¿Es Lighthouse una herramienta de rendimiento engañosa?

Google llama a Lighthouse «una herramienta automatizada de código abierto para mejorar la calidad de las páginas web». No es una herramienta de rendimiento per se, pero una característica destacada es dar retroalimentación sobre el rendimiento de una página web. Es un gran desafío obtener una puntuación de rendimiento superior para dispositivos móviles en Lighthouse. Si ha intentado obtener una puntuación máxima en Lighthouse, ¡es posible que haya dudado de usted mismo, de la herramienta o de ambos! Exploremos Lighthouse para ver por qué sucede esto.

¿Lighthouse es engañoso o es un malentendido?

Problema 1: la escala de puntuación no es lineal

Puede pensar que la puntuación de rendimiento es lineal, donde una puntuación de 100 es un 10 % mejor que una puntuación de 90, pero no es así . En realidad, la puntuación sigue una distribución curva, aquí está la curva de puntuación de la métrica Tiempo para interactuar (TTI) :

Google menciona esto en sus documentos cuando discuten cómo se codifican los puntajes por colores :

Para proporcionar una buena experiencia de usuario, los sitios deben esforzarse por tener una buena puntuación (90-100). Una puntuación «perfecta» de 100 es extremadamente difícil de lograr y no esperada. Por ejemplo, tomar una puntuación de 99 a 100 necesita aproximadamente la misma cantidad de mejora métrica que tomaría de 90 a 94.

Esta característica del cálculo de la puntuación de rendimiento significa que el esfuerzo que pones para mejorar tu puntuación variará dependiendo de dónde te encuentres en la curva. Para hacer una analogía, es como un corredor que pone el mismo esfuerzo durante una carrera:

• Correr cuesta abajo: el corredor correrá más rápido;
• En llano: el corredor correrá a su ritmo habitual;
• Cuesta arriba: el corredor correrá más lento.

Tal vez, no esperabas esto de un sistema de puntuación de cero a 100. ¡Yo no! Después de todo, la palabra porcentaje significa «una parte en cien». Este malentendido podría haberse mitigado si se hubiera elegido un rango o distribución diferente. Tal vez, ¿haría tropezar a menos personas si mostraran el puntaje como un punto en la curva para cada métrica?

Puede profundizar en los detalles del algoritmo de puntuación para comprenderlo más profundamente .

Problema 2: las puntuaciones pueden variar mucho

Si ejecuta Lighthouse en el mismo sitio web usando la misma computadora en la misma red varias veces, obtendrá resultados variables. Esto se siente raro al principio. ¿Estoy repitiendo exactamente lo mismo y obteniendo un resultado diferente? ¿Es esto un error o una realidad distorsionada?

Google dice lo siguiente sobre la variabilidad de la puntuación :

Gran parte de la variabilidad en la puntuación de rendimiento general y los valores de las métricas no se debe a Lighthouse. Cuando su puntaje de rendimiento fluctúa, generalmente se debe a cambios en las condiciones subyacentes. Los problemas comunes incluyen:

• Pruebas A/B o cambios en los anuncios que se publican
• Cambios en el enrutamiento del tráfico de Internet
• Pruebas en diferentes dispositivos, como una computadora de escritorio de alto rendimiento y una computadora portátil de bajo rendimiento
• Extensiones de navegador que inyectan JavaScript y agregan/modifican solicitudes de red
• Software antivirus

¿No se debe a Lighthouse? 🤔 ¿Estamos tratando de esposar a un rayo aquí? 😏

¿Qué tan variable puede ser?

Realice pruebas en diferentes hardware. El swing puede ser dramático. Zach Leatherman discutió esto en un artículo, The Art of Deception, Lighthouse Score Edition : ¡ejecutar Lighthouse en una Macbook (2012) versus una MacBook Air (M1, 2020) resultó en un cambio de 30 puntos ! Eso es mucho.

Parece que puede mitigar el impacto del hardware ejecutando Lighthouse a través de PageSpeed ​​Insights (PSI) , la herramienta de experiencia del usuario basada en la web de Google. Supongo que esto golpea un conjunto particular de servidores de manera consistente.

