Aplicaciones web de alta velocidad: más allá de lo básico

Hola y bienvenidos a mi charla, Aplicaciones web de alta velocidad más allá de lo básico, una charla sobre las últimas y mejores características en Chrome DevTools. Permítanme presentarme rápidamente. Mi nombre es Michael, Michael Lutke. Muy difícil de leer, escribir y pronunciar, así que quedémonos con Michael. Lo que hago es consultorías, capacitaciones y masterclasses en el campo de las optimizaciones de rendimiento, Angular y programación reactiva. También dirijo una empresa llamada Pushbased. Pueden visitarla, simplemente hagan clic en el enlace en mis diapositivas. Pero ahora veamos qué hay en la agenda. En primer lugar, hablaré sobre la pestaña de red. Les mostraré lo que pueden ver en la pestaña de red y luego intentaré ver algunas de las últimas características. Una de las características geniales que se envían en Chrome es la prioridad de fetch y utilizaré la prioridad de fetch para optimizar el contenido más grande para la pintura con una imagen, así como con las solicitudes HTTP. Más adelante les mostraré cómo ver la pestaña de rendimiento. Esto no es realmente fácil porque hay mucha información y espero o mejor dicho, prometo que después de la charla podrán al menos tener un poco más de comprensión sobre lo que verán allí y qué buscar. Para demostrar algunas optimizaciones en la pestaña de rendimiento, utilizaré la visibilidad de contenido, una característica de CSS muy interesante y también les presentaré la programación y fragmentación del trabajo en el hilo principal. Al final de mi charla, algunas cosas realmente emocionantes de las que quiero hablar son los flujos de usuario. El flujo de usuario es básicamente una nueva herramienta que actualmente solo está disponible en Canary Chrome y nos permite medir el rendimiento en tiempo de ejecución de formas completamente nuevas. Al final, les presentaré las últimas y mejores herramientas sobre el flujo de usuario, cómo usarlas y también cómo integrar esas cosas en su CI. Sin más pausas, pasaré directamente al análisis de red y la pestaña de red. Entonces, lo que ven aquí en esta herramienta es, en primer lugar, seleccioné la pestaña de red y luego tienen mucha información presente. Mucha información sobre todas las solicitudes HTTP que se realizan desde su aplicación. Y si observan más de cerca la parte derecha de esa diapositiva, verán el diagrama de cascada. En el diagrama de cascada, básicamente ven un gráfico de barras de tiempo que muestra todas nuestras solicitudes HTTP, su inicio, su final y el tiempo que están compuestas. Si pasan el cursor sobre una de esas pestañas, verán el tiempo de la solicitud. Y el tiempo de la solicitud puede mostrarles información sobre el tiempo de conexión, cuántos datos había y todos los demás tiempos y duraciones que fueron necesarios para recibir todos esos datos. En esta diapositiva ven una columna que básicamente nos habla sobre la prioridad de las solicitudes HTTP. Podemos ver que algunas de esas solicitudes HTTP son más importantes, tienen una prioridad más alta que otras, y quiero aprovechar una de las últimas características, la Prioridad de Fetch, para demostrar lo que se puede lograr con la prioridad en su aplicación. Sin más información en la pestaña de red, pasaré directamente a la práctica y les mostraré cómo podemos cambiar todas las solicitudes que se realizan y cómo podemos mejorarlas. Una de las primeras cosas que quiero mejorar, también visible en la pestaña de red, es el tiempo de conexión. En esta diapositiva ven en la parte superior una versión no optimizada de dos solicitudes HTTP a dos dominios diferentes y como pueden ver, hay un bloque naranja que se conecta y luego un bloque azul que se descarga, otro bloque naranja que se conecta y otro bloque azul que se descarga. Entonces, si aprovechamos el atributo pre-connect en nuestros enlaces, básicamente le decimos al navegador, mira a esos dos puntos finales de la API, realizaremos solicitudes en el futuro, así que ¿por qué no estableces la conexión justo al comienzo de la aplicación y luego podemos ahorrar tiempo de conexión más tarde?

La siguiente optimización que quiero hacer es aprovechar la prioridad de fetch en las solicitudes HTTP. Entonces, cuando usas la API de fetch, ahora también puedes darle una importancia a esta solicitud HTTP y esto se hace simplemente aplicando otra configuración como se muestra aquí. Con esta técnica, veamos qué hice en la práctica con ella. Si observamos la página, vemos dos contenidos dinámicos diferentes en la página.

Vemos una lista de películas y un menú lateral con una sección que está compuesta por elementos de menú obtenidos dinámicamente. Y como pueden ver, esas solicitudes HTTP se realizan bastante tarde en el tiempo. Entonces, cuando aplico la prioridad de fetch y observan la siguiente diapositiva, pueden ver que moví estas cosas al principio y también pude cambiar básicamente el orden de esas dos solicitudes HTTP para que las imágenes de la lista de películas se obtengan primero y después la lista dinámica en el menú lateral. Bastante genial, cosas emocionantes. Todo lo que vieron es básicamente posible con esta nueva y genial característica, la Prioridad de Fetch.

