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

La calidad de la experiencia de los sitios web es crucial para lograr los objetivos comerciales de su sitio web y la satisfacción de los visitantes.

Adobe Experience Manager AEM () está optimizado para ofrecer experiencias excelentes y un rendimiento web óptimo. Con el Monitorización de uso real (RUM) operaciones de recopilación de datos, la información se recopila continuamente a partir del uso en el campo y ofrece una forma de iterar en las mediciones de rendimiento del uso real sin tener que esperar a que los datos CRuX muestren los efectos de los cambios en el código y la implementación. Es común que los datos de campo recopilados en RUM se desvíen de los resultados del laboratorio, ya que la red, la geolocalización y la potencia de procesamiento para dispositivos reales son mucho más diversas que las condiciones simuladas en un laboratorio.

El Google PageSpeed Insight Service se ha demostrado que es una gran herramienta de medición de laboratorio. Se puede utilizar para evitar el lento deterioro de la puntuación de rendimiento y experiencia de su sitio web.

Si inicia el proyecto con las plantillas, como en el Tutorial para desarrolladores, obtendrá una puntuación de Lighthouse muy estable en PageSpeed Insight tanto para móviles como para equipos de escritorio en 100. En cada componente de la puntuación del faro hay algún búfer para que el código del proyecto se consuma y siga estando dentro de los límites de un perfecto 100 puntuación del faro.

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 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. AEM El bot de GitHub de GitHub fallará automáticamente en su PR si la puntuación es inferior 100 con un poco de búfer para dar cuenta de cierta 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 ello, en lugar de utilizar una configuración específica del proyecto para las pruebas de Lighthouse, utilizamos las configuraciones que se actualizan continuamente y que forman parte de las estrategias móviles y de sobremesa a las que se hace referencia en las últimas versiones de Google API de PageSpeed Insights.

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 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.

Carga trifásica (E-L-D)

Dividir la carga útil de una página web en tres fases hace que sea relativamente sencillo obtener una puntuación de faro limpia y, por lo tanto, establece una línea de base para una buena experiencia del cliente.

El método de carga en tres fases divide la carga útil y la ejecución de la página en tres fases

Fase E: Impaciente

En el ansioso fase, todo lo que se necesita para cargar para el verdadero LCP que se desea mostrar está cargado. En un proyecto, esto suele consistir en el marcado, los estilos CSS y los archivos JavaScript.

En muchos casos la variable LCP está contenido en un bloque (a menudo creado por el bloqueo automático), donde el bloque .js y y .css también deben cargarse.

El cargador de bloques muestra las secciones de forma progresiva, lo que significa que todos los bloques de la primera sección deben cargarse para la LCP para hacerse visible. Por este motivo, puede tener sentido tener una sección más pequeña que contenga lo menos necesario en la parte superior de una página.

Es una buena regla general mantener la carga útil agregada antes de que el LCP se muestra por debajo de 100 kb, lo que suele dar lugar a un LCP evento más rápido que 1560 ms (LCP 100 en PSI). Especialmente en dispositivos móviles, la red tiende a tener limitaciones de ancho de banda, por lo que al cambiar la secuencia de carga antes de LCP tiene un impacto mínimo o nulo.

Cargando desde o conectándose a un segundo origen antes de la variable LCP se ha producido un error se recomienda encarecidamente porque establece una segunda conexión (TLS, DNS, etc.) añade un retraso significativo a LCP.

Fase L: diferida

En el holgazán fase, la parte de la carga útil que se carga que no afecta al tiempo total de bloqueo (TBT) y, finalmente, el primer retraso de entrada (FID).

Esto incluye elementos como cargar bloques (JavaScript y CSS), así como cargar todas las imágenes restantes según su loading="lazy" y otras bibliotecas de JavaScript que no bloquean. La fase lenta es generalmente todo lo que sucede en los distintos blocks 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 la primera parte, de modo que se puedan realizar cambios si es necesario para evitar un impacto negativo en TBT, TTI y FID.

Fase D: retrasada

En el retrasado fase, 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 proceden 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 establezca.

La fase retardada se suele controlar en delayed.js que sirve como captador global inicial para los scripts que causan TBT. Lo ideal es que TBT los problemas se eliminan 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 al 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 a menudo son una carga 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 en gran medida imposible cargar fuentes antes de la LCP, por lo que generalmente se añaden al lazy-styles.css y se cargan después de LCP se muestra.

Bloques LCP

Hay situaciones en las que el LCP 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 que se llama, un fragmento que se ha cargado o una búsqueda que debe realizarse en un .json) para el LCP Elemento.
En estos casos, es importante que la carga de la página espere a que se adivine el LCP Candidata (actualmente la primera imagen de la página) hasta que el primer bloque haya realizado los cambios necesarios en el DOM.
Para identificar qué bloques esperar antes de bloquear para el LCP carga, puede añadir los bloques que contienen la variable LCP al elemento LCP_BLOCKS matriz en scripts.js.

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.