Webs falsamente rápidos: cómo se hackea la puntuación de Lighthouse

La comunidad del rendimiento web vive en un ciclo ilusorio. Muchos confunden la puntuación de Lighthouse con la velocidad del sitio web. Esto es aprovechado por los autores de plugins que se enfocan en mejorar esta métrica, sin realmente aumentar la velocidad del sitio.

En el mercado hay numerosos plugins que prometen acelerar el sitio web con un solo clic. Sin embargo, su impacto a menudo se limita a mejorar la puntuación de Lighthouse.

¿Qué encontrarás en este artículo?

1. Razones por las que el puntaje de Lighthouse nos causa dolor de cabeza, en lugar de medir la velocidad.
2. El comportamiento cuestionable del plugin Website Speedy. Otro ejemplo de malas prácticas anteriormente demostradas en los plugins WP-Optimize y el comportamiento límite de WP Rocket.
3. Nuestros argumentos sobre por qué creemos que postergar la carga de todo el JavaScript es más un truco para la puntuación de Lighthouse que una optimización real.

Vamos a sumergirnos en el problema de forma integral. Debemos comenzar con el principal culpable: la puntuación de Lighthouse y su percepción por parte de la comunidad no especializada.

¿Velocidad del sitio web? No es la puntuación de Lighthouse. Punto.

Puntuación de Lighthouse: una métrica incorrecta que a todos interesa#

Al incorporar clientes en PageSpeed.ONE, varias veces al mes hablo con alguien que quiere “mejorar su puntuación en PageSpeed Insights”. Ese círculo de colores en la parte inferior. Sí, la puntuación de Lighthouse.

Lo entendemos. Es un solo número, colorido, fácil de compartir con colegas a través de Slack… Pero la puntuación de Lighthouse es el resultado de una prueba sintética de una sola página, en un solo entorno, con una sola configuración. La composición y el peso pueden cambiar entre versiones de Lighthouse. Del mismo modo, Lighthouse en tu computadora mostrará un número diferente que en PageSpeed Insights.

Repitámoslo:

La puntuación de Lighthouse no es una métrica de velocidad del sitio web. Es un indicador técnico de diagnóstico.

La velocidad del sitio web no se origina en Lighthouse. Ocurre en los teléfonos de tus visitantes, en la wifi del bar, en un viejo smartphone chino con tres barras de señal, con diez pestañas abiertas y clics en el aviso de cookies.

Lighthouse no ve esto. No es un usuario. Lighthouse no desplaza, no hace clics, no inicia sesión, ni abre filtros de productos ni llega al checkout.

La verdadera velocidad la miden las métricas Core Web Vitals a partir de la base de datos Chrome UX Report. (Las diferencias entre el laboratorio y los datos de los usuarios se resumen en synth vs. CrUX vs. RUM.)

Un economista diría: “Claro, la ley de Goodhart”#

El economista Charles Goodhart escribió una vez una frase que hoy se enseña en universidades:

“Cuando una métrica se convierte en un objetivo, deja de ser una buena métrica.”

Aquí encaja a la perfección. Eso es exactamente lo que ha pasado con la puntuación de Lighthouse.

La gente quiere un número simple. Google lo muestra (a mi parecer, erróneamente) grande y colorido en PageSpeed Insights.

Los clientes preguntan a las agencias sobre la puntuación de Lighthouse. Algunas agencias prometen mejorarla. Y luego llegan los plugins que prometen lo mismo, solo que más rápido y sin esfuerzo.

Cuando un número de diagnóstico se convierte en un argumento comercial, surge un mercado para mejorarlo. Y cuando el cálculo es predecible, alguien comienza a hackear la métrica en lugar de optimizar el sitio web.

Postergar JavaScript no es optimización, sino trasladar el problema#

Muchos de los plugins “aceleradores” modernos tienen una casilla que puede aumentar la puntuación de Lighthouse en decenas de puntos en cinco segundos de trabajo. Retrasan la ejecución de todo el JavaScript hasta la primera interacción del usuario. Desplazamiento, clic, toque de pantalla.

