cache.lat
El 24 de marzo de 2026, Google empezó a desplegar una actualización central de su algoritmo. Para cuando la mayoría de los dueños de sitios se dieron cuenta, sus posiciones ya habían cambiado. No tocaron una línea de código. No actualizaron ningún plugin. No cambiaron de tema. Google simplemente le subió el peso a Core Web Vitals como señal de ranking — y WordPress, que mueve alrededor del 43% de todo internet, tiene la peor tasa de aprobación de cualquier plataforma grande.
El problema ya existía, solo que ahora pesa más
Según el Web Almanac 2025 de HTTP Archive, apenas el 45% de los sitios WordPress en móvil logra un puntaje "bueno" en Core Web Vitals. Compará eso con Wix (74%), Shopify (65%) o Duda (85%). WordPress no está cerca de esa carrera — la está perdiendo por un margen grande, y mejoró solo 4 puntos porcentuales en todo 2025. A ese ritmo, le va a tomar casi una década alcanzar donde está Wix hoy.
Las causas son conocidas: temas pesados, constructores visuales que generan HTML inflado, docenas de plugins metiendo su propio JavaScript y CSS, y hosting compartido barato con tiempos de respuesta de servidor lentos. Nada de esto es nuevo. Lo nuevo es que Google ahora lo pesa mucho más al decidir tu posición.
Las tres métricas que definen si aprobás o no
- LCP (Largest Contentful Paint): tiene que estar por debajo de 2.5 segundos. Mide cuánto tarda en aparecer el elemento más grande visible de tu página.
- INP (Interaction to Next Paint): tiene que estar por debajo de 200 milisegundos. Reemplazó a FID en 2024 y mide qué tan rápido responde tu sitio cuando alguien interactúa con él.
- CLS (Cumulative Layout Shift): tiene que estar por debajo de 0.1. Mide cuánto se mueve tu contenido de forma inesperada mientras carga.
Google evalúa estas tres al percentil 75 de tus visitantes reales, no en un test de laboratorio aislado. Aprobás solo si cumplís las tres al mismo tiempo.
Por qué el LCP es donde más rápido se nota el problema
De las tres métricas, LCP es la que más directamente depende de qué tan rápido responde tu servidor antes de que el navegador siquiera empiece a dibujar algo. Si tu WordPress tarda 2-3 segundos solo en generar el HTML de cada visita (ejecutando PHP, consultando la base de datos, armando la página desde cero cada vez), ya perdiste el margen antes de que cargue la primera imagen.
Acá es donde el caché de página hace la diferencia más grande de cualquier optimización individual: reduce el tiempo de primera respuesta de 2-3 segundos a menos de 200 milisegundos, según coinciden varias guías técnicas actualizadas de 2026. No es una mejora marginal — es la optimización de mayor impacto que existe para WordPress en hosting compartido.
Qué podés hacer esta semana
- Corré tu sitio por Google PageSpeed Insights y anotá tus tres números actuales — necesitás una base antes de cambiar nada.
- Revisá el reporte de Core Web Vitals en Google Search Console — te muestra qué URLs específicas están fallando, con datos reales de tus visitantes.
- Si tu LCP está arriba de 2.5s, empezá por ahí: activá caché de página real (HTML ya generado, sin ejecutar WordPress en cada visita) antes de tocar imágenes o JavaScript.
- Repetí la medición después de cada cambio — una sola sesión de optimización no alcanza, esto es una disciplina, no un evento único.
Nada de esto es misterioso ni requiere un desarrollador de tiempo completo. La causa más común de un LCP alto en hosting compartido sigue siendo la misma de siempre: el servidor tarda en responder porque WordPress se ejecuta entero en cada visita. Resolver eso primero es lo que más rápido te devuelve a terreno seguro antes de que la próxima actualización de Google vuelva a subir la vara.