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 de 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ía, formación y masterclasses en el campo de las optimizaciones de rendimiento, Angular y programación reactiva. También dirijo una empresa llamada Pushbased. Puedes visitarla, solo haz clic en el enlace en mis diapositivas.

Pero ahora veamos qué hay en la agenda. Primero hablaré sobre la pestaña de red. Te mostraré lo que puedes 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 han lanzado en Chrome es la prioridad de fetch y usaré la prioridad de fetch para optimizar el contenido más grande para pintar con una imagen así como con solicitudes http. Más adelante te mostraré cómo mirar la pestaña de rendimiento. Esto no es realmente fácil porque hay mucha información y espero o digamos que prometo que después de la charla podrás al menos tener un poco más de comprensión sobre lo que verás allí y en qué fijarte. Para demostrar algunas optimizaciones en la pestaña de rendimiento, usaré la visibilidad de contenido, una característica de CSS muy avanzada y también te introduciré a la programación y fragmentación del trabajo en el hilo principal.

Al final de mi charla, algunas cosas realmente, realmente emocionantes de las que quiero hablar son los flujos de usuario. El flujo de usuario es básicamente una nueva herramienta que en este momento solo está disponible en Canary Chrome, y nos permite nuevas formas completamente, de cómo medir el rendimiento en tiempo de ejecución en el navegador. Al final, te presentaré las últimas y más geniales herramientas sobre el flujo de usuario, cómo usarlas y también cómo integrar esas cosas en tu CI. Sin más pausas, me lanzaré directamente al análisis de red y la pestaña de red. Así que lo que ves aquí en esta herramienta es, en primer lugar, seleccioné la pestaña de red y luego tienes mucha información presente. Mucha información sobre todas las solicitudes HTTP que se realizan desde tu aplicación. Y si miras más de cerca la parte derecha de esa diapositiva aquí, verás el diagrama de cascada. En el diagrama de cascada, básicamente ves una especie de gráfico de barras de tiempo que muestra todas nuestras solicitudes HTTP, su inicio, su fin, y de qué tiempo están compuestas. Si pasas el cursor sobre una de esas pestañas, verás el tiempo de solicitud. Y el tiempo de solicitud puede mostrarte alguna información sobre el tiempo de conexión, cuán grande fue la cantidad de datos, y todos los otros tiempos y duraciones que fueron necesarios para completar la recepción de esos datos. En esta diapositiva ves una columna que básicamente nos dice 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 puedes lograr con la prioridad en tu aplicación. Sin más información sobre la pestaña de red, iré directamente a la práctica y te 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 por supuesto, es el tiempo de conexión. En esta diapositiva ves en la parte superior una versión no optimizada de dos solicitudes HTTP a dos dominios diferentes y como puedes ver hay un bloque naranja que conecta y luego un bloque azul que descarga, otro bloque naranja que conecta y otro bloque azul que descarga. Así que si aprovechamos el atributo de pre-conexión en nuestros enlaces, básicamente podemos decirle al navegador, mira a esos dos puntos finales de API a los que enviaremos solicitudes en el futuro, así que ¿por qué no estableces la conexión justo al inicio de la aplicación y luego podemos ahorrar el tiempo de conexión más tarde?

Esto se demuestra en la parte inferior de la imagen y puedes ver que ambos bloqueos de conexión ahora están paralelizados al principio y todo el gráfico es mucho más corto.

Lo siguiente, y esto es lo nuevo y genial, es la prioridad de esas solicitudes HTTP. Nuevamente, en este gráfico ves una versión no optimizada en la parte superior, alguna ejecución de script, alguna obtención de un recurso A, obtención de un recurso B, y luego renderizando cosas.