¿Por qué funciona tan bien para hackear la puntuación de Lighthouse? Lighthouse carga y mide la página. No desplaza, no hace clics, no toca la pantalla. Por lo tanto, el JavaScript pospuesto nunca se ejecuta en la prueba. Esto elimina del cálculo, por ejemplo, el Total Blocking Time (TBT), la métrica con mayor peso en la puntuación de Lighthouse. También mejora la velocidad de carga (LCP).

La puntuación de Lighthouse sube, pero la velocidad del sitio no mejora. Para el usuario real, nada cambia. Solo se pospone. Y a menudo hasta el peor momento posible.

Ilustración de diferir JavaScript. Los scripts se cargan solo después de la interacción del usuario. Es un error.

En PageSpeed.ONE hemos optimizado cientos de sitios, pero nunca hemos recomendado esta técnica a nuestros clientes. ¿Cuáles son los riesgos de posponer todo el JavaScript?

1. Impacto negativo en las interacciones (INP). Un usuario llega a la página, lee un titular y hace clic. En ese momento, se ejecuta todo el JavaScript pospuesto que se había acumulado hasta entonces. El hilo principal del navegador se bloquea y el primer clic del usuario espera. Esto puede empeorar la métrica INP, que Google incluye en los Core Web Vitals.
2. Impacto negativo en los desplazamientos del diseño (CLS). Los scripts que generan contenido, como carruseles y personalizaciones, se ejecutan tarde si el JavaScript se pospone. En la prueba de Lighthouse, no se mide ningún desplazamiento porque ese código nunca se ejecutó. Así que no ves el valor real de CLS.
3. Funcionalidad de medición. La analítica, el consentimiento de cookies, el chat, las pruebas A/B y la medición de conversiones se posponen junto con todo lo demás. Los datos pueden no coincidir y nadie sabe por qué.
4. Desvalorización de la puntuación de Lighthouse. Como mencionamos, aunque la puntuación de Lighthouse no es una métrica de velocidad del sitio web, es útil para diagnosticar cambios u optimizaciones. Si no hay ningún JavaScript en la puntuación de Lighthouse, estás midiendo algo totalmente diferente a tu web.

Posponer todo el JavaScript es una mala técnica. Decidir qué se debe cargar cuándo y en qué orden es un trabajo de ingeniería que requiere conocimiento del sitio específico. Una casilla que pospone todo el JavaScript no reemplaza ese trabajo.

Y lo más problemático al final. Los proveedores de estas funciones generalmente no indican en ningún lugar lo que esto hará con la puntuación de Lighthouse y cómo puede afectar la velocidad para los usuarios reales. Si lo hicieran, el cliente entendería que a menudo no está comprando un sitio más rápido, sino solo un mejor número en la prueba.

WP-Optimize: el optimizador de puntuación de Lighthouse pillado#

En 2022, el desarrollador Gijo Varghese publicó una captura de pantalla del plugin WP-Optimize, donde se muestra que el JavaScript solo se carga si el navegador no es Lighthouse, GTmetrix, Chrome sin cabeza o Pingdom.

La muestra de WP-Optimize muestra el código que intenta detectar Lighthouse, Pingdom o GTmetrix.

El fabricante de este plugin de optimización para WordPress negó las acusaciones públicamente. Supuestamente se trata de una configuración específica de “Defer using JavaScript”.

De acuerdo, pero ¿por qué existe esa configuración en primer lugar? Regresamos a que tal configuración no la haría ningún optimizador de velocidad. Consejos generales para la velocidad en WordPress los tenemos en optimización de WordPress.

WP Rocket: el límite donde termina la optimización#

El conocido plugin de optimización WP Rocket enfrenta un problema similar. También contiene una función con el inocente nombre de Delay JavaScript Execution. Activar la casilla hace que todos los scripts esperen hasta que el usuario desplace la página, haga clic o toque la pantalla.

Alexander Goller ya escribió sobre esto en 2021 en un artículo, donde compara razonablemente este problema con el escándalo de emisiones de Dieselgate, donde los automóviles Volkswagen cambiaban la configuración del motor durante las pruebas de emisiones para cumplir con los valores requeridos.

¿Cuál es la situación hoy? Esta opción en WP Rocket aún existe. WP Rocket en la página de configuración de retraso de JavaScript solo menciona que es una de las optimizaciones más poderosas.