Google ofrece una lista completa de los factores técnicos para estas variaciones si desea entrar en el meollo del asunto.

El consejo en el repositorio GitHub de Lighthouse para reducir la variabilidad es «ejecutar Lighthouse varias veces y tener cuidado con la variabilidad antes de sacar conclusiones sobre un cambio que afecte el rendimiento». ¿Por qué no incorporar este comportamiento en Lighthouse para reducir la variabilidad?

WebPageTest es una herramienta de rendimiento web rival y su comportamiento predeterminado es dar una puntuación de rendimiento media basada en 3 ejecuciones. El equipo de WebPageTest ha criticado la consistencia de los resultados de Lighthouse . Es posible ejecutar Lighthouse a través de WebPageTest y afirman que pueden proporcionar resultados más consistentes de Lighthouse porque brindan un entorno de prueba más consistente.

Si bien es de esperar cierta variabilidad entre las pruebas, al proporcionar un entorno de prueba coherente para todas las ejecuciones de Lighthouse, WebPageTest ayuda a minimizar esa variabilidad y proporciona un punto de comparación realista y repetible.

Señalan el uso de Lighthouse de aceleración simulada como una fuente de variabilidad que podría mitigarse.

De forma predeterminada, Lighthouse utiliza una limitación simulada : la prueba se ejecuta sin limitación y, a continuación, Lighthouse simula el aspecto que podría tener una carga con limitación en función de los resultados sin limitación.

WebPageTest, por otro lado, utiliza la limitación a nivel de paquete para todas las pruebas, incluidas las pruebas de Lighthouse que se ejecutan a través de WebPageTest. Debido a que la limitación a nivel de paquete permite dar forma a la red a nivel de paquete, es un modelo mucho más preciso de las condiciones reales de la red (hay un estudio fascinante realizado por el equipo de Lighthouse sobre la precisión de la limitación si desea profundizar en la maleza del tema).

Problema 3: la gran mayoría de los sitios web se clasifican como no buenos

Volvamos a 2020, fue cuando Google hizo un gran cambio con respecto a su calificación de rendimiento: introdujeron Core Web Vitals . Quiero discutir este período de tiempo porque fue el último punto en el que hay datos comparables claros entre el conjunto de métricas de rendimiento (5 métricas) y Core Web Vitals (3 métricas). Core Web Vitals es un subconjunto del conjunto de métricas de rendimiento.

Core Web Vitals se presentó como un esfuerzo por simplificar las cosas. Para citar a Google:

Los propietarios de sitios no deberían tener que ser gurús del rendimiento para comprender la calidad de la experiencia que ofrecen a sus usuarios. La iniciativa Web Vitals tiene como objetivo simplificar el panorama y ayudar a los sitios a centrarse en las métricas más importantes, Core Web Vitals.

La edición Web Almanac 2020 demostró en su revisión de rendimiento de la web que Lighthouse informó que el 0,7 % de los sitios web tenían una puntuación de rendimiento móvil de 100, y el 5,7 % de los sitios web estaban en la categoría buena (90-100). ¿Fue realmente tan malo el rendimiento web? ¿O el listón está demasiado alto?

Estaba tratando de entender cómo Google elige los umbrales de categoría buenos y esta es su explicación más clara, específicamente para la métrica de pintura con contenido más grande (LCP) :

Según los datos reales del sitio web, los sitios de mayor rendimiento generan LCP en aproximadamente 1220 ms, por lo que el valor de la métrica se asigna a una puntuación de 99.

Profundizando un poco más, el modelo de curva de puntuación de Lighthouse utiliza datos de HTTPArchive para determinar dos puntos de control que luego establecen la forma de una curva logarítmica normal. El percentil 25 de los datos de HTTPArchive se convierte en una puntuación de 50 (el punto de control medio) y el percentil 8 se convierte en una puntuación de 90 (el punto de control bueno/verde).

¿Significa eso que el 8% superior de los datos representa una puntuación de 90 o más? ¡No entiendo su explicación para ser honesto! 😕 Aunque suena correcto según mi análisis anterior del Web Almanac.