Por supuesto, renderizar una imagen es más importante que ejecutar algún script o obtener algunos recursos que se usan más tarde. Entonces, lo primero que hacemos es que deberíamos hacer que todos los bloques de scripting amarillos sean asíncronos y no bloqueantes. Esto se puede lograr con los atributos defer, preload, o prefetch. Diferir scripts simplemente significa mover ese script al final de la cola y continuar con el procesamiento, con el análisis de tu HTML. Y precargar y prefetch significa básicamente que intento obtener datos al principio de, digamos, la parte que no es visible en la página. Así que precargar sería precargar fuentes de recursos que se acceden en un momento posterior en esta misma página. Y prefetch podría significar precargar algunas cosas que se usan después de una navegación.

Con estas tres cosas ya podemos llegar lejos, pero hay otra característica realmente, realmente genial y muy, muy útil: la prioridad de fetch. Así que con la prioridad de fetch básicamente podemos determinar cuáles de mis solicitudes HTTP tienen más prioridad que otras y quiero usarla para actualizar el largest contentful paint de una imagen. Si miramos este fragmento de código aquí, vemos dos enlaces que obtienen algunas imágenes hero y una de esas dos imágenes es más importante que la otra. Así que normalmente solo por el orden del contenido HTML primero obtendríamos la imagen hero 1 y más tarde la imagen hero 2. Pero ahora con la prioridad de fetch puede decirle al navegador que la segunda imagen, incluso si es más tarde en el tiempo, tiene más prioridad que la primera y el navegador cambiaría la ejecución de esas dos solicitudes HTTP y obtendría la segunda antes en el tiempo.

¿Cómo se vería eso en la práctica? Así que, tomé ObservableHQ como un sitio web de prueba y lo que vemos aquí es una imagen de video, o como dije, una pequeña imagen de un video que comenzará a reproducirse más tarde y esto es definitivamente el largest contentful pane, la parte más importante que el usuario debería ver al principio. Al aplicar algunos ajustes al HTML y usar prefetch, terminamos con la siguiente mejora. Así que lo que ves en la parte superior es la primera línea de esta tira de película que nos muestra la página predeterminada y la segunda línea de esta tira de película muestra cuál es el resultado de mi optimización. Hay dos cosas diferentes. En primer lugar, todo el gráfico es mucho más corto ahora. Básicamente pasé de un total de 7 segundos a 4.5 segundos. Pero la parte realmente importante e interesante aquí es que el largest content for paint ahora está presente al principio. Así que pasé de 7 segundos del largest content for paint que puedes ver aquí en la parte superior a 2.5 segundos. Esto también es visible aquí en el diagrama detallado en la parte inferior. Y puedes ver que la imagen es realmente lo primero visible y luego después de eso hay alguna obtención. Pero la imagen siempre es visible y ofrece una experiencia de usuario muy agradable para los usuarios que quieren consumir este video o al menos quieren ver un primer vistazo.

La siguiente optimización que quiero hacer es quiero usar o aprovechar la prioridad de fetch en solicitudes HTTP. Así que 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 ves aquí. Con esta técnica veamos qué hice en la práctica con ella. Si echamos un vistazo a 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 se compone de elementos de menú obtenidos dinámicamente. Y como puedes ver, esas solicitudes HTTP se activan bastante tarde en el tiempo. Así que cuando aplico fetch priority y miras la siguiente diapositiva, puedes ver que moví estas cosas al principio y también pude básicamente cambiar el orden de esas dos solicitudes HTTP para que las imágenes de la lista de películas se obtengan primero y después de eso, la lista dinámica en el menú lateral. Bastante genial, cosas bastante emocionantes. Todo lo que viste es básicamente posible con esta nueva característica genial Fetch Priority.

