Optimización del renderizado del navegador: explicada

¿Cómo te hacen sentir los tiempos de carga largos de un sitio web? Quizá te suene: la página por fin carga, pero aun así no puedes hacer clic ni desplazarte porque hay cosas ocurriendo en segundo plano. 

Y cuando por fin la página responde, aparecen animaciones descontroladas que lo vuelven todo lento y torpe… ¿Te ha pasado alguna vez? 

A mí sí, y no hace mucho. Y lo sorprendente es que sigo viéndolo, pese a la cantidad de herramientas y prácticas de optimización que tenemos a nuestra disposición. 

La optimización del renderizado del navegador es un tema amplio que cubre muchas áreas e implica herramientas, técnicas y un sinfín de oportunidades de mejora. 

Este artículo se centrará sobre todo en la entrega eficiente de páginas al usuario final: los tiempos de carga, cómo se miden y cómo mejorarlos cuando trabajas como desarrollador frontend. 

Aspectos de la optimización de páginas

En cuanto a conseguir que las páginas se rendericen más rápido y sean más reactivas tras la carga (junto con acciones de usuario más ágiles y animaciones más fluidas), lo trataremos en otro artículo del blog. 

De momento, veamos estos aspectos de la optimización de páginas:

Por qué deberías optimizar el renderizado de la página

Ciclo de vida de la aplicación: el modelo RAIL 

Cómo auditar una página: indicadores y herramientas disponibles

Técnicas de optimización: soluciones y trucos para mejorar la velocidad web en cuatro frentes: entorno, recursos, build y entrega

*(Dado que la optimización y la auditoría del renderizado han crecido mucho en los últimos años, no abarcaré todos los temas en detalle. Algunos solo se mencionarán por encima; por ello, siempre que sea posible, referenciaré fuentes externas para ampliar información.) 

¿Por qué optimizar el renderizado del navegador? 

Ya se ha investigado y escrito mucho sobre la importancia de la memoria y de varios indicadores de experiencia de usuario para los negocios.

Un colega mío escribió recientemente un excelente artículo recopilando una gran cantidad de datos sobre cómo la experiencia de usuario con un sitio web impacta en áreas clave del funcionamiento de una empresa con presencia online. 

Puedes leerlo aquí. 

Algunas cifras rápidas para hacerte una idea de la importancia de optimizar: 

Tiempos de carga más rápidos: cualquier sitio que carga en 5 segundos disfruta de un 25% más de visibilidad de anuncios, sesiones un 70% más largas y una tasa de rebote un 35% menor. 

Cinco segundos no es lo ideal. Un estudio de 2016 mostró que uno de cada dos usuarios móviles espera que una página cargue en menos de dos segundos, y hasta el 53% de los visitantes probablemente abandone si tarda más de 3 segundos. 

En 2017, Google publicó un informe sobre cómo el tiempo de carga aumenta la tasa de rebote. En el mismo informe, una encuesta mostró que la velocidad de la carga inicial de la página es el factor más importante para los usuarios en lo que respecta a la experiencia de usuario. 

De hecho, es 3 veces más importante que la apariencia del sitio. ¡Incluso más importante que la facilidad para encontrar la información buscada! Los tiempos de carga también se vinculan directamente a los ingresos que genera la página: el 80% de los usuarios de Internet está dispuesto a pagar más por una buena experiencia de uso.

Pero basta de teoría. Pasemos a la parte técnica.

RAIL y el ciclo de vida de la aplicación

Cuando hablamos de rendimiento general del sitio, es útil referirse al modelo RAIL. RAIL asume 4 etapas del ciclo de vida de la aplicación (aunque no debe confundirse con el ciclo de vida de componentes en los principales frameworks): response, animation, idle y load. 

Sin embargo, ese orden no coincide con la cronología real de lo que ocurre al abrir un sitio nuevo (en cuyo caso lo llamaríamos LIAR: load, idle, animation y response).

 Seguiré este orden y comentaré la importancia y los detalles de cada etapa una a una. 

La fase de Load es la carga inicial de la página. Obviamente, cuanto más corta, mejor. Distintas fuentes sugieren que este evento debería tardar como máximo de 1 a 5 segundos; sin embargo, las métricas de Google catalogan cualquier valor por encima de 2,5 segundos como “necesita mejora”. 

