El rendimiento de una página no es un valor que se fija el día del lanzamiento. Es un valor que cambia durante los seis meses siguientes. Un tercero añade una etiqueta, se carga otra fuente, se actualiza una librería de componentes, se reexporta una imagen. Ninguno de esos cambios es un fallo. Juntos pueden producir una regresión que ninguno causó por sí solo.
Y normalmente no te enteras. La página carga, no da error, la conversión no cambia de forma visible. Simplemente se ralentiza.
Tres métricas, tres preguntas distintas
LCP (Largest Contentful Paint) — ¿cuándo apareció el elemento más grande? De esto depende la sensación de "la página ha cargado".
Cuando se degrada, los sospechosos habituales: una imagen principal sin optimizar, una fuente que se carga en el camino crítico, otro paquete de JavaScript añadido sin motivo claro.
CLS (Cumulative Layout Shift) — ¿cuánto se movió la página mientras cargaba? Es la razón principal de que los usuarios pulse donde no deben.
Cuando se degrada: una imagen sin dimensiones, un anuncio que carga tarde, un banner inyectado a posteriori.
INP (Interaction to Next Paint) — tras un clic, ¿cuánto tarda la interfaz en responder?
Cuando se degrada: trabajo en el hilo principal, manejadores de eventos, librerías pesadas.
Por qué medir de forma continua y no con una sola nota
El enfoque habitual: pegar la URL en PageSpeed Insights y sacar una nota. Una medición, tres problemas.
1. Un momento, una medición. Los usuarios reales llegan desde dispositivos, redes y horarios distintos. Una nota de laboratorio es un escenario y no muestra la distribución real.
2. Te pierdes el momento de la regresión. La métrica empeoró por un botón. Nadie miraba en ese instante. Cuando alguien lo nota, ya no sabes qué cambio lo causó.
3. Mirar tu servidor no basta. Estas métricas se miden en el dispositivo del usuario. Tu servidor puede estar perfectamente sano mientras la métrica se degrada.
La medición continua resuelve el segundo: ves si la métrica realmente se movió tras cada cambio.
Cómo detectar una regresión
1. Relaciona la medición con el cambio
Una página cambió, el LCP empeoró. Si no puedes unir esos dos hechos, siempre dirás "probablemente fue ese cambio" en lugar de saberlo.
Lo que funciona en la práctica: cada registro de cambio lleva el valor de la métrica en ese momento. Dos semanas después miras atrás y ves qué cambio movió la métrica y cuánto.
Para eso, tu historial de cambios tiene que llevar el porqué, no solo "algo cambió". Para eso sirve un archivo de evidencias.
2. Vigila por página, no por sitio
Una media del sitio engañosa. Si tu portada se ha acelerado y tus páginas de producto se han ralentizado, la media puede no moverse.
Vigila por página. La página que se ha roto suele ser una sola, y ahí es donde está el dinero.
3. Ajusta los umbrales con datos reales
Si el LCP de una página es de 2,4 s y tu umbral está en 2,5, cada cambio la deja justo por debajo del límite. El siguiente cambio pequeño lo cruza y salta una alerta, aunque en realidad no haya cambiado nada.
Es un caso de libro de fatiga por alertas: si el umbral se queda en "algo cambió", tu sistema está vigilando píxeles, no regresiones.
Qué ralentiza las páginas, por orden
Las métricas te dicen que algo se ha degradado. No te dan una lista de tareas, y es deliberado: una métrica es un diagnóstico, no un tratamiento.
Las cuatro causas que más vas a encontrar, en este orden:
Imágenes. La más común. Sin dimensiones, sin formatos modernos, más grandes de lo necesario. Por sí solas, la causa más frecuente de un LCP malo.
Paquetes de JavaScript. Cada librería añadida ocupa el hilo principal. Degrada INP y, indirectamente, LCP.
Fuentes. Cada familia y cada peso es un archivo aparte. Sin display=swap, el
texto no se ve hasta que llega la fuente.
Scripts de terceros. Anuncios y managers de etiquetas. Lo único fuera de tu control que afecta directamente al rendimiento, y lo que más se añade tarde.
Por dónde empezar
Cuatro pasos, en este orden:
- Elige tres tipos de página. Portada, listado, producto. Donde está el dinero. No todas.
- Mide una semana sin cambiar nada. Así aprendes cuáles son tus números reales.
- Ajusta los umbrales según lo que viste, por página. Pueden ser distintos en cada una.
- Solo entonces conecta el seguimiento de cambios. A partir de ahí, "la métrica ha empeorado" se responde con "por este cambio".
Esto es el equivalente a Core Web Vitals de las preguntas de qué comprobar al elegir una herramienta: qué métricas mide, cuánto historial guarda y si el umbral es configurable.
Resumen
- Las Core Web Vitals se degradan de forma continua y silenciosa, porque la página sigue funcionando.
- Una nota puntual se pierde el momento de la regresión; la medición continua lo detecta.
- Vigila por página: una media del sitio oculta la página que se rompió.
- Las métricas diagnostican, no curan. Las cuatro causas habituales: imágenes, JavaScript, fuentes y scripts de terceros.
- La primera semana es para medir, no para cambiar.
La misma lógica aplicada a cómo se ve una página está en qué es la regresión visual.