¿Qué sigue? Lo siguiente es la pestaña de rendimiento. La pestaña de rendimiento es uno de los gráficos más informativos, pero también más complicados de leer cuando se trata de herramientas de rendimiento. En la siguiente diapositiva, quiero darte un adelanto de lo que puedes observar y también cómo mejorar esas cosas. Comencemos con lo que es una caída de fotograma o una tarea larga. En primer lugar, un usuario siempre quiere interactuar con tu página. Interacción significa hacer clic, desplazarse o cualquier otra cosa que pueda suceder con el teclado o sobre el teclado. Una de las partes más importantes es darle al navegador la oportunidad de procesar esas interacciones siempre que sea necesario primero o digamos lo más rápido posible. Si miras el gráfico, ves cajas grises y esas cajas grises son las llamadas tareas. Una tarea es básicamente una unidad de trabajo que el navegador necesita procesar antes de que pueda hacer cualquier otra cosa, por ejemplo, reaccionar a una entrada del usuario. Podemos detectar esas tareas largas, tareas que tomaron demasiado tiempo para bloquear la entrada del usuario o el procesamiento de la entrada del usuario por esta área roja o por el pequeño triángulo rojo que puedes ver en la parte superior derecha aquí. Otro lugar donde puedes detectar esas cosas es también la vista general en la parte superior, allí ves estas barras rojas y los garabatos verdes y esas dos cosas básicamente nos dicen A dónde están nuestras tareas largas y B cómo está la tasa de fotogramas por segundo y si los fotogramas por segundo son consistentes, puedes asumir que también nuestras tareas no están bloqueando demasiado. En la parte inferior número 3 ves una vista general en este caso un tiempo total de nuestras tareas largas y su tiempo de bloqueo y el tiempo total de bloqueo es una de las medidas más valoradas en, por ejemplo, la puntuación de lighthouse y siempre debemos intentar reducir las tareas largas o el tiempo total de bloqueo al mínimo.

Ahora vamos a profundizar un poco más y entender cómo puede verse una sola tarea. Así que en esta imagen vemos una tarea en detalle. Vemos que en la parte superior hay una caja gris. La caja gris marca, por supuesto, las cosas, pero lo que también vemos es el tipo de trabajo. Amarillo, púrpura o verde. Scripting, maquetación o pintura. Debajo de todo eso puedes ver los detalles. ¿Qué exactamente fue scriptado? ¿O qué exactamente fue maquetado o pintado? En esta diapositiva ves que esta tarea está marcada como una tarea larga y vemos el área de tiempo extra en estas líneas rojas, no discontinuas, sino afiladas, y luego también vemos la bandera de tarea larga, el triángulo rojo en la esquina superior derecha de cada caja gris de cada tarea que está marcada 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 50 milisegundos es básicamente el tiempo extra de una tarea.

Con toda esa información clicada, saltamos al diseño de página y pintura. Esto es lo que quiero mostrarte cómo optimizar y quiero usar las últimas funciones del navegador disponibles en Edge y también en Chrome. En esta presentación aquí, puedes ver desde CanIUse dónde está soportado y ya te he dicho que desafortunadamente solo está soportado en Edge y Chrome, pero todos los demás navegadores están trabajando arduamente para implementarlo.

Ahora que entendemos dónde puedes usarlo, veamos cuál podría ser el impacto potencial. Aquí hay una medición de laboratorio de tomar 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á en algún lugar debajo de tu tamaño de pantalla, no visible para el usuario en este momento. Si miramos los números, los números superiores están en verde, pintura, por lo que podemos pasar de un estado no optimizado con seis milisegundos de pintura a uno optimizado en pantalla con un milisegundo de pintura y fuera de pantalla realmente, realmente agradable a 0.1 milisegundos fuera de pantalla. Esto es realmente un impacto interesante, diría un impacto tremendo. Aún más genial para el diseño, esta es la parte inferior aquí en esta diapositiva, ves 11 milisegundos de actualización del árbol de capas y pintura con la optimización todo en pantalla 0.5 milisegundos y más tarde todo fuera de pantalla es solo 61 microsegundos, lo cual es un número realmente, realmente interesante y un impacto dramático.