Es uno de los parámetros esenciales para la experiencia de usuario. 

La fase de Idle es el tiempo tras la carga inicial en el que los usuarios deciden qué hacer. La página espera su interacción, así que aquí podemos finalizar otros trabajos que sacamos de la fase de carga (imágenes, vídeos, secciones de comentarios). 

Estas tareas deberían ejecutarse en trozos de 50 ms para que, cuando el usuario interactúe, la respuesta a su acción tenga prioridad sobre cualquier cosa en segundo plano. 

Para que las Animations se sientan fluidas, hay que generar un frame en menos de 16 ms. En un artículo sobre el modelo RAIL en web.dev leemos: 

En puntos de alta presión como las animaciones, la clave es no hacer nada cuando sea posible, y lo mínimo imprescindible cuando no lo sea. Siempre que puedas, aprovecha la respuesta en 100 ms para pre-calcular trabajo costoso y así maximizar tus opciones de alcanzar 60 frames por segundo. 

La fase de Response es la respuesta a una acción del usuario (p. ej., pulsar un botón, hacer routing) y debería producirse en 100 ms. Es el tiempo máximo que pasa desapercibido; aún se percibe como respuesta instantánea. 

En el diagrama de arriba, Load e Idle están marcadas en azul, mientras que Animation y Response en verde. Esto es porque Load e Idle se dan una sola vez por cada página nueva cargada (en SPA pueden ser únicas durante toda la vida de la app), mientras que Animation y Response se repiten en cada nueva interacción del usuario.

Uso de Google Web Vitals

Para medir el rendimiento del sitio y determinar si, cuándo y dónde requiere optimización, necesitamos herramientas. Idealmente, deberían ser universales para poder comparar resultados con otras páginas en Internet. 

Google tomó la delantera creando Web Vitals. Web Vitals es una iniciativa de Google que ofrece una guía unificada de señales de calidad esenciales para ofrecer una gran experiencia de usuario en la web. 

Aunque existen muchas herramientas para medir y optimizar el rendimiento web, Google decidió desarrollar una que cualquiera pudiera entender y aplicar con facilidad. 

Para ello implementó también un subconjunto llamado Core Web Vitals, orientado a medir tres aspectos de la experiencia de usuario: carga, interactividad y estabilidad visual. 

Se miden con tres métricas:

Fuente: https://web.dev/vitals/ 

Largest Contentful Paint (LCP) - Mide el tiempo de carga inicial. Como ves, la carga debería ocurrir dentro de los primeros 2,5 segundos. Con 1,5 segundos adicionales (4 en total) ya se considera una experiencia pobre.

First Input Delay (FID) - Mide la interactividad. La acción del usuario debería reflejarse (responder) en 100 ms. Más tiempo y el sitio se percibe con lag. 

Cumulative Layout Shift (CLS) - Este ratio muestra la estabilidad de la página. Si una página carga a trompicones y el contenido se desplaza por imágenes que irrumpen o por anuncios que aparecen segundos después, también se considera una mala experiencia.

Medir Core Web Vitals con Lighthouse

Hay varias formas de medir Core Web Vitals (y no solo CWV). Una con la que todo desarrollador debería empezar es Lighthouse: una herramienta automatizada y de código abierto para medir y reportar el rendimiento de un sitio y sus puntos débiles. 

Antes estaba en la pestaña Audits de las herramientas de desarrollador, pero recientemente se eliminó y se reemplazó por una extensión independiente de Chrome.

Si el sitio que quieres auditar ya está en producción, no necesitas extensiones. La herramienta está disponible aquí. Lighthouse incorpora los tres indicadores descritos (LCP, FID, CLS), entre otros. 

Te lo muestro:

Este es un análisis de Lighthouse ejecutado para un sitio elegido al azar con sus resultados correspondientes:

Fuente: https://web.dev/measure/ 

Como puedes ver, Lighthouse se centra en cuatro áreas principales: Performance, Accessibility, Best Practices y SEO. Dado que nuestro foco ha sido el rendimiento, desgranemos esta puntuación.

