Novedades de Lighthouse 6.0

Nuevas métricas, actualización de la puntuación de rendimiento, nuevas auditorías y mucho más.

Connor Clark
Connor Clark

Hoy lanzamos Lighthouse 6.0.

Lighthouse es una herramienta automatizada de auditoría de sitios web que ayuda a los desarrolladores con oportunidades y diagnósticos para mejorar la experiencia del usuario en sus sitios. Está disponible en Herramientas para desarrolladores de Chrome, npm (como módulo Node y CLI) o como una extensión del navegador (en Chrome y Firefox). Potencia a muchos servicios de Google servicios, como web.dev/measure y PageSpeed. Estadísticas.

Lighthouse 6.0 está disponible de inmediato en npm y en Chrome Canary. Otros servicios de Google que usan Lighthouse recibirás la actualización antes de fin de mes. Llegará a la versión estable de Chrome en Chrome 84 (a mediados de julio).

Para probar la CLI de Node de Lighthouse, usa los siguientes comandos: bash npm install -g lighthouse lighthouse https://www.example.com --view

Esta versión de Lighthouse incluye una gran cantidad de cambios en el registro de cambios de la versión 6.0. Abordaremos lo más destacado de este artículo.

Métricas nuevas

Métricas de Lighthouse 6.0.

Lighthouse 6.0 incluye tres métricas nuevas en el informe. Dos de estas métricas nuevas: la Contentful Paint (LCP) y Cambio de diseño acumulado (CLS) son implementaciones de lab de Core Web Datos vitales.

Largest Contentful Paint (LCP)

El procesamiento de imagen con contenido más grande (LCP) es una medición de la carga percibida. una experiencia fluida a los desarrolladores. Marca el punto durante la carga de la página en el que se carga el contenido principal (o "más grande") y es visible para el usuario. El LCP es un complemento importante del primer procesamiento de imagen con contenido (FCP), que solo capturan el inicio de la experiencia de carga. El LCP les indica a los desarrolladores cómo rápidamente un usuario puede ver el contenido de una página. Una puntuación de LCP inferior a 2.5 segundos es considerada "buena".

Para obtener más información, mira este análisis detallado sobre LCP de Paul Ireland.

Cumulative Layout Shift (CLS)

Cambio de diseño acumulado (CLS) es una medición de la estabilidad visual. Integra cuantifica cuánto se desplaza visualmente el contenido de una página. Una puntuación de CLS baja es un indicador para a los desarrolladores que sus usuarios no experimenten cambios de contenido indebidos una puntuación de CLS inferior a 0.10 es considerada "buena".

En un entorno de lab, el CLS se mide hasta el final de la carga de la página. Mientras que, en el campo, Mide el CLS hasta la primera interacción del usuario o incluye todas las entradas del usuario.

Para obtener más información, mira este análisis detallado sobre CLS de Annie Sullivan.

Tiempo de bloqueo total (TBT)

El Tiempo de bloqueo total (TBT) cuantifica la capacidad de respuesta de carga y mide la la cantidad total de tiempo durante la cual se bloqueó el subproceso principal durante el tiempo suficiente para evitar la capacidad de respuesta de la entrada. La TBT mide la cantidad total de tiempo entre el primer procesamiento de imagen con contenido (FCP) y el tiempo de carga (TTI). Es una métrica complementaria de TTI y ofrece más matices para cuantificar la actividad del subproceso principal. que bloquea la capacidad de un usuario de interactuar con la página.

Además, TBT se correlaciona bien con la métrica de campo Retraso de primera entrada (FID), que es una Métrica web esencial.

Actualización de la puntuación de rendimiento

La puntuación de rendimiento en Lighthouse se calcula a partir de un combinación ponderada de varias métricas para resumir la velocidad de una página. La fórmula de la puntuación de rendimiento de 6.0 sigue.

Fase Nombre de la métrica Peso de la métrica
Temprano (15%) First Contentful Paint (FCP) 15%
Medio (40%) Índice de velocidad (SI) 15%
Largest Contentful Paint (LCP) 25%
Tarde (15%) Tiempo de carga (TTI) 15%
Subproceso principal (25%) Tiempo de bloqueo total (TBT) 25%
Previsibilidad (5%) Cumulative Layout Shift (CLS) 5%

Si bien se agregaron tres métricas nuevas, se quitaron tres métricas anteriores: la primera pintura significativa, Primera CPU inactiva y FID potencial máximo. Las ponderaciones de las métricas restantes se modificaron a y enfatizar la interactividad del subproceso principal y la predictibilidad del diseño.

A modo de comparación, aquí está la puntuación de la versión 5:

Fase Nombre de la métrica Peso
Temprano (23%) First Contentful Paint (FCP) 23%
Medio (34%) Índice de velocidad (SI) 27%
Primera pintura significativa (FMP) 7%
Completados (46%) Tiempo de carga (TTI) 33%
Primera inactividad de la CPU (FCI) 13%
Subproceso principal FID potencial máxima 0%

Cambios de puntuación de Lighthouse entre las versiones 5 y 6.

Estos son algunos aspectos destacados de los cambios de puntuación entre las versiones 5 y 6 de Lighthouse:

  • El peso de TTI se redujo del 33% al 15%. Fue una respuesta directa al usuario sobre la variabilidad de TTI, así como inconsistencias en las optimizaciones de métricas mejoras en la experiencia del usuario. El TTI sigue siendo un indicador útil para cuando una página se encuentra completamente interactivo, pero con TBT como complemento, la variabilidad se reduce. Con este cambio en la puntuación, esperamos que se aliente de manera más eficaz a los desarrolladores a que optimicen interactividad del usuario.
  • El peso del FCP se redujo del 23% al 15%. Medir solo cuando el primer píxel se (FCP) no nos proporcionó una imagen completa. Se combina con la medición del momento en que los usuarios pueden para ver qué es lo más probable que le interese (LCP) que refleje mejor la experiencia de carga.
  • El FID potencial máximo dejó de estar disponible. Ya no aparece en el informe, pero que todavía están disponibles en JSON. Te recomendamos revisar la TBT para cuantificar la interactividad en lugar de mpFID.
  • First Meaningful Paint dejó de estar disponible. Esta métrica era demasiado variante y no tenía ruta de la estandarización, ya que la implementación es específica para los componentes internos de renderización de Chrome. Mientras que algunos equipos consideran que el tiempo del FMP es valioso en su sitio, la métrica no recibirá mejoras adicionales.
  • La primera CPU inactiva dejó de estar disponible porque no se diferencia lo suficiente de TTI. TBT y TTI son las métricas de interactividad actuales.
  • El peso de CLS es relativamente bajo, aunque esperamos aumentarlo en una versión principal futura.

Cambios en las puntuaciones

¿Cómo afectan estos cambios a las puntuaciones de los sitios reales? Publicamos un análisis de los cambios de puntuación usando dos conjuntos de datos: un conjunto general de sitios y un conjunto de sitios estáticos compilada con Eleventy. En resumen, alrededor del 20% de los sitios ven puntuaciones, ~30% casi no presentan cambios y alrededor del 50% observan una disminución de, al menos, cinco puntos.

Los cambios en la puntuación se pueden desglosar en tres componentes principales:

  • cambios en el peso de la puntuación
  • correcciones de errores en implementaciones de métricas subyacentes
  • cambios en la curva de puntuación individual

Los cambios en el peso de la puntuación y la introducción de tres métricas nuevas generaron la mayor parte de la puntuación general. cambios. Las métricas nuevas que los desarrolladores aún deban optimizar tienen un peso significativo en la versión 6 nivel de rendimiento. Si bien la puntuación de rendimiento promedio del corpus de prueba en la versión 5 fue de alrededor de 50, las puntuaciones promedio en las nuevas métricas de Tiempo de bloqueo total y Largest Contentful Paint fueron de alrededor de 30. En conjunto, esas dos métricas representan el 50% del peso de la puntuación de rendimiento de la versión 6 de Lighthouse, por lo que, naturalmente, un gran porcentaje de los sitios tuvo disminuciones.

Las correcciones de errores en el cálculo de la métrica subyacente pueden generar puntuaciones diferentes. Esto afecta relativamente pocos sitios, pero pueden tener un impacto considerable en ciertas situaciones. En general, alrededor del 8% de los sitios experimentaron una mejora en la puntuación debido a los cambios en la implementación de las métricas y cerca del 4% de los sitios obtuvieron una puntuación debido a cambios en la implementación de métricas. Aproximadamente el 88% de los sitios no se vieron afectados por estas correcciones.

Los cambios en la curva de puntuaciones individuales también afectaron de forma muy leve los cambios en la puntuación general. Mié asegúrate periódicamente de que la curva de puntuación se alinee con las métricas observadas en el archivo HTTPArchive conjunto de datos. Se excluyen los sitios afectados por cambios importantes en la implementación, menores. Los ajustes en la curva de puntuaciones de métricas individuales mejoraron las puntuaciones de aproximadamente el 3% de los sitios y disminuyó los puntajes de aproximadamente un 4% de los sitios. Aproximadamente el 93% de los sitios no se vieron afectados por este cambio.

Calculadora de puntuación