Como las medidas de laboratorio son agradables para aprender y entender, pero lo que realmente nos interesa son los datos de campo. Así que veamos lo que logré en el mundo real. Optimizar el tiempo de renderizado es lo primero que quiero mostrarte y en la siguiente diapositiva vemos nuevamente desde observable HQ en la parte superior algo de 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, una tarea larga porque es más de 50 milisegundos y con mi aplicación de visibilidad de contenido pude reducir a 15 milisegundos para el mismo trabajo realizado en el mismo sitio web. Así que esta es una mejora tremenda y realmente agradable de ver lo que es posible con solo uno o dos pequeños cambios en tu aplicación. Lo siguiente que quiero demostrar o introducirte es la programación y el presupuesto de fotogramas. Esto es principalmente importante para deshacerse de la escritura de scripts o al menos reducir el tiempo total de bloqueo de la escritura de scripts. Lo que vemos en esta diapositiva aquí es la programación de trabajo y cómo podría mejorar la entrada a NextPaint, el tiempo total para interactivo y el tiempo total de bloqueo. Imagina que hay un clic de botón y este clic de botón causaría algún trabajo y en lugar de ejecutar ese trabajo de inmediato, tomo este paquete de trabajo y lo muevo a la siguiente tarea en la siguiente caja gris y lo ejecuto más tarde en el tiempo. En este mismo ejemplo usé el marco de animación para hacer la actualización porque fue una actualización visual que causó algunos píxeles cambiar, pero esto es básicamente también posible con muchas otras APIs de programación. Así que lo que está marcado aquí es el momento de programación en el tiempo y la duración de la programación. Veamos lo que teóricamente mejoraría. Lo que vemos aquí en la línea horizontal discontinua rosa fuerte es el próximo momento posible cuando el navegador podría procesar la interacción del usuario. Esto es una mejora muy agradable y también aumentó el tiempo para interactivo en cantidades tremendas como puedes ver desde este primer corchete aquí y también redujimos el tiempo total de bloqueo en 50 milisegundos porque cada tarea está bien por debajo de 50 milisegundos y ahora hicimos dos en lugar de una tarea. Mejoras bastante sorprendentes y esto es solo la teoría. En la práctica, optimizar el tiempo total de bloqueo y el retraso de entrada es lo siguiente que quiero mostrarte y en este mismo ejemplo quiero demostrar nuevamente la aplicación de películas y el arranque de esa aplicación. Si miramos este diagrama aquí, básicamente vemos una gran tarea que está procesando algunos archivos JavaScript y luego ejecutando el marco. Después de algunas optimizaciones en la parte muy izquierda todavía tenemos un poco de una gran tarea porque optimizar un paquete de webpack y su compilación no es tan fácil, pero todo lo que es del marco ahora está optimizado y podemos ver muchas líneas verticales discontinuas rosa fuerte y esas básicamente son todas tareas separadas que en medio dan al navegador la oportunidad de procesar la entrada del usuario y como puedes ver todas esas tareas no son tareas largas, así que mejoras bastante, bastante sorprendentes que pudimos lograr con la programación y el fraccionamiento. Lo último y más emocionante que puedo demostrarte es User Flows. User Flows es una de las nuevas características elegantes que Chrome DevTools lanzará, en este momento solo es accesible en Chrome Canary, pero debes saber que hay una biblioteca de código abierto que puedes usar e instalar ya hoy y ejecutar todo eso nuevo completamente estable en tu CI o desde tu CLI. El enlace aquí es github.com slash push dash based slash user flow.

Por favor, échale un vistazo, muy interesante. Entonces, ¿qué son los user flows? Si imaginas que Chrome tiene esta herramienta llamada Chrome Lighthouse y Lighthouse hasta ahora solo podía medir el rendimiento de arranque que medía el momento en que navegabas a una página por primera vez, y esto siempre fue una navegación en frío y siempre, como dije, se limitaba solo al rendimiento de arranque. Con la versión 9 algo. Lighthouse ahora permite 3 modos de medición, navegación, lapso de tiempo y snapshot.