¿Qué sigue? A continuación está la pestaña de rendimiento. La pestaña de rendimiento es una de las más informativas, pero también una de las gráficas más complicadas de leer cuando se trata de herramientas de rendimiento. En la siguiente diapositiva, quiero darles un vistazo de lo que pueden observar y también cómo mejorar eso. Comencemos con qué es una caída de fotogramas o una tarea larga. En primer lugar, un usuario siempre desea interactuar con su página. La interacción implica hacer clic, desplazarse o cualquier otra cosa que pueda ocurrir en el teclado o a través del teclado. Una de las partes más importantes es darle al navegador la oportunidad de procesar esas interacciones siempre que sea necesario o, digamos, lo más rápido posible. Si observan el gráfico, verán cajas grises y esas cajas grises son tareas. Una tarea es básicamente una unidad de trabajo que el navegador necesita procesar antes de poder hacer cualquier otra cosa, por ejemplo, reaccionar a una entrada del usuario. Podemos identificar esas tareas largas, tareas que tardaron demasiado en bloquear la entrada del usuario o el procesamiento de la entrada del usuario, mediante esta área roja o mediante el pequeño triángulo rojo que pueden ver en la parte superior derecha aquí. Otro lugar donde pueden identificar eso es también la vista general en la parte superior, allí verán estas barras rojas y las ondulaciones verdes, y esas dos cosas básicamente nos indican A dónde están nuestras tareas largas y B cómo es la velocidad de fotogramas por segundo y si la velocidad de fotogramas es constante, podemos asumir que nuestras tareas no están bloqueando demasiado. En la parte inferior número 3, verán una vista general en este caso del tiempo total de nuestras tareas largas y su tiempo de bloqueo, y el tiempo total de bloqueo es una de las medidas más importantes en, por ejemplo, la puntuación de Lighthouse y siempre debemos tratar de reducir las tareas largas o el tiempo total de bloqueo al mínimo.

Ahora vamos a acercarnos un poco más y entender cómo puede verse una sola tarea. En esta imagen vemos una tarea en detalle. Vemos que en la parte superior hay un cuadro gris. El cuadro gris marca, por supuesto, la tarea, pero lo que también vemos es el tipo de trabajo. Amarillo, morado o verde. Programación, diseño o pintura. Debajo de todo eso puedes ver los detalles. ¿Qué exactamente se ha programado? ¿O qué exactamente se ha diseñado o pintado? En esta diapositiva vemos que esta tarea se marca como una tarea larga y vemos el área de tiempo extra en estas líneas rojas punteadas, o no punteadas, pero afiladas, y luego también vemos la marca de tarea larga, el triángulo rojo en la esquina superior derecha de cada cuadro gris de cada tarea que se marca como una tarea larga. Esta información es muy importante para nosotros porque esto es lo que necesitamos eliminar. Lo que necesitamos eliminar es todo lo que dure más de 50 milisegundos. Como puedes ver aquí, 50 milisegundos es una tarea larga aceptable y todo lo que esté por encima de los 50 milisegundos es básicamente el tiempo extra de una tarea.

Con toda esa información en mente, pasemos a la salida y pintura de la página. Esto es lo que quiero mostrarte cómo optimizar, y quiero utilizar las últimas funciones del navegador disponibles en Edge y también en Chrome. En esta presentación de diapositivas, puedes ver en CanIUse dónde es compatible y ya te he dicho que, desafortunadamente, solo es compatible con Edge y Chrome, pero todos los demás navegadores están trabajando mucho para implementarlo.

