Cada vez que alguien abre Search Console y ve la sección de Core Web Vitals en rojo, la primera reacción suele ser la misma: instalar tres plugins de caché y esperar el milagro. A veces funciona, pero muchas veces no, porque una parte de esas métricas no se arregla desde WordPress: se arregla desde el servidor. En esta nota te explico qué mide cada una de las tres métricas, qué porcentaje de cada una depende de tu hosting y qué podés hacer concretamente para mejorarlas sin volverte loco.
Qué son los Core Web Vitals y por qué a Google le importan
Los Core Web Vitals son tres métricas que Google usa para medir la experiencia real de las personas que visitan tu sitio. No son inventos teóricos de laboratorio: se calculan a partir de datos de usuarios reales, con sus conexiones reales y sus teléfonos reales. Por eso son parte de las señales de posicionamiento y por eso conviene tomarlas en serio, aunque no sean el factor más importante del SEO.
La lógica de Google es simple: si dos páginas responden igual de bien a la búsqueda de alguien, va a preferir mostrar primero la que se carga rápido y no salta mientras se lee. En sectores competitivos, donde hay veinte resultados igual de buenos, esa diferencia puede definir quién queda arriba.
LCP: cuánto tarda en aparecer lo importante
El LCP (Largest Contentful Paint) mide cuánto tarda en dibujarse el elemento visible más grande de la pantalla: normalmente la imagen principal o el titular. El objetivo es estar por debajo de 2,5 segundos.
Esta es, de lejos, la métrica que más depende del hosting. El LCP arranca a contar desde que el visitante hace clic, e incluye el tiempo que tarda tu servidor en responder con el primer byte de HTML. Si tu servidor tarda 1,2 segundos solo en empezar a contestar, ya te comiste casi la mitad del presupuesto antes de que el navegador haya descargado una sola imagen. Ningún plugin de caché arregla eso si el problema está abajo.
Qué mejora el LCP desde el servidor: discos SSD puros (no mecánicos ni híbridos), un servidor web rápido como LiteSpeed con su caché a nivel de servidor, una versión moderna de PHP, y sobre todo que la máquina no esté saturada por tener demasiadas cuentas encima. Qué lo mejora desde el sitio: imágenes en formato WebP y del tamaño correcto, precargar la imagen del encabezado, y no cargar fuentes o scripts pesados antes de que se dibuje el contenido principal.
INP: cuánto tarda tu página en reaccionar
El INP (Interaction to Next Paint) reemplazó al viejo FID y mide otra cosa: cuánto tarda la página en responder visualmente cuando alguien toca un botón, abre un menú o escribe en un campo. El objetivo es estar por debajo de 200 milisegundos.
Acá el hosting influye menos, porque el INP se juega casi todo en el navegador del visitante: es JavaScript ejecutándose en su teléfono. Un sitio con quince plugins que cargan sus propios scripts, sliders pesados y rastreadores de todo tipo va a tener un INP malo aunque lo alojes en el mejor servidor del mundo.
Dicho eso, hay un caso donde el servidor sí pesa: cuando una interacción dispara una consulta al servidor (un filtro de productos, una búsqueda, agregar al carrito). Ahí el tiempo de respuesta del backend entra en la cuenta, y un servidor lento vuelve a aparecer en la foto. Para el resto, la receta es podar: menos plugins, menos scripts de terceros, y cargar en diferido lo que no es imprescindible para la primera pantalla.
CLS: cuánto salta el contenido mientras carga
El CLS (Cumulative Layout Shift) mide esa experiencia irritante en la que vas a tocar un botón y el contenido se corre justo en ese momento porque terminó de cargar una imagen o un banner. El objetivo es un valor menor a 0,1.
Esta métrica prácticamente no depende del hosting: es puro maquetado. Las causas más comunes son imágenes sin ancho y alto declarados, publicidades que se insertan y empujan el texto, fuentes personalizadas que cambian el tamaño del texto al cargar, y avisos de cookies que aparecen tarde. La solución es siempre la misma: reservarle el espacio a todo lo que va a aparecer, antes de que aparezca.
Cómo saber si tu problema es del servidor o del sitio
Hay una prueba muy simple. Medí el TTFB (el tiempo hasta el primer byte) de tu página con cualquier herramienta de análisis de velocidad. Si ese número está por encima de 600 milisegundos de forma consistente, tenés un problema de servidor y ninguna optimización de imágenes te va a salvar. Si el TTFB está en 200 milisegundos pero el LCP en 4 segundos, el problema está en el sitio: imágenes gigantes, demasiados recursos bloqueantes o fuentes mal cargadas.
Segunda prueba, todavía más reveladora: medí la misma página a las 4 de la mañana y a las 9 de la noche. Si el rendimiento cambia mucho según la hora, tu servidor está sobrecargado por vecinos ruidosos. Eso no se arregla optimizando: se arregla mudándose a un plan con menos cuentas por máquina.
Un plan de trabajo realista
- Primero medí, después tocá. Anotá los valores actuales de las tres métricas antes de cambiar nada, así sabés si tus cambios sirvieron.
- Atacá el TTFB antes que nada. Es el piso sobre el que se apoya todo lo demás; si está mal, cualquier otra optimización rinde la mitad.
- Después las imágenes. Convertir a WebP y servirlas en el tamaño real de pantalla suele ser la mejora más grande por unidad de esfuerzo.
- Después el JavaScript. Desactivá plugins uno por uno y volvé a medir; casi siempre hay dos o tres culpables claros.
- Al final, el maquetado. Anchos y altos en las imágenes, espacio reservado para banners y avisos.
- Volvé a medir a los 28 días. Search Console usa una ventana móvil de casi un mes, así que las mejoras tardan en reflejarse.
Lo que no te van a decir
Los Core Web Vitals importan, pero no son magia. Un sitio con contenido mediocre y métricas perfectas no le va a ganar a uno con contenido excelente y métricas aceptables. La forma correcta de pensarlo es como un desempate: cuando dos páginas están parejas en calidad y relevancia, la más rápida gana. Y también, muy concretamente, la más rápida convierte mejor, porque menos gente se va antes de que cargue.
En la práctica, la mitad de esta batalla se gana eligiendo bien dónde vive el sitio. Por eso recomiendo BanaHosting: SSD puro sobre servidores Dell con RAID-10, LiteSpeed con LSCache a nivel de servidor —que es la caché que realmente baja el TTFB, no una que se ejecuta después de PHP—, versiones actualizables de PHP y planes con pocas cuentas por máquina. Con planes desde 4,95 dólares al mes, migración gratis de hasta 3 sitios sin downtime y 30 días de garantía, es la forma más barata de arreglar la parte del problema que ningún plugin puede arreglar.