Google no te avisa cuando baja tu sitio en los resultados de búsqueda. No te manda un email. No te da una advertencia. Simplemente te baja en silencio, y vos empezás a notar que el tráfico orgánico cae sin ninguna razón aparente.
Una de las causas más frecuentes y menos diagnosticadas de esa caída silenciosa tiene nombre técnico: malos Core Web Vitals. En 2026, solo el 55.9% de todos los sitios web rastreados globalmente pasan las tres métricas que Google evalúa. Eso significa que casi la mitad de los sitios que existen tienen un problema de rendimiento que Google está penalizando, muchas veces sin que sus dueños lo sepan.
Esta guía explica qué son los Core Web Vitals sin tecnicismos innecesarios, cómo medirlos gratis con herramientas oficiales de Google, y qué pasos concretos podés seguir para mejorarlos en un sitio WordPress sin necesidad de tocar una sola línea de código.
Qué son los Core Web Vitals y por qué importan para tu posicionamiento
Los Core Web Vitals son un conjunto de métricas específicas que Google utiliza para evaluar experiencia de página desde la perspectiva de usuarios reales, no solo datos de laboratorio.
La diferencia entre «datos de laboratorio» y «usuarios reales» es importante. Las herramientas de análisis de velocidad tradicionales medían el rendimiento de una página en condiciones ideales: una conexión rápida, un servidor sin carga, un navegador limpio. Los Core Web Vitals miden lo que experimenta un visitante real con su teléfono real, en su conexión real, en condiciones reales.
En 2026, Google sigue priorizando sitios web que cargan rápido, responden sin trabas y se mantienen visualmente estables en todos los dispositivos. Estas métricas influyen en el rendimiento SEO, el engagement, las tasas de conversión y la calidad general del sitio.
El impacto no es solo teórico. Los sitios que aprueban las tres métricas registran hasta un 24% menos de abandono y mejoras de conversión de entre 15% y 30% según estudios de la industria. No es solo SEO: es dinero que se queda o se pierde.
Las 3 métricas que componen los Core Web Vitals
Las 3 métricas que componen los Core Web Vitals son: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS). Google califica los Core Web Vitals de tu sitio como Bueno, Necesita mejorar o Deficiente.
Para pasar los Core Web Vitals no alcanza con tener una buena nota en una sola métrica. Una página pasa los Core Web Vitals únicamente cuando las tres métricas alcanzan sus umbrales de «Bueno» en el percentil 75 de las sesiones reales de usuarios de Chrome durante una ventana móvil de 28 días. Una sola métrica en la banda «Necesita mejorar» es suficiente para reprobar la evaluación general.
Métrica 1: LCP — Largest Contentful Paint (Carga del contenido principal)
¿Qué mide? El tiempo que tarda en cargarse el elemento más grande visible en la pantalla cuando el usuario abre la página. Generalmente es la imagen destacada del post, el hero image de la portada, o el bloque de texto principal.
¿Por qué importa? Es el indicador más directo de si tu página «apareció» para el usuario. Un LCP rápido significa que el visitante ve contenido útil casi de inmediato. Un LCP lento hace que la pantalla quede en blanco o con un esqueleto de carga durante segundos, lo que lleva al usuario a cerrar la pestaña.
Los umbrales de Google:
- ✅ Bueno: menos de 2.5 segundos
- ⚠️ Necesita mejorar: entre 2.5 y 4 segundos
- ❌ Deficiente: más de 4 segundos
Según el Web Almanac 2025, solo el 62% de las páginas móviles logra un buen LCP, lo que la convierte en la métrica de Core Web Vitals más difícil de aprobar.
Las causas más comunes de un LCP lento en WordPress:
Imágenes sin optimizar son el culpable número uno. Una imagen de portada de 3MB en formato JPEG es suficiente para arruinar el LCP de cualquier post, sin importar lo bien configurado que esté todo lo demás.
El TTFB (Time To First Byte) alto es el segundo factor más frecuente. Si el servidor tarda mucho en responder, todo lo demás carga tarde. Un hosting compartido económico sin caché configurada puede tener TTFBs de 800ms a 2 segundos, lo que hace prácticamente imposible pasar el umbral de LCP sin importar cuántos plugins de optimización instales.
Las fuentes bloqueantes también penalizan el LCP. Cuando WordPress carga fuentes tipográficas externas (Google Fonts, por ejemplo) de forma bloqueante, el navegador no puede renderizar el texto hasta que la fuente descargue completamente.
Métrica 2: CLS — Cumulative Layout Shift (Estabilidad visual)
¿Qué mide? La suma de todos los movimientos inesperados de elementos en la página mientras carga. Cuando un botón se mueve justo cuando ibas a hacer clic, cuando un texto baja de posición porque cargó una imagen arriba, cuando un banner publicitario aparece y empuja el contenido: todo eso es CLS.
¿Por qué importa? Un CLS alto es frustrante a nivel de usuario de una forma muy específica: hace que hagas clic en el lugar equivocado. Es el tipo de problema que no se nota en herramientas de velocidad pero que el visitante experimenta como un sitio «roto» o «inestable».
Los umbrales de Google:
- ✅ Bueno: 0.1 o menos
- ⚠️ Necesita mejorar: entre 0.1 y 0.25
- ❌ Deficiente: más de 0.25
Las causas más comunes de CLS alto en WordPress:
La causa más común del CLS son imágenes, videos y anuncios sin dimensiones definidas en el código: el navegador no reserva el espacio, así que cuando cargan, empujan todo lo demás.
Los banners de cookies que aparecen desde abajo empujando el contenido hacia arriba son un generador de CLS clásico en WordPress. Muchos plugins de consentimiento de cookies no están optimizados para esto.
Los widgets de redes sociales que cargan de forma asíncrona (botones de compartir, feeds de Instagram incrustados, contadores de Twitter) también generan layout shifts frecuentes.
Métrica 3: INP — Interaction to Next Paint (Respuesta a la interacción)
¿Qué mide? El tiempo que tarda la página en responder visualmente después de que el usuario hace alguna interacción: un clic, un tap en móvil, una tecla presionada. INP mide cada interacción en una página, no solo la primera, lo que lo convierte en una prueba mucho más estricta de la capacidad de respuesta.
¿Por qué importa? Es la métrica más nueva y la que más sitios WordPress está fallando en 2026. Un INP alto se experimenta como una página que «se cuelga» o «no responde» cuando hacés clic en algo: un menú que tarda en abrirse, un formulario que no reacciona inmediatamente, un filtro que congela la pantalla por un momento.
En marzo de 2024, Interaction to Next Paint (INP) reemplazó a First Input Delay (FID) como la métrica de capacidad de respuesta.
Los umbrales de Google:
- ✅ Bueno: menos de 200 milisegundos
- ⚠️ Necesita mejorar: entre 200 y 500 milisegundos
- ❌ Deficiente: más de 500 milisegundos
Las causas más comunes de INP alto en WordPress:
INP penaliza JavaScript pesado. Si tu tema tiene scripts que bloquean el hilo principal por 300ms cuando el usuario hace clic en el menú móvil, INP lo va a detectar. WordPress con muchos plugins suele fallar INP aunque pase LCP y CLS sin problema. Es la métrica que más sitios WordPress está sufriendo en 2026.
Los page builders como Elementor generan hasta 3 veces más nodos en el DOM que un tema basado en bloques, penalizando directamente el INP.
Cómo medir tus Core Web Vitals: las herramientas oficiales
Antes de optimizar nada, necesitás saber dónde estás. Estas son las tres herramientas que el Radar Eclixxo recomienda, en orden de importancia.
1. Google Search Console — La fuente de datos más importante
Por qué es la más importante: Muestra los datos reales de usuarios reales que visitaron tu sitio, no una simulación. Es el mismo dato que usa Google para evaluar tu posicionamiento.
Cómo acceder: Abrí search.google.com/search-console → menú lateral → Experiencia → Core Web Vitals.
Vas a ver dos informes separados: uno para móvil y otro para escritorio. En cada uno, las URLs de tu sitio están clasificadas en tres grupos: Deficiente (rojo), Necesita mejorar (amarillo) y Buenas (verde).
Lo que hay que saber: Google Search Console actualiza los datos con una ventana de 28 días de datos reales. Eso significa que si hacés mejoras hoy, vas a ver los resultados reflejados recién en 4 a 6 semanas, y el impacto en el ranking puede tardar entre 8 y 14 semanas adicionales.
2. PageSpeed Insights — El diagnóstico rápido por URL
Cómo usarlo: Entrá a pagespeed.web.dev, pegá la URL de tu post o página de inicio y hacé clic en Analizar.
El reporte tiene dos secciones. La primera muestra datos de campo (cuando existen): son los datos reales de usuarios reales del Chrome UX Report, igual que Search Console. La segunda muestra datos de laboratorio: una simulación en condiciones controladas.
Para SEO técnico, siempre priorizá el dato de campo sobre el dato de laboratorio. El dato de laboratorio sirve para diagnosticar problemas específicos, pero el dato de campo es lo que Google usa para evaluar tu sitio.
Un detalle importante: Si tu sitio tiene poco tráfico, puede que no aparezcan datos de campo porque Google necesita un mínimo de visitas para tener datos representativos. En ese caso, trabajá con los datos de laboratorio como referencia.
3. Google Chrome DevTools — Para diagnóstico profundo
Ya cubrimos DevTools en detalle en otro artículo del Radar Eclixxo, pero para Core Web Vitals el panel más útil es Lighthouse, que está integrado en DevTools.
Cómo acceder: F12 → pestaña Lighthouse → elegí «Performance» → «Analyze page load».
El reporte de Lighthouse muestra puntuaciones del 0 al 100 y, lo más valioso, una lista de oportunidades de mejora ordenadas por impacto estimado. Cada sugerencia te dice exactamente qué cambiar y cuántos segundos podría ahorrarte en LCP.
Cómo mejorar cada métrica en WordPress: guía práctica
Ahora viene la parte accionable. Para cada métrica, estas son las acciones ordenadas de mayor a menor impacto.
Cómo mejorar el LCP
Acción 1 — Optimizá la imagen principal de cada post (impacto: muy alto)
La imagen destacada de un post de WordPress es casi siempre el elemento LCP. Si esa imagen pesa más de 200KB y está en formato JPEG o PNG sin comprimir, es tu problema número uno.
Lo que hay que hacer: convertir todas las imágenes a formato WebP o AVIF. WebP pesa aproximadamente un 30% menos que JPEG con calidad equivalente. AVIF pesa un 50% menos pero tiene soporte ligeramente menor. La diferencia en LCP de una imagen hero en JPEG versus WebP puede ser de 400 a 800 milisegundos en conexiones móviles.
Los plugins gratuitos que hacen esta conversión automáticamente en WordPress: ShortPixel (plan gratuito con 100 imágenes por mes) e Imagify (plan gratuito con 200 imágenes por mes). Ambos convierten las imágenes nuevas automáticamente y tienen una función de «optimización masiva» para las imágenes que ya tenés subidas.
Acción 2 — Agregá fetchpriority="high" a la imagen principal (impacto: alto)
Las formas más efectivas de mejorar el LCP incluyen precargar la imagen LCP con fetchpriority="high" y optimizar el tamaño de los archivos de imagen con formatos modernos como WebP y AVIF.
Este atributo le dice al navegador que descargue esa imagen antes que cualquier otra cosa. En WordPress, los plugins de optimización como WP Rocket lo hacen automáticamente. Si no usás un plugin de caché, podés agregarlo manualmente en el código del tema.
Acción 3 — Mejorá el TTFB con caché y mejor hosting (impacto: muy alto)
Un hosting con TTFB inferior a 200ms es el factor más infravalorado: ningún plugin de caché puede compensar un servidor lento.
Si tu TTFB (el tiempo que tarda el servidor en empezar a responder) es mayor a 600ms en los datos de PageSpeed Insights, el problema está en el hosting o en la falta de caché del servidor. Los plugins de caché recomendados para WordPress son WP Rocket (de pago, el más completo) y LiteSpeed Cache (gratuito, excelente si tu hosting usa LiteSpeed).
Acción 4 — Cargá las fuentes tipográficas localmente (impacto: medio)
Si usás Google Fonts cargadas desde los servidores de Google, hay un tiempo de conexión adicional que penaliza el LCP. La solución es descargar las fuentes y servirlas desde tu propio servidor. El plugin gratuito OMGF (Optimize My Google Fonts) hace esto automáticamente.
Cómo mejorar el CLS
Acción 1 — Definí el tamaño de todas las imágenes en el código HTML (impacto: muy alto)
El atributo width y height en las etiquetas <img> le dice al navegador cuánto espacio reservar antes de que la imagen cargue. Sin esos atributos, el navegador no reserva espacio y la imagen «aparece» desplazando todo lo que estaba abajo.
WordPress agrega automáticamente estos atributos en las imágenes subidas desde el editor de bloques (Gutenberg). Si usás el editor clásico o un page builder, verificá que las imágenes incluyan dimensiones definidas.
Acción 2 — Reservá espacio para los anuncios y widgets (impacto: alto)
Si tenés publicidad en el sitio (Google AdSense, por ejemplo), cada bloque de anuncio necesita tener dimensiones fijas reservadas aunque el anuncio no haya cargado todavía. La forma más sencilla es agregar un min-height en CSS para el contenedor del anuncio.
Acción 3 — Configurá los banners de cookies para que no desplacen contenido (impacto: medio)
Los banners de cookies que aparecen desde abajo son generadores de CLS clásicos. La solución es configurarlos para que aparezcan en una posición fija (fixed) que no interactúe con el flujo del documento. Los plugins de consentimiento más modernos como CookieYes tienen esta opción en su configuración.
Cómo mejorar el INP
Acción 1 — Auditá los plugins que cargan JavaScript en todas las páginas (impacto: muy alto)
Plugins que cargan JavaScript en todas las páginas cuando solo lo necesitan en una específica son enemigos directos del INP.
Un plugin de slider que carga su JavaScript en el home y también en cada post individual, un plugin de formularios que carga su script en páginas donde no hay ningún formulario, un plugin de e-commerce que carga scripts en posts de blog: todos están bloqueando el hilo principal innecesariamente.
La herramienta para detectar esto: en Chrome DevTools, abrí el panel Network, recargá la página y filtrá por «JS». Vas a ver todos los archivos JavaScript que carga la página. Buscá scripts con nombres de plugins que no son necesarios en esa página específica.
Acción 2 — Desactivá plugins que no uses activamente (impacto: alto)
El problema rara vez es un solo plugin, es la suma. Muchos plugins (cada uno agrega JS/CSS y queries a la base de datos), un tema con código pesado, falta de optimización de imágenes, hosting compartido lento, sin CDN, JS de jQuery y bibliotecas innecesarias.
Hacé un inventario de tus plugins activos y desactivá todo lo que no estés usando activamente. Cada plugin desactivado es código que no se carga.
Acción 3 — Considerá cambiar a un tema más ligero (impacto: muy alto para sitios con temas pesados)
Si usás Divi, Avada, o cualquier theme builder basado en shortcodes o frameworks pesados, el INP va a ser difícil de mejorar porque el problema está en la arquitectura misma del tema. Los temas ligeros recomendados para WordPress en 2026 en términos de performance son: GeneratePress, Kadence, Blocksy y Astra.
Stack de plugins recomendado para Core Web Vitals en WordPress
Esta es la combinación de plugins que cubre todos los frentes de optimización sin solapamientos ni conflictos:
Para caché y optimización general: WP Rocket (de pago, $59/año, el más completo del mercado) o LiteSpeed Cache (gratuito si tu hosting usa servidor LiteSpeed).
Para optimización de imágenes: ShortPixel o Imagify en sus planes gratuitos para sitios pequeños. Para sitios con mucho volumen de imágenes, el plan de pago de cualquiera de los dos.
Para fuentes de Google: OMGF (Optimize My Google Fonts), gratuito.
Para CDN (Content Delivery Network): Cloudflare en su plan gratuito. Un CDN sirve los archivos estáticos de tu sitio desde servidores cercanos a cada visitante, reduciendo el tiempo de carga significativamente para visitantes de otras regiones.
La hoja de ruta: qué hacer primero
Si acabás de medir tus Core Web Vitals y los números no son buenos, esta es la secuencia de acciones ordenada por impacto:
Semana 1 — Las acciones de mayor impacto: Instalá un plugin de caché (LiteSpeed Cache si tu hosting lo soporta, WP Rocket en cualquier otro caso). Activá Cloudflare en tu dominio. Optimizá y convertí a WebP las imágenes de los 10 posts con más tráfico.
Semana 2 — Optimización de imágenes y fuentes: Instalá ShortPixel o Imagify y corrés la optimización masiva de todas las imágenes. Instalá OMGF para servir Google Fonts localmente. Revisás los atributos width y height en las imágenes del tema y los posts más importantes.
Semana 3 — Auditoría de plugins y JavaScript: Hacés el inventario de plugins activos y desactivás todo lo que no esté en uso. Usás el panel Network de DevTools para identificar scripts que cargan en páginas donde no son necesarios.
Semana 4 en adelante — Monitoreo: Revisás Search Console una vez por semana. Recordá que los cambios tardan 4 a 6 semanas en aparecer reflejados en los datos de campo de Google.
Los errores más frecuentes al optimizar Core Web Vitals en WordPress
Error 1 — Optimizar solo para escritorio y olvidarse del móvil
Google usa Mobile-First Indexing, lo que significa que evalúa la versión móvil de tu sitio para el ranking. Un sitio con 90 puntos en Lighthouse en escritorio puede tener 40 puntos en móvil. Siempre medí y optimizá para móvil primero.
Error 2 — Instalar muchos plugins de optimización a la vez
Instalar WP Rocket, W3 Total Cache y LiteSpeed Cache al mismo tiempo no triplica la velocidad: genera conflictos que pueden hacer que el sitio funcione peor que antes. Usá un solo plugin de caché, el que más se adapte a tu configuración de hosting.
Error 3 — Confiar solo en el dato de laboratorio de PageSpeed Insights
El dato de laboratorio es útil para diagnosticar problemas específicos, pero puede diferir significativamente del dato de campo real. Siempre tomá decisiones basadas en los datos de campo de Search Console, que reflejan la experiencia real de tus visitantes.
Error 4 — Esperar resultados inmediatos
Como mencionamos, Google tarda 4 a 6 semanas en actualizar los datos de Core Web Vitals en Search Console, y el impacto en el ranking puede tardar hasta 14 semanas más. La optimización de Core Web Vitals es una inversión a mediano plazo, no una solución rápida.
Error 5 — Ignorar el hosting
Un hosting con TTFB inferior a 200ms es el factor más infravalorado. Ningún plugin de caché puede compensar un servidor lento. Si tu TTFB supera los 600ms y estás en un hosting compartido económico, la solución de raíz es cambiar de hosting o al menos cambiar a un plan con más recursos.
Conclusión: los Core Web Vitals son una inversión, no una tarea técnica
La mayoría de los bloggers y emprendedores perciben los Core Web Vitals como un tema para «los técnicos». Pero los números cuentan otra historia: los sitios que aprueban las tres métricas registran hasta un 24% menos de abandono y mejoras de conversión de entre 15% y 30%.
No hace falta ser desarrollador para mejorarlos. Con el stack de plugins correcto, una optimización básica de imágenes y un hosting razonablemente bueno, la mayoría de los sitios WordPress pueden pasar de rojo a verde en 30 días.
El primer paso es siempre el mismo: medí. Abrí PageSpeed Insights ahora mismo, pegá la URL de tu portada y la de tu post con más tráfico, y mirá los números. Con esa información en mano, el resto del camino es mucho más claro.
En El Radar Eclixxo vamos a seguir publicando guías específicas sobre cada métrica, con ejemplos reales y configuraciones paso a paso para los plugins más usados.
¿Cuál es tu puntuación actual en PageSpeed Insights? Dejá el número en los comentarios y te decimos por dónde empezar.
Artículos relacionados en El Radar Eclixxo:
- DevTools: qué son, para qué sirven y cómo empezar a usarlas hoy
- Las 7 extensiones de Chrome que los desarrolladores web están usando en 2026
- Radar: 5 alternativas gratuitas a Canva que están ganando terreno