Al final del informe hay seis métricas que definen distintas áreas de rendimiento y que ahora explicaré:

Speed Index (SI) -  Una comparación del speed index de tu página frente al de sitios reales, basada en datos del HTTP Archive. Puedes saber más sobre Speed Index aquí. 

Time to Interactive (TTI) - Mide el tiempo que tarda el sitio en volverse completamente interactivo. Tiene en cuenta factores como FCP, el registro de event handlers para elementos visibles y la respuesta a acciones del usuario dentro del parámetro de 50 ms.  Lee aquí una explicación más detallada del cálculo del TTI. 

Total Blocking Time (TBT) - Está directamente ligado a la fase Idle del modelo RAIL. Muestra el tiempo total de bloqueo de la página debido a la ejecución en segundo plano de tareas. Idealmente, estos trozos no deberían superar los 50 ms. 

Ahora bien, Lighthouse no es perfecto. Con el tiempo se han registrado inconsistencias, algunas documentadas en la web de Calibre y en este artículo de blog. 

PageSpeed

Otra gran herramienta para medir el rendimiento es el sitio de Google Developers PageSpeed. Es muy simple: pega la URL que quieras auditar y pulsa Analyze. En segundos verás un informe con dos secciones y selección de dispositivo. 

Empiezo por la segunda sección, Diagnose Performance Issues. ¿Te suena? Correcto: es como un informe de Lighthouse. Y lo es. PageSpeed incorpora resultados de laboratorio de Lighthouse como parte de sus resultados. 

Genial. O no. ¿Y si tu página muestra un rendimiento mediocre y sigues sin saber qué causa los malos resultados en áreas concretas? Lighthouse te cubre. 

Si haces scroll verás una lista de posibles problemas en distintos aspectos del rendimiento junto con soluciones. Están marcados y ordenados según su gravedad y el impacto que pueden tener en la optimización. 

La primera sección del informe es la más importante, ya que ilustra la experiencia REAL de los usuarios en tu web. Basada en datos reales de sesiones de usuarios en Chrome, vemos cómo se comporta la página en la vida real, a diferencia del entorno más de laboratorio de Lighthouse. 

Además, puedes medir esta experiencia tanto en desktop como en dispositivos móviles.

En el informe de PageSpeed, verás un indicador que aún no comentamos: FCP, o First Contentful Paint. 

FCP indica cuándo los usuarios empiezan a ver contenido en la página. Es otra métrica útil que se tiene en cuenta, ya que es crucial que al menos aparezca algo en pantalla lo antes posible:

Fuente: https://pagespeed.web.dev/ 

Pero todo esto son muchas teorías y ratios. Pasemos a algo mucho más interesante para nosotros, los desarrolladores: las principales causas de malas métricas y cómo mejorarlas. 

Optimiza con entorno, recursos, build y entrega 

Como por fin hablamos de optimización, ahora te daré diez pistas para hacer tu página ultrarrápida y no tener que optimizarla nunca más. 

Es broma. 

Bueno, en realidad no. ¿A qué me refiero?

Se han escrito muchas guías sobre cómo optimizar el rendimiento web. Vitaly Friedman escribió un artículo increíble sobre prácticamente todos los métodos de optimización del renderizado usados en 2021. Por eso es una lectura exhaustiva de 3 horas. 

Con tantísimas variables en nuestros entornos de desarrollo, hay infinitas posibilidades de error. O, mejor dicho, muchas combinaciones que pueden funcionar en una app y no necesariamente en otra. 

No las cubriremos todas aquí; eso exigiría otro artículo de 3 horas y repetir lo que ya han escrito otros autores más expertos que yo. 

En su lugar, te dejo una lista de cosas a considerar al optimizar tu aplicación en los cuatro frentes que un desarrollador frontend puede abordar: entorno, recursos, build y entrega.

Entorno 

Build tools - Grunt, Gulp, Webpack, Parcel, Rollup, Snowpack… Mientras cumplas objetivos de mantenimiento y rendimiento, vas bien con cualquier configuración. Si te cuesta elegir, recuerda que Webpack lleva mucho tiempo y ofrece un gran abanico de plugins de optimización. 

