Rendimiento en un sitio estático de 1.382 páginas: qué medimos con Lighthouse y qué no sirve medir

Tenemos un sitio estático de 1.382 páginas hecho con Astro y publicado en Cloudflare. Esta semana lo medimos con Lighthouse 13 contra producción para ver si las páginas nuevas (un directorio de registros y varias notas) bajaban los puntajes. Estos son los números y lo que aprendimos al medir.

Los resultados

Cinco páginas de plantillas distintas, medidas en modo escritorio simulado de Lighthouse:

El desplazamiento del diseño (CLS) dio entre 0 y 0,002, y el tiempo de bloqueo (TBT) dio 0 ms en todas.

Lo primero: dos puntos son ruido

La misma página del directorio dio 98 en una corrida y 100 en la siguiente. La portada del sitio, que usamos de referencia, dio 98 en esa misma tanda. Una diferencia de uno o dos puntos entre corridas del mismo código no es una regresión: es variación del entorno de medición. Antes de buscar un problema, repetí la medición.

Qué ayudó, en concreto

• Scripts propios con hash y minificados. En el build, los scripts de la carpeta pública se renombran con un hash de su contenido y se minifican. En una corrida del build bajaron de 106,2 KB a 36,1 KB (66% menos), con las referencias reescritas en todas las páginas.
• Módulos cargados después del primer pintado. Los scripts que no hacen falta para ver la página se cargan con baja prioridad.
• Un solo script en línea, habilitado por hash. La política de seguridad de contenido (CSP) permite ese script por su hash, sin abrir unsafe-inline.
• Sin analítica de terceros en las páginas. No cargamos Google Analytics ni etiquetas de seguimiento: medimos el tráfico con Search Console. Cada script externo cuesta puntos de rendimiento, y el dato que aporta ya lo da el buscador.

Qué medir y cómo

• Una página por plantilla, no solo la portada. Una prueba de accesibilidad de la portada nunca va a encontrar un problema de contraste que vive en otra plantilla. En nuestro caso, un enlace dentro de un párrafo gris daba contraste insuficiente solo en la página de la API.
• Rendimiento contra producción, el resto en local. Cloudflare comprime el HTML y en local no se reproduce, así que el puntaje de rendimiento local sale peor de lo que es. Accesibilidad, buenas prácticas y SEO sí se pueden medir en local con las mismas cabeceras de seguridad.
• No lo corras en cada build. Necesita un navegador y tarda unos 30 segundos por página. Lo corremos antes de cambiar una plantilla o los estilos.

Un detalle que nos engañó

Una página de una calculadora salía en rojo en buenas prácticas en el entorno local por un error 502 en la consola del navegador. Era el servicio de valores que no existe en local. En producción, la misma página daba 100 y cero errores. Antes de tocar código, confirmá el problema contra producción.

Las páginas medidas son parte del sitio: podés ver el directorio de registros del automotor o la sección de herramientas y medirlas por tu cuenta.