Auditamos webs de pymes españolas cada semana. Los problemas de velocidad siempre vienen de los mismos sitios. Te los contamos sin rodeos, con las métricas que Google usa de verdad en 2026.
La semana pasada auditamos la web de una clínica dental en Madrid. PageSpeed Insights le daba un 34 en móvil. El dueño estaba convencido de que era culpa del hosting y llevaba meses pagando más por un plan "premium".
El hosting no era el problema. Era una imagen de portada de 4,2MB en JPEG sin comprimir. Un cambio de 10 minutos subió el score a 78.
Este es el tipo de cosas que encontramos constantemente. Los problemas de velocidad casi siempre vienen de los mismos sitios.
Las métricas que Google usa en 2026
Antes de hablar de soluciones, vale la pena entender qué mide Google. Muchas webs siguen optimizando para el FID (First Input Delay), que Google reemplazó en 2024 por el INP.
LCP (Largest Contentful Paint): cuánto tarda en aparecer el elemento más grande de la pantalla. Objetivo: menos de 2,5 segundos. El culpable habitual: una imagen hero enorme sin optimizar.
INP (Interaction to Next Paint): cuánto tarda la web en responder cuando el usuario hace clic, escribe o toca algo. Objetivo: menos de 200ms. El culpable habitual: demasiado JavaScript ejecutándose en el hilo principal.
CLS (Cumulative Layout Shift): cuánto se mueven los elementos mientras carga la página. Ese momento frustrante en que vas a pulsar un botón y se desplaza justo antes. Objetivo: menos de 0,1.
El problema número uno: las imágenes
El 70% de las webs que auditamos tienen imágenes mal optimizadas como causa principal de su LCP alto. La corrección es directa:
El segundo problema: el JavaScript
Las webs modernas cargan mucho JavaScript. El problema es que todo ese JS bloquea el hilo principal y hace que la web parezca congelada aunque visualmente se vea bien.
El tercer problema: el servidor
El TTFB (Time to First Byte) mide cuánto tarda el servidor en empezar a responder. Si supera los 600ms, algo está mal. Las causas más comunes: hosting compartido saturado, consultas a base de datos sin índices, o ausencia de caché.
Con Next.js en Vercel el TTFB habitual está por debajo de 80ms. Con un WordPress en un hosting compartido de 5€/mes puede superar los 2 segundos antes de que el navegador haya recibido ni un byte.
Cómo medir antes de arreglar
No optimices a ciegas. Mide primero con estas herramientas:
En Codelvia incluimos auditoría de Core Web Vitals antes de cada lanzamiento, con objetivo contractual de Lighthouse 90+ en móvil. En migraciones desde WordPress, el salto medio que conseguimos es de 40-50 puntos. Si quieres que revisemos la tuya, contacta con nosotros.
¿Tienes un proyecto en mente?
Cuéntanos qué quieres conseguir.