Nota técnica
Lighthouse mide en "laboratorio" (simula 4G lento, CPU throttled). Para el ranking real, Google usa datos de campo de usuarios reales (CrUX). Un 100 en Lighthouse no garantiza que todos los usuarios vean lo mismo, pero demuestra que el sitio tiene el potencial óptimo. Y eso impacta positivamente en los datos reales.
## Fix 2: Google Analytics se cargaba DOS veces
Este fue un error mío. Tenía GA en el `` de Layout.astro (para todos los visitantes) Y en el componente CookieConsent (solo si aceptaban cookies). Resultado: 153 KiB de JS innecesario para usuarios que no habían aceptado cookies, y un problema de GDPR.
**Solución:** Eliminé el script de Layout y dejé solo el de CookieConsent, que carga GA únicamente tras el consentimiento.
Ahorro: 153 KiB de JS + 196 ms de hilo principal. Y ahora es legal.
## Fix 3: El ChatWidget mataba el Speed Index
El componente ChatWidget.tsx usa React con `useState`, `useEffect`, `useCallback`... todo eso se hidrataba con `client:load`, lo que significa que el navegador lo descargaba y ejecutaba **antes de pintar la página**.
El chat pesa poco (~5 KiB), pero arrastra React entero (54 KiB). El problema no era el tamaño del archivo — era el **coste de hidratación**: la CPU del móvil pasaba 80ms "desempaquetando" React y evaluando el componente antes de permitir que el usuario hiciera scroll. Esos 80ms de Total Blocking Time (TBT) son tareas largas que congelan el hilo principal del navegador.
**Solución:** Implementé un **patrón Facade**. Creé un `ChatWrapper.astro` que renderiza un botón estático en HTML puro (0 JavaScript). Solo cuando el usuario hace clic, un `import()` dinámico carga React y el chat completo. El JavaScript se ejecuta en un momento de ocio del navegador, no durante el renderizado crítico.
```
## Fix 4: Contraste WCAG — de 96 a 100 en accesibilidad
Lighthouse marcaba varios elementos con contraste insuficiente. La lección: **el mismo color puede fallar en un fondo y pasar en otro**. Hay que calcular contra el fondo real.
Fechas blog (sobre blanco)
text-gray-400 (2.95:1) → text-gray-500 (5.74:1)
Footer (sobre gray-900)
text-gray-500 (3.67:1) → text-gray-400 (~7:1)
Enlace cookies (sobre oscuro)
text-primary (2.2:1) → text-indigo-400 (5.1:1)
Badges servicios (sobre primary)
bg-white/20 (4.19:1) → border-white/40 (6.28:1)
Metrica
Antes
Despues
Mejora
Rendimiento
~96
100
+4
Accesibilidad
96
100
+4
Practicas recomendadas
~97
100
+3
SEO
~95
100
+5
FCP
~0.9s
0.3s
-67%
LCP
~1.0s
0.3s
-70%
Speed Index
~0.9s
0.5s
-44%
TBT
~20ms
0ms
-100%
CLS
0
0
—
Los valores "Antes" de escritorio son estimaciones basadas en las metricas de movil y las diferencias tipicas entre Lighthouse movil/escritorio.
Metrica
Antes
Despues
Mejora
Rendimiento
89
100
+11
Accesibilidad
96
100
+4
Practicas recomendadas
~98
100
+2
SEO
92
100
+8
FCP
2.6s
1.2s
-54%
LCP
3.2s
1.4s
-56%
Speed Index
2.6s
1.2s
-54%
TBT
80ms
0ms
-100%
CLS
0
0.002
—
## Sobre la variabilidad de las puntuaciones
Antes de que alguien se obsesione con mantener el 100 exacto, conviene una aclaración: **una puntuación de Lighthouse no es un examen con nota fija**. Es una estimación en condiciones de laboratorio controladas (CPU throttled, red 4G simulada), y tiene una variabilidad inherente de entre 2 y 5 puntos entre ejecuciones consecutivas. Google lo documenta abiertamente en su guía de [Lighthouse Variability](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring#how_is_the_score_calculated).
La curva de puntuación es logarítmica: subir de 50 a 70 es relativamente sencillo; subir de 95 a 100 requiere ajustes marginales que en muchos casos no tienen impacto perceptible para el usuario. La diferencia real entre un 92 y un 100 en rendimiento no la nota nadie navegando tu web — la nota Lighthouse, que simula un Moto G4 con CPU reducida al 4x de lentitud.
Lo que sí importa de verdad es el color: **estar en verde (90+) significa que tu web está en el cuartil superior** de la distribución de rendimiento que Google considera aceptable. Y para el posicionamiento real, Google utiliza datos de campo (CrUX, medidos con usuarios reales), no las puntuaciones de laboratorio. Un 90 consistente en campo es más valioso que un 100 en laboratorio que no se sostiene.
Mi objetivo con la optimización fue eliminar problemas estructurales (render-blocking, JS innecesario, contraste insuficiente), no perseguir un número. El 100 es la consecuencia de haber resuelto las causas, no la meta.
## Lo que aprendí
**En un sitio estático, el rendimiento no se mejora con caché de servidor.** Se mejora eliminando lo que bloquea el hilo principal del navegador. JavaScript innecesario, fuentes externas, hidratación prematura.
Cada byte de JS que quitas del renderizado inicial es un paso hacia el 100.
Y si tienes un componente interactivo que el 90% de los usuarios no va a usar en los primeros segundos, **no lo cargues**. Ponle una fachada estática y cárgalo cuando te lo pida.
## Cómo evito que vuelva a bajar a 89
El rendimiento no es un destino, es un estado. Mi CI/CD en GitHub Actions builda y despliega automáticamente en cada push a `main`. Si un nuevo componente o un post pesado degrada las métricas, lo detecto en el siguiente deploy. La clave es que los patrones que he aplicado (self-hosting, facade, sin JS inicial) son estructurales — no dependen de un plugin que se actualiza y rompe todo.
---
¿Tu web está en la zona roja o naranja?
Cada segundo de carga te cuesta conversiones. Auditoría Lighthouse + plan de acción concreto.
Audita mi web →