La navegación es básicamente la medición predeterminada de Lighthouse que estuvo presente desde siempre. Así que cualquier medición era una medición de navegación o modo de navegación hasta la versión 9. El segundo modo de medición muy interesante y para mí el más emocionante es el modo de medición de lapso de tiempo, donde puedes iniciar y detener la grabación de una duración de tiempo y dentro de esa duración de tiempo puedes ejecutar algunas interacciones de usuario. Por ejemplo, completamente automatizado con Puppeteer. Y al final vemos snapshot y el snapshot es básicamente una forma de tomar una llamada snapshot de tu página en cualquier momento. Y es muy útil para determinar medidas de accesibilidad y otras cosas estáticas en un momento posterior, no solo en la navegación.

Veamos cómo podría verse esto en la práctica. Lo que ves aquí y en un segundo te lo mostraré en vivo es un informe de user flow, básicamente un informe que se ve bastante similar a un informe de Lighthouse, pero como puedes ver tiene múltiples pasos diferentes. Y lo que hice aquí es básicamente pedir un café en línea. Déjame salir rápidamente de las diapositivas y demostrarte cómo se ve este informe en la vida real. Abriré las herramientas de desarrollo de Chrome y espero, si no cometo un error, poder arrastrar y soltar el informe directamente aquí. Como puedes ver, pop. Así que este es el visor de informes normal de lighthouse y ya admite user flows. El primero, déjame hacer clic en resumen es una navegación a esta aplicación del carrito de café y abriré la aplicación para ti solo para que puedas ver una aplicación muy primitiva Puedo seleccionar un café, hacer clic en esa cosa, podría ingresar algunos datos de usuario y luego básicamente pedir un café. Veo el mensaje de confirmación en la parte inferior y eso es todo. Lo que quería grabar. Así que volvamos y echemos un vistazo a esto. Lo que hice fue una navegación a esta página y a partir de los números puedes ver que este es un puntaje predeterminado de lighthouse. Puedo hacer clic en él y veo todos los detalles completos. Tengo todos mis web vitals aquí, algunas imágenes, el tiempo, el mapa de árbol y todos los diagnósticos visibles en la parte inferior. En un momento posterior, grabé el lapso de tiempo de seleccionar un café. Así que de un café no seleccionado a pasar el cursor sobre un café y luego hacer clic en ese café y seleccionarlo. Esto está grabado aquí. Como puedes ver, nos proporciona un número reducido de nuestra grabación. Vemos el tiempo total de bloqueo, cambios acumulativos de diseño y otras cosas.

Y si desplazo más hacia abajo, también vemos todas las grabaciones detalladas. La última es seleccionar un snapshot de café. Así que después de seleccionar un café, quería asegurarme, ¿todavía se da toda la accesibilidad? ¿Se cumplen los términos de CO, siguen siendo las mejores prácticas? Y como puedes ver, esos números aquí nos muestran que se ha reducido, pero aún nos da muchas ideas sobre lo que podemos hacer con esas nuevas herramientas.

Por supuesto, hay más mediciones, nuevamente, otro tiempo dedicado al pago, otro snapshot para el pago, otro tiempo dedicado a la presentación del pedido y otro snapshot para la presentación del pedido. Herramientas realmente agradables. Te recomiendo encarecidamente que consultes el enlace de antes en GitHub push-based con un guion slash user flow, y puedes usarlo directamente ya en tu proyecto, CLI, o incluso CI.

Permíteme volver a las diapositivas y abrirlas en pantalla completa. Y permíteme decir, gracias por tu tiempo. Este es el final de esta muy pequeña, densa y breve charla sobre algunas de las últimas y mejores características. Sé que fue bastante en, mucho en un tiempo mínimo. 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 más, probablemente más activo en Twitter que en cualquier otra plataforma. Y nuevamente, el enlace de GitHub a la última y más genial característica, Userflow, por favor consúltalo. Y nuevamente, muchas gracias por tu tiempo y nos vemos más tarde. Disfruta el resto de la conferencia.