Framework - ¿Angular, Vue, React, Svelte? Ten en cuenta que los frameworks modernos no priorizan los dispositivos más modestos. Además, no todas las páginas en una SPA requieren cargar todo el framework. Para más contexto, mira este estupendo caso de estudio de Netflix

Rendering - Server-Side, Static, Streaming Server-Side, Client-Side… elijas lo que elijas, recuerda que la tarea más importante es minimizar el tiempo entre LCP y TTI.

Baseline performance cost - En lugar de ir con un framework “puro”, puedes optar por ninguno o por una alternativa opinionated como Next.js, Nuxt.js o React, etc. Y aquí tienes un estudio muy interesante sobre el coste en rendimiento de los frameworks. 

Fuente: https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/

Recursos

AVIF, AV1, WebP, WebM -  Usar formatos modernos de foto y vídeo puede suponer un gran impulso para reducir tiempos de carga; aunque WebM y AVIF aún necesitan algo más de soporte, ya viene en camino.

Responsive images - Usa siempre imágenes responsive con `srcset`, sizes y el elemento <picture>. Los background-image también pueden ser responsive: revisa la propiedad CSS `image-set`. 

Web fonts, Google Fonts -  Un tema grande en sí mismo que puedes profundizar en este artículo.

Brotli -  Un formato de compresión sin pérdidas, abierto y muy prometedor. 

GIFs -  No te molestes: son ineficientes en tamaño; usa en su lugar vídeos HTML en bucle:

Fuente: https://www.smashingmagazine.com/2021/01/front-end-performance-2021-free-pdf-checklist/#defining-the-environment 

Build

JS modules, patrón module/nomodule (differential serving) -  Aprende más en la documentación del motor V8 del navegador y en el blog de PerfPlanet.

Tree-shaking, code-splitting, scope-hoisting -  Probablemente ya los conozcas: son prácticas estándar en builders como Webpack. 

Web Worker - Para reducir el TTI, es buena idea delegar algunos cálculos iniciales a un web worker. 

Optimización en SPA - La mayoría de devs frontend hoy usan frameworks SPA. Hay varias cosas para mejorar su rendimiento, pero para abreviar, enlazo este gran artículo práctico de CSS-Tricks. 

Identificar y eliminar CSS/JS no usados - Puedes usar Chrome DevTools (Coverage), o Puppeteer, que también realiza otras tareas útiles como preparar contenido prerenderizado.

Partial hydration - Si quieres profundizar en este concepto, puedes empezar con buenos casos de estudio: aquí uno para usuarios de React y otro muy bueno para fans de Vue. 

Cache-Control - Aunque el caché no es nuevo, al profundizar descubres la parte sumergida del iceberg. Hay muchas estrategias y matices al definir cómo debe cachear un navegador. Para una introducción rápida, ve aquí. Si ya vas avanzado, este artículo sobre cómo la red puede ser más rápida que el caché te interesará.

Third-party libraries - Cuantas menos, mejor. Según thirdpartyweb.today, las librerías de terceros suponen el 57% de toda la ejecución de JS. Si necesitas una, mejor autoalójala.

Fuente: thirdpartyweb.today 

Entrega

Lazy loading - Además de usar defer o async para algunos scripts, el lazy-loading nativo ya está soportado por todos los navegadores (para imágenes; iFrames pronto tendrán soporte). 

Intersection Observer - Según su definición: Intersection Observer API proporciona una forma de observar de forma asíncrona cambios en la intersección de un elemento objetivo con un ancestro o con el viewport del documento. En otras palabras, nos da control granular sobre elementos que están a punto de entrar en vista. Junto con el lazy-loading, puede ser muy potente.  Si nunca lo has usado, aquí tienes un buen ejemplo práctico.

Content-visibility - Cuando todos los navegadores lo soporten, podremos implementar lazy-loading de secciones completas de la página solo con CSS. Si tu home es larga (con múltiples secciones), será buena idea renderizarlas justo antes de que aparezcan en pantalla. Aquí un gran ejemplo de cómo usarlo para acelerar el LCP. 