Según los mismos datos (los datos del Informe de experiencia del usuario de Chrome que están disponibles a través del archivo HTTP) durante el mismo período aproximado (de agosto a octubre de 2020), el 22,3 % de las páginas aprobaron las 3 métricas de Core Web Vital con una puntuación «buena» . Más sitios web aprueban Core Web Vitals que obtienen una puntuación de rendimiento «buena» en Lighthouse.

En los años siguientes, se han realizado mejoras en la puntuación de rendimiento. La última versión de Lighthouse es la 10. Se utilizan cinco de las mismas métricas en la puntuación desde la versión 6, los umbrales y los pesos se han ajustado. Recientemente se introdujo una nueva métrica llamada Interacción hasta la próxima pintura (INP) y reemplazará a First Input Delay (FID) en marzo de 2024 como una métrica Core Web Vital.

Lo que encuentro extraño es que Lighthouse en las herramientas de desarrollo de Chrome no menciona Core Web Vitals en absoluto . Todavía da la puntuación de rendimiento en 5 métricas. Entonces, ¿por qué dar a las personas el conjunto de métricas más complejo y desafiante?

Para definir los umbrales, Google explica la ciencia detrás de los umbrales relacionados con los umbrales de percepción humana y la investigación HCI relevante . Los umbrales se basan en cómo percibimos las cosas, pero ¿cuán alcanzable es eso en la web? Google dice lo siguiente en su artículo sobre la definición de umbrales :

Para confirmar que se puede alcanzar un umbral, requerimos que al menos el 10% de los orígenes alcancen actualmente el umbral «bueno». Además, para asegurarnos de que los sitios bien optimizados no se clasifiquen incorrectamente debido a la variabilidad en los datos de campo, también verificamos que el contenido bien optimizado cumpla constantemente con el umbral «bueno».

Entonces, con todos los números mencionados, el requisito mínimo de Google es que el 10% de la web se clasifique como que cumple con el umbral de rendimiento «bueno» para Core Web Vitals. Eso parece que Core Web Vitals es un poco más indulgente que el conjunto de rendimiento general, pero sigue siendo un gran desafío.

Podemos ver las cifras de Core Web Vitals durante los últimos 3 años o más en HTTPArchive , el porcentaje de orígenes que pasan Core Web Vitals para dispositivos móviles ha aumentado del 22,6 % al 40,7 %.

Me encantaría ver el mismo gráfico para la puntuación de rendimiento general. Supongo que sería mucho más bajo.

Problema 4 – ¿Son datos de campo o datos de laboratorio?

Es importante entender la diferencia entre datos de laboratorio y datos de campo. Lighthouse es una herramienta de laboratorio, también conocida como herramienta sintética .

Los datos de laboratorio se recopilan en un entorno controlado con dispositivos predefinidos y configuraciones de red. Su uso principal es para depurar problemas de rendimiento porque proporciona un entorno de prueba y depuración reproducible. La desventaja es que los datos de laboratorio no capturan bien los cuellos de botella del mundo real.

Los datos de campo son datos de rendimiento recopilados de cargas de páginas reales que sus usuarios experimentan en la naturaleza. Las herramientas que recopilan datos de campo a menudo se denominan herramientas de monitoreo de usuarios reales (RUM). Los datos de campo capturan la verdadera experiencia del usuario en el mundo real. PageSpeed ​​Insights utiliza el conjunto de datos del Informe de experiencia del usuario de Chrome (CrUX) para aumentar los datos de laboratorio proporcionados por Lighthouse para las mismas métricas. Sin embargo, es posible que su página u origen no esté en el conjunto de datos porque no se puede descubrir públicamente o no hay una cantidad suficiente de visitantes para crear un conjunto de datos estadísticamente significativo.

Un buen ejemplo de esta dicotomía es ver un informe de PSI en web.dev , este es el blog de Google que tiene mucha información sobre Lighthouse. Puede ver el resultado de la prueba que realicé en esta URL: https://pagespeed.web.dev/analysis/https-web-dev/hp4cd34d4i?form_factor=mobile .