Publicamos una calculadora de puntuación para ayudarte. a explorar la puntuación de rendimiento. La calculadora también te ofrece una comparación entre la versión 5 de Lighthouse y 6 puntuaciones. Cuando ejecutas una auditoría con Lighthouse 6.0, el informe incluye un vínculo a la calculadora con los resultados propagados.

Calculadora de puntuación de Lighthouse.
Muchísimas gracias a Ana Tudor por la actualización del indicador.

Nuevas auditorías

JavaScript sin usar

Usamos el código de Herramientas para desarrolladores cobertura en una nueva auditoría: No utilizado JavaScript

Esta auditoría no es completamente nueva, sino que se agregó a mediados de 2017, pero debido a la sobrecarga de rendimiento, se inhabilitó de forma predeterminada para mantener Lighthouse tan rápido como como sea posible. Recopilar estos datos de cobertura es mucho más eficiente, por lo que de forma predeterminada.

Auditorías de accesibilidad

Lighthouse usa la maravillosa biblioteca axe-core para potenciar la categoría de accesibilidad. En Lighthouse 6.0, agregamos las siguientes auditorías:

Ícono de enmascarable

Los íconos enmascarables son un nuevo formato de ícono que crea íconos para tu AWP se vean bien en todo tipo de dispositivos. Para que tu AWP se vea lo mejor posible, introdujimos se realizará una nueva auditoría para comprobar si el archivo manifest.json admite este nuevo formato.

Declaración de conjunto de caracteres

El elemento meta charset declara qué codificación de caracteres se debe usar. para interpretar un documento HTML. Si falta este elemento o si se declara tarde en la los navegadores emplean varios métodos heurísticos para adivinar la codificación que se debe utilizar. Si un si el navegador lo adivina incorrectamente y se encuentra un elemento meta charset tardío, el analizador generalmente arrojará todo el trabajo realizado hasta ahora y empieza de nuevo, lo que lleva a una mala experiencia para el usuario. Esta nueva auditoría verifica que la página tenga una codificación de caracteres válida y que se defina al principio y al principio.

Lighthouse CI

En CDS el pasado mes de noviembre anunciamos Lighthouse CI, el servicio de Node.js CLI y servidor que realiza un seguimiento de los resultados de Lighthouse en cada confirmación de tu integración continua y hemos avanzado mucho desde el lanzamiento de la versión alfa. Lighthouse CI ahora es compatible para varios proveedores de CI, como Travis, Circle, GitLab y GitHub Actions. Listo para implementar Las imágenes de Docker hacen que la configuración sea un diseño integral del panel ahora revela tendencias en todas las categorías y métricas en Lighthouse para obtener un análisis detallado.

Comienza a usar Lighthouse CI en tu proyecto hoy mismo siguiendo nuestro guía de introducción.

Lighthouse CI
Lighthouse CI
Lighthouse CI

Cambio de nombre del panel de Herramientas para desarrolladores de Chrome

Cambiamos el nombre del panel Auditorías a Lighthouse. ¡Suficientemente dicho!

Según el tamaño de la ventana de Herramientas para desarrolladores, es probable que el panel esté detrás del botón ». Puedes arrastrar la pestaña para cambiar el orden.

Para mostrar el panel rápidamente con la tecla Command en el menú desplegable:

  1. Presiona `Control + Mayúsculas + J` (o `Command + Option + J` en Mac) para abrir Herramientas para desarrolladores.
  2. Presiona Control+Shift+P (o Command+Shift+P en Mac) para abre el menú Comando.
  3. Comienza a escribir "Lighthouse".
  4. Presiona Enter.

Emulación de dispositivos móviles

Lighthouse sigue una mentalidad centrada en los dispositivos móviles. Los problemas de rendimiento son más evidentes en dispositivos móviles, pero los desarrolladores no suelen realizar pruebas en esas condiciones. Por eso, la configuración predeterminada en Lighthouse aplica la emulación móvil. La emulación consta de lo siguiente:

  • Simulación de condiciones lentas de la red y la CPU (mediante un motor de simulación llamado Farol).
  • Emulación de pantalla del dispositivo (la misma que se encuentra en las Herramientas para desarrolladores de Chrome)

Desde el principio, Lighthouse utiliza el Nexus 5X como dispositivo de referencia. En los últimos años, la mayoría los ingenieros de rendimiento utilizaron el Moto G4 para realizar pruebas. Ahora Lighthouse sigue su ejemplo y cambió su dispositivo de referencia a Moto G4. En la práctica, este cambio no es muy notorio, pero aquí están todos los cambios detectables por una página web:

  • El tamaño de la pantalla cambia de 412 x 660 px a 360 x 640 px.
  • La cadena de usuario-agente cambió ligeramente, la parte del dispositivo que anteriormente era Nexus 5 Build/MRA58N ahora será Moto G (4).

