Optimización del rendimiento del sitio web y la ruta de representación crítica

¿El rendimiento de representación de su página web cumple con los estándares actuales? La representación es el proceso de traducir la respuesta de un servidor a la imagen que el navegador "pinta" cuando un usuario visita un sitio web. Un mal rendimiento de renderizado puede traducirse en una tasa de rebote relativamente alta.

Hay diferentes respuestas del servidor que determinan si una página se representa o no. En este artículo, nos centraremos en la presentación inicial de la página web, que comienza con el análisis de HTML (siempre que el navegador haya recibido correctamente HTML como respuesta del servidor). Exploraremos las cosas que pueden conducir a tiempos de renderizado altos y cómo solucionarlos.

Ruta de representación crítica

La ruta de representación crítica (CRP) es el proceso por el que pasa su navegador para convertir el código en píxeles visualizables en su pantalla. Tiene varias etapas, algunas de las cuales se pueden realizar en paralelo para ahorrar tiempo, pero algunas partes deben realizarse de forma secuencial. Aquí se visualiza:

En primer lugar, una vez que el navegador obtiene la respuesta, comienza a analizarla. Cuando encuentra una dependencia, intenta descargarla.

Si se trata de un archivo de hoja de estilo, el navegador tendrá que analizarlo por completo antes de mostrar la página, y es por eso que se dice que CSS bloquea el procesamiento .

Si es un script, el navegador debe: dejar de analizar, descargar el script y ejecutarlo. Solo después de eso puede continuar con el análisis, porque los programas de JavaScript pueden alterar el contenido de una página web (HTML, en particular). Y es por eso que JS se llama bloqueo del analizador .

Una vez que se realiza todo el análisis, el navegador tiene el Modelo de objetos de documento (DOM) y el Modelo de objetos de hojas de estilo en cascada (CSSOM) construidos. Combinarlos juntos da el Render Tree. Las partes de la página que no se muestran no se incluyen en el árbol de representación porque solo contiene los datos necesarios para dibujar la página.

El penúltimo paso es traducir el Render Tree a Layout. Esta etapa también se llama reflujo. Ahí es donde se calcula cada posición de cada nodo de Render Tree, así como su tamaño.

Finalmente, el último paso es Paint. Consiste literalmente en colorear los píxeles de acuerdo con los datos que el navegador ha calculado durante las etapas anteriores.

Conclusiones relacionadas con la optimización

Como puede adivinar, el proceso de optimización del rendimiento del sitio web implica cambios en el sitio web que reducen:

• La cantidad de datos que tienen que ser transferidos
• La cantidad de recursos que el navegador tiene que descargar (especialmente los de bloqueo)
• La duración de la PCR

Además, profundizaremos en los detalles de cómo se hace, pero primero, hay una regla importante que observar.

Cómo medir el rendimiento

Una regla importante de optimización es: Mida primero, optimice según sea necesario . La mayoría de las herramientas de desarrollo de los navegadores tienen una pestaña llamada Rendimiento , y ahí es donde se realizan las mediciones. Al optimizar para el renderizado inicial (primero) más rápido, lo más importante que debe tener en cuenta es la hora de los siguientes eventos:

• Primera pintura
• Primera pintura con contenido
• Primera pintura significativa

Aquí, "Pintar" significa renderizado exitoso de una página, la última etapa en la ruta crítica de renderizado. Algunos renderizados pueden ocurrir uno tras otro porque los navegadores intentan mostrar algo lo antes posible y actualizarlo más tarde.

Además del tiempo de renderizado, hay otras cosas a tener en cuenta, lo más importante, cuántos recursos de bloqueo se utilizan y cuánto se tarda en descargarlos. Esta información se encuentra en la pestaña Rendimiento después de realizar las mediciones.

Estrategias de optimización del rendimiento

Dado lo que hemos aprendido anteriormente, existen tres estrategias principales para la optimización del rendimiento del sitio web:

1. Minimizar la cantidad de datos que se transferirán a través del cable,
2. Reducir el número total de recursos que se transferirán por cable, y
3. Acortar la ruta de renderizado crítica

1. Minimice la cantidad de datos que se transferirán

En primer lugar, elimine todas las partes no utilizadas, como funciones inaccesibles en JavaScript, estilos con selectores que nunca coinciden con ningún elemento y etiquetas HTML que se ocultan para siempre con CSS. En segundo lugar, elimine todos los duplicados.

Entonces, recomiendo poner en marcha un proceso automático de minificación. Por ejemplo, debe eliminar todos los comentarios de lo que está sirviendo su back-end (pero no el código fuente) y todos los caracteres que no contienen información adicional (como los espacios en blanco en JS).

Una vez hecho esto, lo que nos queda puede ser como texto. Significa que podemos aplicar con seguridad un algoritmo de compresión como GZIP (que la mayoría de los navegadores entienden).

Por último, está el almacenamiento en caché. No ayudará la primera vez que un navegador muestre la página, pero ahorrará mucho en visitas posteriores. Sin embargo, es crucial tener en cuenta dos cosas:

• Si usa un CDN, asegúrese de que el almacenamiento en caché sea compatible y esté configurado correctamente allí.
• En lugar de esperar a que llegue la fecha de vencimiento de los recursos, es posible que desee tener una forma de actualizarlo antes desde su lado. Incruste las "huellas dactilares" de los archivos en sus URL para poder invalidar el caché local.