Lighthouse informó una puntuación de rendimiento de 96, ¡pero falló en Core Web Vitals! De un vistazo, ¡puede parecer un error! ¿Cómo ocurrió eso?

Esto se debe a que PSI informa diferentes cifras para la métrica LCP para Core Web Vitals y el puntaje de rendimiento general (vea los resaltados amarillos en la captura de pantalla a continuación). Las cifras son diferentes porque PSI usa datos de campo del conjunto de datos CrUX para Core Web Vitals (cuando está disponible) en la primera sección, mientras que los datos de laboratorio se usan para el puntaje de desempeño en la segunda sección.

¡Puedes perderte esto! Tener 2 conjuntos de métricas diferentes usando 2 conjuntos de datos diferentes uno al lado del otro fue confuso para mí inicialmente. Además, si se está enfocando en Core Web Vitals, hay 2 conjuntos basados ​​en el método de prueba:

• Pruebas de laboratorio en Lighthouse: pintura con contenido más grande (LCP), cambio de diseño acumulativo (CLS), tiempo total de bloqueo (TBT) .
• Pruebas de campo en PageSpeed ​​Insights: pintura con contenido más grande (LCP), cambio de diseño acumulativo (CLS), retraso de la primera entrada (FID) .

Anteriormente, el informe de PSI era más explícito acerca de si se utilizaban datos de campo o datos de laboratorio en los resultados que se mostraban. Aquí hay una captura de pantalla de ejemplo del informe PSI de hace unos años:

Creo que las actualizaciones de la interfaz de usuario se ven más bonitas pero son menos evidentes.

Puede leer más sobre cómo pensar en herramientas en Cómo pensar en herramientas de velocidad por web.dev .

Problema 5: ¿móvil o de escritorio?

Cuando las personas discuten y comparan las puntuaciones de Lighthouse, a menudo toman capturas de pantalla para llevar un registro. No hay ninguna indicación en la interfaz de usuario si los resultados son para dispositivos móviles o de escritorio . Los umbrales para el rendimiento móvil son más altos. Esta es una vía para errores y tergiversaciones.

Se ha discutido sobre agregar un indicador visual para que el modo sea más obvio, ¡pero no se ha incluido en las herramientas de desarrollo de Chrome!

Problema 6: las personas inevitablemente aspiran a puntajes casi perfectos

Inevitablemente, las personas aspiran a obtener una puntuación de rendimiento casi perfecta. Las personas se enorgullecen de lo que hacen y quieren señalar algo que hicieron y decir «mira el rendimiento de esto». Si crea una herramienta con umbrales altos, entonces pone el logro de una puntuación máxima fuera del alcance de algunos tipos de sitios web y aplicaciones web. No hay diferenciación entre una tienda web exigente como Amazon, una aplicación web como Google Docs y un sitio web personal.

Para resaltar esta situación, hay un hilo de discusión, «Instrucciones para obtener una puntuación de 100 en el móvil» en el repositorio de Lighthouse GithHub :

He usado el faro para monitorear un sitio web para el rendimiento. Sin embargo, es realmente difícil obtener una puntuación de 100 para el móvil. Solo puedo obtener la puntuación de 100 para el móvil con el sitio que contiene solo un texto estático sin css, javascript.

No estoy seguro si el equipo de Lighthouse considera que el sitio web contiene solo un texto estático es popular hoy en día para el sitio web moderno.

Por supuesto, la PWA aún no es estándar e incluso para la PWA, también debemos cargar para el modo de «estado completo».

A mí también me sorprendió esto hace un tiempo. Me acerqué a reconstruir mi sitio web personal comenzando con la página de inicio más simple posible. No tenía imágenes, una hoja de estilo bastante pequeña y creo que usé 3 fuentes web. ¡No obtuvo una puntuación móvil «buena»! Tuve que optimizar estos activos para subir a los 90.

Otra parte de esto es que cuando se trata de números, puede generar un elemento competitivo. Los marcos y las bibliotecas se apoyan en esto para promover la velocidad y el rendimiento de su oferta. Eleventy tiene una tabla de clasificación que utiliza un complemento basado en Lighthouse llamado speedlify para clasificar sitios web.