Ahora que entendemos dónde se puede usar, veamos cuál podría ser el impacto potencial. Aquí tenemos una medición de laboratorio de una página en un estado no optimizado, una página optimizada con visibilidad de contenido o nodos en pantalla, lo que significa que todo el contenido es visible dentro de la página, y luego todo el contenido fuera de pantalla, lo que significa que está debajo del tamaño de tu pantalla y no es visible para el usuario en ese momento. Si observamos los números, los números superiores están en verde, que representan la pintura, por lo que podemos pasar de una pintura no optimizada de seis milisegundos a una pintura optimizada en pantalla de un milisegundo y fuera de pantalla realmente, realmente rápida, de 0.1 milisegundos fuera de pantalla. Este es realmente un impacto interesante, diría que tremendo. Aún más interesante para el diseño, esta es la parte inferior de la diapositiva, puedes ver 11 milisegundos para actualizar el árbol de capas y pintar con la optimización todo en pantalla 0.5 milisegundos y luego todo fuera de pantalla es solo 61 microsegundos, lo cual es un número realmente interesante y un impacto dramático. Si bien las mediciones de laboratorio son útiles para aprender y comprender, lo que realmente nos interesa son los datos de campo. Así que veamos lo que logré en la práctica. La optimización del tiempo de renderizado es lo primero que quiero mostrarte, y en la siguiente diapositiva vemos nuevamente desde observable HQ en la parte superior alguna animación y trabajo de diseño que está presente aquí. Y la tarea más larga en este trabajo de diseño tomó básicamente 260 milisegundos. Por supuesto, es una tarea larga porque dura más de 50 milisegundos y con mi aplicación de visibilidad de contenido pude reducirlo a 15 milisegundos para el mismo trabajo realizado en el mismo sitio web. Esto es una mejora tremenda y realmente bueno ver lo que es posible con solo uno o dos pequeños cambios en tu aplicación. Lo siguiente que quiero demostrar o presentarte es la programación y el presupuesto de cuadros. Esto es especialmente importante para eliminar o al menos reducir el tiempo total de bloqueo de la ejecución de scripts. Lo que vemos en esta diapositiva es la programación del trabajo y cómo podría mejorar la entrada hasta el siguiente pintado, el tiempo total hasta la interactividad y el tiempo total de bloqueo. Imagina que hay un clic en un botón y ese clic en el botón causaría algún trabajo y en lugar de ejecutar ese trabajo de inmediato, tomo ese paquete de trabajo y lo muevo a la siguiente tarea, al siguiente cuadro gris, y lo ejecuto más tarde en el tiempo. En este ejemplo específico, utilicé el marco de animación para realizar la actualización porque era una actualización visual que cambiaba algunos píxeles pero esto básicamente también es posible con muchas otras APIs de programación. Lo que se marca aquí es el momento de programación en el tiempo y la duración de la programación. Veamos qué mejoraría teóricamente. Lo que vemos aquí en la línea horizontal punteada de color rosa intenso es el siguiente momento posible en el que el navegador podría procesar la interacción del usuario. Esto es una mejora muy buena y también aumentó el tiempo hasta la interactividad en cantidades tremendas como puedes ver en este primer paréntesis aquí y también redujimos el tiempo total de bloqueo en 50 milisegundos porque cada tarea está bien si dura menos de 50 milisegundos y ahora tenemos dos en lugar de una tarea. Mejoras realmente asombrosas y esto es solo la teoría. En la práctica, la optimización del tiempo total de bloqueo y la demora de entrada es lo siguiente que quiero mostrarte y en este ejemplo quiero demostrar nuevamente la aplicación de películas y la inicialización de esa aplicación. Si observamos este diagrama aquí, básicamente vemos una tarea enorme que está procesando algunos archivos JavaScript y luego ejecutando el framework. Después de algunas optimizaciones en la parte izquierda, todavía tenemos una tarea un poco grande porque optimizar un paquete de webpack y su compilación no es tan fácil, pero todo lo que está en el ámbito del framework ahora está optimizado y podemos ver muchas líneas verticales punteadas de color rosa intenso y esas básicamente son todas tareas separadas que permiten al navegador procesar la entrada del usuario y como puedes ver, todas esas tareas no son tareas largas, por lo que son mejoras realmente, realmente asombrosas que podríamos lograr con la programación y la fragmentación. Lo último y más emocionante que puedo demostrarte son los Flujos de Usuario. Los Flujos de Usuario son una de las nuevas y elegantes funciones que Chrome DevTools lanzará, actualmente solo se puede acceder en Chrome Canary, pero debes saber que hay una biblioteca de código abierto que puedes usar e instalar desde hoy y ejecutar todas esas cosas nuevas de manera totalmente estable en tu CI o desde tu CLI. El enlace aquí es

Y si sigo desplazándome hacia abajo, también vemos todas las grabaciones detalladas. La última es una captura de pantalla de la selección de un café. Así que después de seleccionar un café, quería asegurarme, ¿se sigue cumpliendo la accessibility? ¿Se cumplen los términos de CO, sigue siendo una buena práctica? Y como puedes ver, estos números aquí nos muestran que se ha reducido, pero aún nos brinda mucha información sobre lo que podemos hacer con estas nuevas herramientas. Por supuesto, hay más mediciones, nuevamente, más tiempo invertido en el proceso de pago, otra captura de pantalla para el proceso de pago, más tiempo invertido en el envío del pedido y otra captura de pantalla para el envío del pedido. Herramientas realmente útiles. Recomiendo encarecidamente que consultes el enlace anterior en GitHub push-based con una barra diagonal y flujo de usuario, y ya puedes usarlo directamente en tu proyecto, CLI, o incluso CI.

Permíteme volver a las diapositivas y abrirlas a pantalla completa. Y permíteme decirte, gracias por tu tiempo. Este es el final de esta charla muy pequeña, densa y breve sobre algunas de las últimas y mejores características. Sé que fue bastante en poco tiempo. Así que si tienes alguna pregunta, no dudes en enviarme un correo electrónico, michael.latki8-push-based.io. También estoy en Twitter y probablemente más activo en Twitter que en cualquier otra plataforma. Y nuevamente, el enlace de GitHub a la última y mejor característica, Userflow, por favor, échale un vistazo. Y nuevamente, muchas gracias por tu tiempo y nos vemos más tarde. Disfruta el resto de la conferencia. Gracias.