Critical CSS - Hoy es práctica común separar o marcar el CSS above-the-fold y adjuntarlo en la parte <head> de la página.

Service Worker - También pueden reducir drásticamente los tiempos de carga posteriores usando recursos en caché

Rendering performance - Para que un sitio se sienta responsivo, debemos tener en cuenta el proceso de renderizado de frames y optimizarlo. Pero como es otro tema enorme, publicaremos un artículo aparte sobre cómo optimizar las fases de Animation y Response del modelo RAIL.

Connection-aware components - Puedes aprovechar APIs del navegador cada vez más completas y renderizar componentes según el ancho de banda del usuario (consulta el objeto navigator.connection). Es muy útil al lanzar una aplicación global para usuarios con velocidades que van de muy lentas a ultrarrápidas:

Fuente: https://dev.to/addyosmani/loading-web-pages-fast-on-a-20-feature-phone-8h6 

Optimización proactiva y reactiva del navegador

La lista anterior puede parecer abrumadora al principio. Así que quizá te preguntes: si quiero que mi web rinda al máximo, ¿tengo que revisar punto por punto si necesita optimización? 

Aunque conviene tenerlos presentes, la optimización debería ser una mezcla de enfoques proactivos y reactivos. Algunos puntos son obvios y deberían tenerse en cuenta al escribir código. 

Entre ellos: gestión de dependencias, SSR, gestión de recursos, tipografías, tree-shaking, librerías de terceros, caché y lazy loading. Si los incorporas al día a día, aumentan mucho las probabilidades de obtener buenas puntuaciones en cualquier análisis de rendimiento. 

Sin embargo, si los resultados siguen sin ser satisfactorios, las herramientas anteriores señalarán los puntos débiles de tu aplicación para optimizarlos después (Webpack, CDN, SSR, differential serving, partial hydration, imports diferidos, renderizado aplazado, Critical CSS, Service Worker, etc.). 

Si quieres ver cómo es el camino de optimización para la landing de una gran marca de moda, puedes ver este video grabado por Addy Osmani, uno de los principales especialistas de Google en optimización.

También puedes ir más allá del código y los ajustes de servidor y profundizar en la configuración a nivel de navegador para optimizar Google Chrome. Para muchos usuarios, con explorar la configuración de Chrome ya basta para descubrir opciones como la aceleración por hardware y el flag “Override software rendering list”. En algunas máquinas, la aceleración por hardware descarga trabajo a la GPU y ayuda de verdad a que Chrome renderice páginas complejas con mayor fluidez; en otras, introduce jank y artefactos visuales. En esos casos, desactivar la aceleración por hardware en la configuración de Chrome puede hacer que el navegador se sienta más estable y predecible en sitios con muchas animaciones o gráficos.

Para diagnósticos más avanzados, Google Chrome también incluye un Administrador de tareas (Shift+Esc) que muestra qué pestañas, extensiones y procesos consumen más CPU y memoria durante la carga. Así es más fácil detectar una extensión del Chrome Web Store que esté afectando al rendimiento, incluso si tu código y tu servidor ya están optimizados. Combinar una buena higiene de extensiones con una configuración sensata del navegador te da otra capa de control sobre el rendimiento real, complementando todas las optimizaciones de renderizado y entrega descritas antes. 

Resumen

A estas alturas, espero que haya quedado claro lo crucial que es ofrecer una experiencia de usuario óptima. Habiendo tocado las dos primeras fases del modelo RAIL, también debería estar claro el enfoque adecuado para la carga de páginas y cómo ofrecer a los usuarios el contenido que buscan lo antes posible.

También vimos las herramientas Lighthouse y PageSpeed, que ayudan a identificar los factores que pueden obstaculizar la capacidad de respuesta de tu web. Luego recurrimos a una chuleta condensada con distintas técnicas de optimización a las que puedes recurrir para lograr ese objetivo. 

En definitiva, recuerda que los muchos temas descritos aquí son solo la punta del iceberg que mencioné. Ojalá el tema te resulte lo bastante interesante como para seguir explorando algunas de las técnicas que ilustré y que, al hacerlo, tus habilidades de optimización web mejoren considerablemente.

¡Feliz programación!