La puntuación de Lighthouse no es el resultado de la optimización, sino un reflejo de la esencia de la arquitectura

La comparación entre sitios con puntuaciones altas y bajas en Lighthouse revela hechos sorprendentes. Los sitios con puntuaciones altas no son necesariamente los que han dedicado más tiempo a la optimización, sino que suelen ser sitios con un diseño simple que no sobrecarga al navegador con tareas innecesarias.

Lo que indican las métricas de rendimiento

Lighthouse no mide la clasificación de herramientas o frameworks. Lo que evalúa son resultados reales:

• La velocidad con la que un usuario ve contenido relevante
• El tiempo que JavaScript ocupa en el hilo principal
• La estabilidad del diseño durante la carga
• La accesibilidad y rastreabilidad de la estructura del documento

Estas métricas (TTFB, LCP, CLS) son reacciones en cadena a decisiones tomadas durante la implementación. En particular, están directamente relacionadas con la cantidad de cálculo que el navegador realiza en tiempo de ejecución.

Una arquitectura que depende de grandes bundles del lado cliente inevitablemente tendrá puntuaciones bajas. Por otro lado, sitios que se centran en HTML estático y minimizan la lógica del lado cliente logran un rendimiento predecible y estable.

La codicia de JavaScript: el verdadero culpable de la caída en rendimiento

Un problema común en muchos proyectos auditados es la ejecución de JavaScript.

No se trata de un problema de calidad del código, sino de una restricción fundamental del entorno de un navegador, que es un solo hilo. La ejecución de frameworks, la hidratación, la resolución de dependencias y la inicialización del estado consumen tiempo antes de que la página sea interactiva.

Incluso funciones interactivas simples a menudo requieren bundles excesivamente grandes. Las arquitecturas que asumen JavaScript por defecto necesitan ajustes continuos para mantener el rendimiento.

En contraste, arquitecturas que consideran JavaScript como una opción voluntaria tienden a ofrecer resultados más estables. Esta diferencia filosófica se refleja claramente en las puntuaciones de Lighthouse.

El proceso de construcción que elimina la incertidumbre

La renderización previa elimina varias variables en la ecuación del rendimiento:

• No es necesario el coste de renderizado en el servidor en tiempo de solicitud
• No se requiere bootstrap del lado cliente para mostrar contenido
• El navegador recibe HTML completo y predecible

Como resultado, métricas como TTFB, LCP y CLS mejoran de forma natural. Aunque no garantizan una puntuación perfecta, reducen significativamente las posibilidades de fallo.

Aprendiendo de ejemplos reales

En un proyecto de reconstrucción de un blog personal, se consideraron varias aproximaciones. Configurar React con hidratación fue flexible, pero requería atención continua al rendimiento, reevaluando estrategias de renderizado, obtención de datos y tamaño del bundle con cada nueva funcionalidad.

En cambio, un enfoque basado en HTML estático, tratando JavaScript como una excepción, fue radicalmente diferente. La elección de Astro se basó en que su diseño restrictivo coincidía con las hipótesis que queríamos validar.

Lo sorprendente no fue la puntuación inicial, sino la estabilidad del rendimiento con el tiempo:

• No se reduce la puntuación tras publicar contenido nuevo
• Los pequeños elementos interactivos no generan advertencias en cadena
• La línea base se mantiene estable

En esta arquitectura, la puntuación de Lighthouse no es un objetivo, sino una consecuencia natural.

La realidad de los compromisos

Es importante entender que este enfoque no es universal. Las arquitecturas centradas en sitios estáticos no son adecuadas para aplicaciones altamente dinámicas y con estado. En escenarios que requieren autenticación, datos en tiempo real o gestión compleja del estado del cliente, la implementación se vuelve más compleja.

Frameworks que asumen renderizado en el cliente ofrecen mayor flexibilidad para estos casos, a costa de mayor complejidad en tiempo de ejecución.

Lo fundamental es que no existe una única mejor opción; la elección de arquitectura afecta directamente las métricas de Lighthouse.

Por qué las puntuaciones se estabilizan o caen

Lo que Lighthouse revela no son logros de optimización, sino la complejidad del sistema.

Los sistemas que dependen de cálculos en tiempo de ejecución tienden a acumular complejidad a medida que se añaden funciones. Los sistemas que hacen trabajo en build, en cambio, mantienen esa complejidad bajo control por defecto.

Esta diferencia explica por qué algunos sitios requieren ajustes constantes para mantener el rendimiento, mientras otros permanecen estables con intervenciones mínimas.

La decisión esencial

Una puntuación alta en Lighthouse generalmente no resulta de herramientas de optimización activa, sino de una arquitectura que minimiza la carga en la carga inicial del navegador. Es una consecuencia natural, no un objetivo en sí mismo.

Aunque las herramientas y tendencias cambien, los principios fundamentales permanecen: incorporar el rendimiento como una restricción en el diseño, no como un objetivo separado. Así, Lighthouse deja de ser una meta a perseguir y pasa a ser un indicador a observar.

Este cambio no se trata de elegir qué framework usar, sino de decidir en qué puntos aceptar la complejidad.