A partir de Chrome 81, el Moto G4 también está disponible en la lista de emulación de dispositivos de las Herramientas para desarrolladores de Chrome.

Lista de emulación de dispositivos de Herramientas para desarrolladores de Chrome con Moto G4 incluido.

Extensión del navegador

El Extensión de Chrome para Lighthouse ha sido una forma conveniente de ejecutar Lighthouse de forma local. Lamentablemente, brindar asistencia fue complicado. Sentimos que debido a que el panel Lighthouse de las Herramientas para desarrolladores de Chrome es una mejor experiencia (el informe se integra con otros paneles), podríamos reducir nuestra sobrecarga de ingeniería si simplificamos el uso de Chrome .

En lugar de ejecutar Lighthouse de forma local, la extensión ahora usa la herramienta PageSpeed Insights API Reconocemos que esto no sería un reemplazo suficiente para algunos de nuestros usuarios. Estas son las diferencias clave:

  • PageSpeed Insights no puede auditar sitios web no públicos, ya que se ejecuta a través de un controlador remoto y no a tu instancia local de Chrome. Si necesita auditar un sitio web no público, utilice el panel Lighthouse de Herramientas para desarrolladores o la CLI de Node.
  • No se garantiza que PageSpeed Insights utilice la versión más reciente de Lighthouse. Si quieres usar la versión más reciente, usa la CLI de Node. La extensión del navegador se actualizará en aproximadamente 1 a 2 semanas después del lanzamiento.
  • PageSpeed Insights es una API de Google y su uso implica la aceptación de las Condiciones de la API de Google Servicio. Si no deseas o no puedes aceptar las Condiciones del Servicio, usa el panel Lighthouse de Herramientas para desarrolladores. o la CLI de Node.

La buena noticia es que simplificar la historia del producto nos permitió enfocarnos en otras ingenierías problemas. Como resultado, lanzamos Lighthouse Firefox extensión.

Presupuestos

Lighthouse 5.0 introdujo los presupuestos de rendimiento, que admite agregar umbrales para cuánto de cada tipo de recurso (como secuencias de comandos, imágenes o CSS) que puede publicar una página.

Incorporaciones de Lighthouse 6.0 asistencia para las métricas presupuestarias, así que ahora puedes establecer umbrales para métricas específicas como el FCP. Por ahora, los presupuestos solo están disponibles a Node CLI y Lighthouse CI.

Vínculos de ubicación de origen

Algunos de los problemas que Lighthouse descubre sobre una página se remonta a una línea específica de código fuente, y el informe indicará el archivo y la línea exactos que sean relevantes. Para que esto sea fácil de en Herramientas para desarrolladores. Haz clic en las ubicaciones especificadas en el informe para abrir los archivos relevantes. en el panel Fuentes.

Herramientas para desarrolladores muestra la línea de código exacta que causa el problema.

En el horizonte

Lighthouse comenzó a experimentar con la recopilación de mapas de origen para potenciar funciones nuevas, como las siguientes:

  • Detección de módulos duplicados en paquetes de JavaScript
  • Detección de polyfills excesivos o transformaciones en el código enviado a navegadores modernos
  • Se mejoró la auditoría de JavaScript sin usar para brindar nivel de detalle a nivel del módulo.
  • Visualizaciones de diagrama de árbol en las que se destacan los módulos que requieren acción.
  • Se muestra el código fuente original de los elementos del informe con una "ubicación de origen".
JavaScript sin usar que muestra módulos de mapas de orígenes.
La auditoría de JavaScript sin usar usa mapas de origen para mostrar el código sin usar en módulos empaquetados específicos.

Estas funciones se habilitarán de forma predeterminada en una versión futura de Lighthouse. Por ahora, puedes ver Auditorías experimentales de Lighthouse con la siguiente marca de la CLI:

lighthouse https://web.dev --view --preset experimental

¡Gracias!

Gracias por usar Lighthouse y enviarnos tus comentarios. Tus comentarios nos ayudan a mejorar Lighthouse y esperamos que Lighthouse 6.0 te facilite mejorar el rendimiento de tu sitios web.

¿Cómo puedes proceder?

Nos apasiona la Web y nos encanta trabajar con la comunidad de desarrolladores para crear herramientas para para ayudar a mejorar la Web. Lighthouse es un proyecto de código abierto y todo lo que hacemos contribuyentes que ayudan con todo, desde correcciones de errores tipográficos hasta refactorizaciones de documentación, hasta nuevas y auditorías de software. ¿Te interesa contribuir? Desplázate por el repositorio de GitHub de Lighthouse.