Rendimiento web, manteniendo su puntuación de Lighthouse 100.

Prueba De Solicitudes De Extracción

Resulta que es difícil mejorar la puntuación de Lighthouse una vez que es baja, pero no es difícil mantenerla en 100 si realiza pruebas continuamente.

Cuando abre una solicitud de extracción (PR) en un proyecto, las direcciones URL de prueba en la descripción del proyecto se utilizan para ejecutar el servicio PageSpeed Insights con. El bot de AEM GitHub fallará automáticamente en su PR si la puntuación es inferior a 100 con un poco de búfer para tener en cuenta la volatilidad de los resultados.

Los resultados son para la puntuación del faro móvil, ya que tienden a ser más difíciles de lograr que el escritorio.

¿Por qué Google PageSpeed Insights?

Muchos equipos e individuos utilizan sus propias configuraciones para medir las puntuaciones de Lighthouse. Diferentes equipos han desarrollado sus propios mazos de pruebas y utilizan sus propias herramientas de prueba con configuraciones que se han configurado como parte de sus prácticas de monitorización continua y generación de informes de rendimiento.

El rendimiento de un sitio web afecta a sus clasificaciones en los resultados de búsqueda, lo que se refleja en los elementos vitales web principales del informe crUX. Google tiene un buen control de las combinaciones medias relevantes de información del dispositivo (por ejemplo, tamaño de pantalla), así como el rendimiento de red de esos dispositivos. Pero al final, la SEO es el árbitro supremo de lo que es un buen desempeño frente a un mal desempeño web. Como la configuración específica es un objetivo móvil, las prácticas de rendimiento deben alinearse con los dispositivos y las características de red medias actuales a nivel global.

Por eso, en lugar de usar una configuración específica del proyecto para las pruebas de Lighthouse, usamos las configuraciones que se actualizan continuamente y que forman parte de las estrategias móviles y de escritorio a las que se hace referencia en las últimas versiones de la API de PageSpeed Insights de Google.

Aunque puede haber una perspectiva adicional que algunos desarrolladores sientan que pueden recopilar de otras formas de medir las puntuaciones de Lighthouse, para poder tener una conversación de rendimiento significativa y comparable entre proyectos, debe haber una manera de medir el rendimiento universalmente. El servicio PageSpeed Insight predeterminado es la prueba de laboratorio más autorizada y aceptada cuando se trata de medir el rendimiento.

Sin embargo, es importante recordar que las recomendaciones que obtiene de PageSpeed Insights no necesariamente conducen a mejores resultados, especialmente cuanto más cerca esté de una puntuación de faro de 100.

Los elementos vitales de la web (CWV) recopilados por la recopilación de datos integrada de RUM desempeñan un papel importante en la validación de los resultados. Sin embargo, para cambios menores, la variación de los resultados y la falta de puntos de datos suficientes (tráfico) durante un corto período de tiempo hace que sea poco práctico obtener resultados estadísticamente relevantes en la mayoría de los casos.

LCP

En general, LCP es la imagen "a pantalla completa" que se muestra en la parte superior de una página. Es crucial asegurarse de que esta imagen se cargue y se muestre lo antes posible en la secuencia de carga (consulte la fase Eager).

Se debe cargar todo lo que se necesita cargar para que se muestre el LCP verdadero. En un proyecto, esto suele consistir en el marcado, los estilos CSS y los archivos JavaScript.

En muchos casos, el elemento LCP está contenido en un bloque, donde el bloque .js y y .css también deben cargarse.

Es una buena regla general mantener la carga útil agregada antes de que LCP se muestre por debajo de 100 kb, lo que generalmente da como resultado un evento de LCP más rápido que 1560 ms (LCP con una puntuación de 100 en PSI). Especialmente en dispositivos móviles, la red tiende a estar restringida en el ancho de banda, por lo que cambiar la secuencia de carga antes de LCP tiene un impacto mínimo o nulo.

No se recomienda cargar desde o conectarse a un segundo origen antes de que se produzca LCP, ya que el establecimiento de una segunda conexión (TLS, DNS, etc.) agrega un retraso significativo a LCP.

Hay situaciones en las que el elemento LCP real no se incluye en el marcado que se transmite al cliente. Esto sucede cuando hay una indirección o búsqueda (por ejemplo, un servicio al que se llama, un fragmento que se ha cargado o una búsqueda que debe realizarse en un elemento .json) para el elemento LCP.
En estos casos, es importante que al cargar la página se espere a adivinar el candidato LCP (actualmente la primera imagen de la página) hasta que el primer bloque haya realizado los cambios necesarios en el DOM.

Hay otras situaciones en las que el contenido contiene 2 imágenes a pantalla completa, una para escritorio y otra para móvil. Al igual que en el caso anterior, es importante asegurarse de que la imagen correcta se considere como el candidato LCP y que sea necesario ajustar el bloque "hero" para eliminar la imagen innecesaria de DOM (eliminar la imagen de escritorio en dispositivos móviles o viceversa) y, de este modo, no cargar una imagen que consume ancho de banda o, peor aún, cargar primero la imagen innecesaria como candidato LCP.

Por último, LCP puede ser algo más que una imagen, un vídeo, un texto largo… En todos esos casos, es necesario tener una comprensión profunda de la secuencia de carga y de cómo se calcula el candidato LCP para realizar las optimizaciones correctas.