¿Una configuración inocente de plugin? No lo creo. En ninguna parte de la página de funciones WP Rocket menciona lo que esto hará con la puntuación de Lighthouse. Y eso es un problema.

WP Rocket solo menciona las ventajas de la configuración "Delay JS execution", pero no los riesgos.

Así que tanto WP-Optimize como WP Rocket aún venden esta característica, sin advertir que puede aumentar artificialmente la puntuación de Lighthouse y otros riesgos que mencioné anteriormente.

Website Speedy: ¿mejora de velocidad o de puntuación de Lighthouse?#

Website Speedy es una herramienta para varias plataformas que afirma ser un “Optimizador Automático de Velocidad de Sitios Web”. Uno de nuestros clientes creyó esto y usó este complemento durante meses pensando que estaba mejorando la velocidad del sitio.

Mi colega Michal Matuška descubrió que este complemento también puede aumentar artificialmente la puntuación de Lighthouse. Juzga por ti mismo.

Website Speedy en su página de inicio promete influir en la tasa de rebote y el ranking SEO.

Nuestra investigación sobre Website Speedy#

Comienza con el propio sitio web, donde se mezclan "impacto en las métricas comerciales" y "puntuación de Lighthouse". La velocidad ciertamente tiene un impacto en el negocio, pero esto no se puede vincular a una métrica sintética.

El propio marketing de estas extensiones se basa en usuarios que creen que la puntuación de Lighthouse es la velocidad del sitio web. Y hay muchos.

Los propios autores de Website Speedy lo admiten en la comunicación con nosotros:

“Nuestros paneles y documentación actualmente lideran con puntuaciones de laboratorio, y no explicamos que los resultados de laboratorio pueden diferir de lo que experimentan los usuarios reales.”

En el código fuente de Website Speedy encontramos detección de herramientas de prueba#

El comportamiento de Website Speedy intrigó a mi colega Michal, quien decidió examinar el código fuente. Este está fuertemente ofuscado, es decir, intencionadamente oscurecido.

En el código, después de decodificarlo a través de varios agentes de IA, encontramos una condición que decide si el JavaScript en el sitio web se ejecuta. ¿Y qué crees? Sí, no se ejecuta si detecta pruebas de velocidad.

Antes de la publicación, preguntamos a Website Speedy sobre su postura. El fundador Ishan Makkar respondió rápidamente:

“Nuestro script no detecta ni se ramifica en Lighthouse, PageSpeed Insights, GTmetrix, navegadores sin cabeza o cualquier entorno de prueba sintético.”

Añadió que revisó personalmente el código en varios sitios web de clientes en vivo y no pudo reproducir nuestros hallazgos. Y nos ofreció una demostración limpia con su versión de producción actual para que lo verifiquemos nosotros mismos.

La demostración llegó el 18 de agosto. Mi colega Michal Matuška encontró esto en su script:

Fragmento del código de la demo de Website Speedy. El truco lo ocultaron de nosotros.

La función se llama isAuditBot, es decir, "es un robot de auditoría". La primera línea devuelve false, por lo que en la demo que nos proporcionaron, toda la detección nunca se realiza. En el script del sitio web de nuestro cliente no estaba desactivada.

Por cierto, en ese resto de código muerto se prueban cadenas que recuerdan notablemente los nombres de las herramientas de medición sintéticas más comunes, a saber, GTmetrix, Lighthouse, PageSpeed, WebPageTest y Headless Chrome.

Como prueba de inocencia, recibimos una instalación donde la detección de herramientas de prueba estaba despojada de la forma más rápida posible.

¿Qué ocurrió cuando desactivamos Website Speedy en el sitio del cliente?#

Con el cliente, acordamos desactivar temporalmente Website Speedy. Vimos claramente qué ocurrió con la velocidad cuando el plugin dejó de funcionar. Casi nada.

La puntuación de Lighthouse ciertamente empeoró drásticamente...

Cambio de puntuación de Lighthouse en la página de inicio después de desactivar Website Speedy.

Después de desactivar Website Speedy, la puntuación de Lighthouse en la página de inicio cambió de 95 puntos a alrededor de 60. ¿Empeoró? No, se normalizó.