Por supuesto, las políticas de almacenamiento en caché deben definirse por recurso. Algunos pueden cambiar raramente o nunca cambiar en absoluto. Otros están cambiando más rápido. Algunos contienen información confidencial, otros podrían considerarse públicos. Utilice la directiva "privada" para evitar que las CDN almacenen en caché datos privados.

También se pueden optimizar las imágenes web, aunque las solicitudes de imágenes no bloquean ni el análisis ni la representación.

2. Reducir el recuento total de recursos críticos

"Crítico" se refiere solo a los recursos necesarios para que la página web se muestre correctamente. Por lo tanto, podemos saltarnos todos los estilos que no intervienen directamente en el proceso. Y todos los guiones también.

hojas de estilo

Para decirle al navegador que no se requieren archivos CSS particulares, debemos establecer atributos de media para todos los enlaces que hacen referencia a las hojas de estilo. Con este enfoque, el navegador solo tratará los recursos que coincidan con los media actuales (tipo de dispositivo, tamaño de pantalla) según sea necesario, mientras reduce la prioridad de todas las demás hojas de estilo (se procesarán de todos modos, pero no como parte de la representación crítica). sendero). Por ejemplo, si agrega el atributo media="print" a la etiqueta de style que hace referencia a los estilos para imprimir la página, estos estilos no interferirán con su ruta de representación crítica cuando los medios no se print (es decir, cuando se muestra el página en un navegador).

Para mejorar aún más el proceso, también puede hacer algunos de los estilos en línea. Esto nos ahorra al menos un viaje de ida y vuelta al servidor que, de otro modo, habría sido necesario para obtener la hoja de estilo.

Guiones

Como se mencionó anteriormente, los scripts bloquean el analizador porque pueden alterar DOM y CSSOM. Por lo tanto, los scripts que no los alteran no deben bloquearse, ahorrándonos así tiempo.

Para implementar eso, todas las etiquetas de script deben estar marcadas con atributos, ya sea async o defer .

Los scripts marcados con async no bloquean la construcción de DOM o CSSOM, ya que pueden ejecutarse antes de que se construya CSSOM. Sin embargo, tenga en cuenta que los scripts en línea bloquearán CSSOM de todos modos a menos que los coloque por encima de CSS.

Por el contrario, los scripts marcados con defer se evaluarán al final de la carga de la página. Por lo tanto, no deberían afectar el documento (de lo contrario, se activará una nueva representación).

En otras palabras, con defer , la secuencia de comandos no se ejecuta hasta que se activa el evento de carga de la página, mientras que async permite que la secuencia de comandos se ejecute en segundo plano mientras se analiza el documento.

3. Acorte la longitud de la ruta de representación crítica

Finalmente, la longitud del CRP debe acortarse al mínimo posible. En parte, los enfoques descritos anteriormente harán eso.

Las consultas de medios como atributos para las etiquetas de estilo reducirán el recuento total de recursos que deben descargarse. Los atributos de la etiqueta del script defer y async evitarán que los scripts correspondientes bloqueen el análisis.

Los recursos de minificación, compresión y archivo con GZIP reducirán el tamaño de los datos transferidos (reduciendo así también el tiempo de transferencia de datos).

Incorporar algunos estilos y scripts puede reducir el número de viajes de ida y vuelta entre el navegador y el servidor.

Lo que aún no hemos discutido es la opción de reorganizar el código entre los archivos. De acuerdo con la última idea de mejor rendimiento, lo primero que debe hacer un sitio web más rápido es mostrar contenido ATF. ATF significa por encima del pliegue. Esta es el área que se ve de inmediato, sin desplazarse. Por lo tanto, es mejor reorganizar todo lo relacionado con la representación de manera que los estilos y scripts requeridos se carguen primero, y todo lo demás se detenga, ni el análisis ni la representación. Y recuerda siempre medir antes y después de hacer el cambio.

Conclusión: la optimización abarca toda su pila

En resumen, la optimización del rendimiento del sitio web incorpora todos los aspectos de la respuesta de su sitio, como el almacenamiento en caché, la configuración de un CDN, la refactorización, la optimización de recursos y otros, sin embargo, todo esto se puede hacer gradualmente. Como desarrollador web, debe utilizar este artículo como referencia y recordar siempre medir el rendimiento antes y después de sus experimentos.

Los desarrolladores de navegadores hacen todo lo posible para optimizar el rendimiento del sitio web para cada página que visita, razón por la cual los navegadores generalmente implementan el llamado "cargador previo". Esta parte de los programas escanea antes de un recurso que haya solicitado en HTML para realizar múltiples solicitudes a la vez y hacer que se ejecuten en paralelo. Esta es la razón por la que es mejor mantener las etiquetas de estilo cerca unas de otras en HTML (en líneas), así como las etiquetas de secuencias de comandos.

Además, intente agrupar las actualizaciones de HTML para evitar múltiples eventos de diseño, que se activan no solo por un cambio en DOM o CSSOM, sino también por un cambio de orientación del dispositivo y un cambio de tamaño de la ventana.

Recursos útiles y lecturas adicionales:

• Perspectivas de PageSpeed
• Lista de verificación de almacenamiento en caché
• Una forma de probar si GZIP está habilitado para su sitio web
• Redes de navegador de alto rendimiento: un libro de Ilya Grigorik