Fase L: diferida

En la fase lenta, se carga la parte de la carga útil que no afecta al tiempo total de bloqueo (TBT) y, en última instancia, al primer retraso de entrada (FID).

Esto incluye cosas como cargar las secciones siguientes y sus bloques (JavaScript y CSS), así como cargar todas las imágenes restantes según su atributo loading="lazy" y otras bibliotecas de JavaScript que no estén bloqueando. La fase diferida es generalmente todo lo que sucede en los distintos blocks que va a crear para cubrir las necesidades del proyecto.

En esta fase sería aconsejable que la mayor parte de la carga útil provenga del mismo origen y esté controlada por el primero, de modo que se puedan realizar cambios si es necesario para evitar el impacto negativo en TBT, TTI y FID.

Fase D: retrasada

En la fase retrasada, se cargan las partes de la carga útil que no tienen un impacto inmediato en la experiencia o que no están controladas por el proyecto y provienen de terceros. Piense en las herramientas de marketing, la administración de consentimiento, los análisis ampliados, los módulos de chat/interacción, etc. que a menudo se implementan mediante soluciones de administración de etiquetas.

Es importante comprender que, para minimizar el impacto en la experiencia general del cliente, el inicio de esta fase debe retrasarse significativamente. La fase retrasada debe ser de al menos tres segundos después del evento LCP para dejar tiempo suficiente para que el resto de la experiencia se resuelva.

La fase retrasada se controla normalmente en delayed.js, que sirve como captador global inicial para los scripts que provocan TBT. Lo ideal es que los problemas de TBT se eliminen de los scripts en cuestión cargándolos fuera del subproceso principal (en un trabajo web) o simplemente eliminando el tiempo real de bloqueo del código. Una vez solucionados los problemas, esas bibliotecas se pueden añadir fácilmente a la fase de carga diferida y cargarse antes.

Lo ideal es que no haya tiempo de bloqueo en los scripts, lo que a veces es difícil de lograr, ya que la tecnología utilizada comúnmente como los administradores de etiquetas o las herramientas de compilación crean grandes archivos JavaScript que se bloquean a medida que el explorador los analiza. Desde el punto de vista del rendimiento, es aconsejable eliminar esas técnicas, asegúrese de que los scripts individuales no se bloqueen y cárguelos individualmente como archivos separados más pequeños.

Encabezado y pie de página

El encabezado y, específicamente, el pie de página de la página no se encuentran en la ruta crítica de LCP, por lo que se cargan de forma asíncrona en sus respectivos bloques. Por lo general, los recursos que no comparten el mismo ciclo de vida (lo que significa que se actualizan con cambios de creación en diferentes momentos) deben mantenerse en documentos independientes para que la cadena de almacenamiento en caché entre los orígenes y el explorador sea más sencilla y eficaz. Mantener estos recursos separados aumenta las proporciones de visitas de caché y reduce la invalidación de la caché y la complejidad de la administración de la caché.

Fuentes

Dado que las fuentes web suelen ser una carga excesiva en el ancho de banda y se cargan desde un origen diferente a través de un servicio de fuentes como https://fonts.adobe.com o https://fonts.google.com, es prácticamente imposible cargar fuentes antes de LCP, por lo que se cargan justo después.

De manera predeterminada, AEM Boilerplate implementa la técnica de reserva de fuente para evitar CLS cuando se carga la fuente. Sería contraproducente precargar las fuentes (mediante sugerencias tempranas, h2-push o marcado) y afectar en gran medida a las prestaciones.

Bonus: La velocidad es verde

Crear sitios web rápidos, pequeños y rápidos de procesar no es solo una buena idea para ofrecer experiencias excepcionales que mejoren la conversión, sino que también es una buena manera de reducir las emisiones de carbono.

Fuentes comunes de problemas de rendimiento

Con el tiempo, recopilamos una colección de antipatrones que afectan negativamente al rendimiento y deben evitarse para cumplir con las prácticas recomendadas en este documento.

Las sugerencias iniciales, h2-push o preconexión forman parte del presupuesto de la red

Instintivamente, tendría sentido decirle al navegador que descargue tanto como sea posible y lo antes posible, incluso antes de que se inicie el procesamiento del marcado. Pero recuerde, el objetivo final es tener una página estable para mostrar al visitante lo antes posible. El tiempo de LCP es un buen proxy para eso.

Como regla general, para obtener un(a) LCP a 100 en dispositivos móviles con PageSpeed Insight, las restricciones de red se configuran de manera que solo pueda haber un único host con una carga útil de red que no supere los 100 KB, ya que la configuración está restringida en gran medida en el ancho de banda. Las sugerencias tempranas, h2-push y preconnect consumen ese ancho de banda, al descargar recursos que no son necesarios para LCP y que, por lo tanto, afectan negativamente al rendimiento y deben eliminarse.

Redirecciones para resolución de rutas

Si un visitante solicita www.domain.com y se le redirige a www.domain.com/en y luego a www.domain.com/en/home,, se le aplica una penalización por cada redirección, es decir, el rendimiento se ve afectado negativamente. Esto es visible principalmente en Core Web Vitals medido a través de RUM o CrUX como resultados de laboratorio en PageSpeed Insights de forma predeterminada excluyen la sobrecarga de redireccionamiento de la prueba de laboratorio.