Google mide la experiencia de tu sitio con tres números, y los usa como factor de posicionamiento. La mayoría de los sitios que revisamos fallan al menos uno, y casi siempre por causas que se arreglan en horas.
Puedes ver los tuyos en PageSpeed Insights pegando tu dirección. Un detalle importante antes de empezar: esa herramienta muestra dos cosas distintas. El puntaje grande de colores es una simulación en laboratorio. Arriba, si tu sitio tiene tráfico suficiente, aparecen los datos de campo: mediciones de usuarios reales. Esos son los que Google usa para posicionar. Un sitio puede tener 95 en laboratorio y fallar en campo.
LCP — cuánto tarda en verse lo principal
Mide desde que alguien pide la página hasta que aparece el elemento más grande visible: normalmente la imagen del encabezado o el titular. Bueno: bajo 2,5 segundos.
Es el que más sitios fallan, y casi siempre por lo mismo.
La imagen del hero pesa demasiado. Fotos de cuatro mil píxeles de ancho servidas para mostrarse en mil doscientos. La solución es servir la imagen en el tamaño real en que se muestra, en formato WebP o AVIF, y darle fetchpriority="high" para que el navegador la pida primero.
Hay recursos bloqueando el renderizado. Hojas de estilo y scripts en el <head> que el navegador debe descargar y procesar antes de dibujar nada. Los scripts que no son críticos van con defer o al final del documento.
Las fuentes tardan. Si el texto principal usa una tipografía web y esta no llegó, el navegador puede no mostrar nada hasta que llegue. Usa font-display: swap y precarga la fuente del titular.
El servidor responde lento. Si el tiempo hasta el primer byte ya es de un segundo, nunca vas a llegar a 2,5. Esto es hosting o arquitectura: un sitio que arma cada página con base de datos en cada visita parte con esa desventaja. Un sitio estático servido desde CDN parte con el primer byte en decenas de milisegundos.
INP — cuánto tarda en responderte
Reemplazó al antiguo FID en 2024. Mide cuánto demora la página en reaccionar cuando haces clic, tocas o escribes. Bueno: bajo 200 milisegundos.
La causa es casi siempre la misma: demasiado JavaScript ocupando el hilo principal. El navegador tiene un solo hilo para ejecutar código y responder a la interacción; si está ocupado procesando scripts, tu clic espera.
Qué hacer: audita cuánto JavaScript envías realmente y saca lo que no se usa. Revisa los scripts de terceros —chats, mapas, píxeles de publicidad, herramientas de analítica— que suelen ser la mayor parte del peso. Carga diferido lo que no se necesita al inicio: un chat de soporte no tiene por qué cargar antes de que la página sea usable.
Aquí es donde la arquitectura de islas de Astro cambia el resultado de raíz: solo los componentes que declaras interactivos envían JavaScript. El resto de la página es HTML puro, que responde instantáneamente porque no hay nada que ejecutar.
CLS — cuánto se mueve el contenido
Mide si los elementos saltan mientras la página carga. Es el que arruina la experiencia de forma más visible: vas a tocar un botón y justo ahí aparece un banner y tocas otra cosa. Bueno: bajo 0,1.
Las causas son pocas y muy identificables:
Imágenes sin dimensiones. Si no declaras width y height, el navegador no reserva el espacio y el contenido salta cuando la imagen llega. Poner los atributos —aunque uses CSS para el tamaño real— resuelve la mayoría de los casos.
Anuncios, banners o avisos insertados dinámicamente. Todo lo que aparece después de la carga y empuja contenido. Reserva el espacio con una altura mínima desde el principio.
Fuentes que cambian de tamaño al cargar. El texto se dibuja con la fuente de respaldo y luego cambia a la definitiva, y si las métricas difieren mucho, todo se reacomoda. Se corrige eligiendo una fuente de respaldo con métricas similares y ajustándola con size-adjust.
Contenido inyectado arriba de lo visible. Una barra de aviso de cookies que aparece al segundo y empuja la página entera hacia abajo.
El orden de trabajo que funciona
- Mide con datos de campo, no solo laboratorio.
- Arregla la imagen del hero. Suele ser la mitad del problema de LCP.
- Pon dimensiones a todas las imágenes. Suele ser casi todo el CLS.
- Saca o difierí los scripts de terceros. Suele ser casi todo el INP.
- Recién después mira el resto.
Estos cuatro pasos mueven la aguja en la mayoría de los sitios y no requieren rehacer nada.
Una advertencia sobre el puntaje
Perseguir el 100 en Lighthouse es un mal objetivo. El puntaje es una simulación con condiciones fijas y no siempre refleja lo que viven tus usuarios reales. Un sitio con 85 y datos de campo en verde está mejor que uno con 98 y campo en rojo.
Optimiza para los umbrales de campo —2,5 s, 200 ms, 0,1— y deja el puntaje donde caiga.
Si quieres que midamos tu sitio con datos reales y te digamos exactamente qué está pesando, escríbenos.