¿Es Lighthouse adecuado para comparar sitios de esta manera? 🤨

Pensamientos finales

Medir el rendimiento web es una propuesta difícil. No estamos haciendo productos homogéneos basados ​​en la web de manera uniforme. Esto hace que sea un desafío definir qué es un buen rendimiento para algo en la web. Google ha estado activo en la definición de lo que es un buen rendimiento a través de sus métricas y herramientas, y tiene mucho que decir al respecto.

Google llama a Lighthouse «una herramienta automatizada de código abierto para mejorar la calidad de las páginas web». Inspecciona algunas facetas diferentes de una página web en sus auditorías, como: rendimiento, SEO y accesibilidad. No es una herramienta de auditoría de rendimiento per se, pero tiene una gran presencia en ese espacio porque Google la creó, la puso en Chrome y anunció que las métricas de Core Web Vitals son un factor en su ranking de búsqueda .

Lighthouse es principalmente una herramienta de laboratorio que se utiliza para la depuración del rendimiento. Tiene algunas características que no son aparentes. El cálculo de la puntuación es bizantino, los resultados pueden ser muy variables y es muy difícil obtener una puntuación de rendimiento «buena» para dispositivos móviles. Como cubrí en este artículo, parte de esto se puede atribuir a la necesidad de comprender bastante bien el rendimiento web y Lighthouse, pero de alguna manera Lighthouse es engañoso.

Google dice que un puntaje de rendimiento móvil perfecto de 100 es «extremadamente difícil de lograr». Su enfoque de la clasificación de rendimiento es mucho más palo que zanahoria. A fines de 2020, según la clasificación de Lighthouse, se consideró que menos del 6 % de los orígenes web habían alcanzado un rendimiento «bueno», mientras que el 22,3 % superó las métricas de Core Web Vital. Core Web Vital es un conjunto de métricas más indulgente.

Core Web Vitals ha hecho que más empresas presten atención al rendimiento web. Como lo expresó Web Almanac en la revisión de desempeño de 2022 :

La decisión de Google de hacer de CWV [Core Web Vital] parte del ranking de búsqueda catapultó el rendimiento a la cima de las hojas de ruta de muchas empresas, especialmente en la industria de SEO. Los propietarios de sitios individuales ciertamente están trabajando arduamente para mejorar su rendimiento y desempeñaron un papel importante en las mejoras de CWV durante el último año, incluso si esos esfuerzos individuales son mucho más difíciles de detectar a esta escala.

El porcentaje de orígenes que pasan Core Web Vitals para dispositivos móviles en el momento de escribir este artículo es del 40,7 %.

El objetivo de la iniciativa Web Vitals era simplificar el panorama del rendimiento, en mi opinión, no lo ha hecho tan bien. Hay una falta de claridad y enfoque. Su puntuación de rendimiento todavía se basa en el conjunto completo de métricas. El conjunto completo de métricas se muestra en las herramientas de desarrollo de Chrome, que es donde muchas personas se encuentran con Lighthouse por primera vez.

En realidad, las métricas de CWV no se han adoptado por completo en ninguna parte. PSI muestra las métricas de CWV primero, pero hay 3 métricas más junto a ellas. No da un mensaje claro a los usuarios: ¿debería pasar CWV u obtener un puntaje de rendimiento «bueno» o ambos? ¿ Y cuál es una puntuación realista para su tipo particular de aplicación?

La variabilidad de puntuación significa que Lighthouse viene con advertencias. Generalmente no es una herramienta de depuración de rendimiento muy confiable. Dado que la variabilidad de la puntuación está sesgada por el rendimiento de su máquina cuando se ejecuta localmente, probablemente no sea una buena idea ejecutar Lighthouse en las herramientas de desarrollo de Chrome. Es mejor usar Lighthouse a través de WebPageTest, donde hace más para mitigar la variabilidad, o usar otras herramientas para depurar el rendimiento.

Recomendaría usar Lighthouse principalmente para comprender cómo Google clasifica su sitio web. Las oportunidades que presenta la auditoría Lighthouse le brindan una guía aproximada para mejorar el rendimiento, pero tómela con cuidado.