Sin embargo, la desactivación del complemento no tuvo ningún impacto en los Core Web Vitals:

Evolución de Core Web Vitals después de desactivar el complemento Website Speedy.

No vemos ningún cambio aparte de otras influencias que ocurren en el sitio:

• Un leve deterioro en la velocidad del sitio (LCP) correlaciona con una fluctuación en TTFB (respuesta del backend).
• CLS mejora con la modificación de otra característica del sitio y no está relacionada temporalmente.
• Es bueno recordar que los datos de CrUX de Google muestran un estado acumulativo de 28 días, por lo que los cambios tardan en manifestarse.

Después de desactivar Website Speedy, la puntuación de Lighthouse en el sitio de nuestro cliente se normalizó. Pero la velocidad del sitio permaneció sin cambios.

Nuestra metodología y lo que no afirmamos#

Para ser justos, debemos aclarar la metodología en nuestro caso de investigación sobre Website Speedy:

• Website Speedy no desea la divulgación del código fuente del plugin, por lo que solo publicamos el código fuente de la demo que nos proporcionaron y que difiere del código fuente del plugin.
• Experimentamos en el sitio web de uno de nuestros clientes.
• No tenemos aquí datos cuantitativos de múltiples proyectos.
• La desactivación del plugin y nuestra investigación del código se realizaron en julio de 2026.
• Además de desactivar el plugin, no optimizamos nada más en el sitio web.

El plugin Website Speedy en nuestro cliente mantenía la puntuación de Lighthouse alta, sin proporcionar a los usuarios reales un sitio más rápido de manera medible.

Por lo tanto, un problema está en los autores de los plugins. Pero el más grande está en los propios usuarios que pagan por estos plugins.

No deseches Lighthouse. Solo no lo conviertas en un objetivo#

Usa la herramienta Lighthouse como diagnóstico. Te encontrará una imagen lenta, un paquete de JavaScript innecesariamente grande o un CSS bloqueante. Para estos propósitos, Lighthouse es excelente.

Como métricas comerciales principales para la velocidad del sitio web, sigue los datos de usuarios reales. Core Web Vitals del Chrome UX Report o datos de tus propias mediciones (RUM). Observa todo el dominio y las plantillas más importantes en monitorización, no una sola URL de vez en cuando.

Sabemos que la demanda de una sola puntuación para todo es grande, por lo que en PageSpeed.ONE también usamos nuestro propio Puntuación PageSpeed.ONE, basado en datos de usuarios de las métricas Core Web Vitals.

En nuestra prueba de velocidad del sitio web también relegamos la puntuación de Lighthouse tanto como sea posible. En cambio, mostramos la tendencia de Core Web Vitals y una evaluación verbal del estado de la velocidad.

Si deseas verificar un caso similar por ti mismo, el siguiente procedimiento puede ayudarte.

Cómo verificar un salto sospechoso en la puntuación de Lighthouse#

Lista de verificación para detectar hackeos sospechosos de la puntuación de Lighthouse:

• Comienza preguntando si la puntuación aumentó sospechosamente rápido después de la instalación del plugin o un cambio en la configuración.
• Compara las solicitudes de red y el JavaScript ejecutado en Lighthouse con una carga normal en el navegador.
• Verifica el primer desplazamiento, clic, aviso de cookies, apertura de filtro, formulario y checkout. Lighthouse no desplaza ni hace clics, pero el usuario sí.
• Revisa los datos de los usuarios (CrUX o RUM) antes y después del cambio. Un puntaje de laboratorio más verde sin mejora en los datos de usuarios no es una victoria.
• Y principalmente: deja de comprar plugins que prometen aceleraciones milagrosas con un solo clic.

La próxima vez que alguien te ofrezca un plugin que milagrosamente aumente la puntuación en cinco minutos, pregúntale sobre una cosa:

¿Qué impacto tendrá en la velocidad real para los usuarios, por ejemplo, Core Web Vitals? Si no puede responder a esta pregunta, conoces la respuesta por ti mismo.

Ten sitios rápidos. Y mide la velocidad correctamente.

Etiquetas:Web PerformanceLighthouse