Una web lenta pierde clientes antes de enseñar lo que vendes: cada segundo de más en cargar baja las conversiones y, de paso, el posicionamiento en Google. Los Core Web Vitals son las tres métricas con las que Google mide esa experiencia. Para una pyme del Vallès Occidental con la web en WordPress y unos cuantos plugins, suelen ser el punto donde más se gana con menos esfuerzo. Aquí te explico qué son en lenguaje llano, cómo medirlos y qué se puede hacer.
Qué son los Core Web Vitals en cristiano
Son tres métricas que resumen si una web va fluida para quien la usa.
LCP (Largest Contentful Paint): cuánto tarda en verse lo importante
Mide el tiempo hasta que se pinta el elemento grande principal de la página (la imagen de cabecera, el titular). Bien: por debajo de 2,5 segundos. Si tu LCP es de 5 segundos, medio visitante ya se ha ido.
INP (Interaction to Next Paint): cuánto tarda en responder cuando tocas algo
Mide el retraso entre que el usuario pulsa un botón, abre el menú o rellena un campo y la web reacciona. Bien: por debajo de 200 milisegundos. Un INP alto es esa sensación de "he tocado y no pasa nada" típica de webs con exceso de scripts. Sustituyó a la antigua métrica FID en 2024.
CLS (Cumulative Layout Shift): cuánto "baila" la página al cargar
Mide si el contenido salta mientras carga (entra un banner, una fuente, una imagen sin espacio reservado) y acabas pulsando donde no querías. Bien: por debajo de 0,1.
Por qué le importan a tu negocio, no solo a Google
- Conversión: estudios de grandes ecommerce y de la propia Google asocian mejoras de velocidad con subidas claras de ventas y bajadas de rebote. En una web de servicios, se traduce en más formularios y llamadas.
- SEO: los Core Web Vitals son un factor de posicionamiento. No el más importante —el contenido y los enlaces pesan más—, pero sí un desempate real entre webs parecidas, y afecta a todo el dominio.
- Imagen de marca: una web que va lenta o "baila" transmite dejadez antes de que el cliente lea una palabra.
- Coste de publicidad: si pagas Google Ads o Meta, una landing lenta te sube el coste por lead porque parte del tráfico que pagas se pierde en la carga.
Un ejemplo hipotético para ver el orden de magnitud
Imagina una web de servicios del Vallès con unas 3.000 visitas al mes, dos tercios desde el móvil, y un LCP móvil de 4,8 segundos por un slider de cabecera y fotos sin comprimir. La conversión a formulario ronda el 1%. Tras comprimir imágenes, quitar el slider, cargar bien las fuentes y activar una caché decente, el LCP baja a unos 2 segundos y el INP mejora al reducir scripts de terceros. En los dos meses siguientes suele verse: menos rebote en móvil, más páginas por visita, la conversión moviéndose hacia el 1,5-1,8% y un puñado de páginas de servicio ganando posiciones en búsquedas locales donde ya rondaban la primera página. No es un resultado garantizado —depende del punto de partida y de la competencia—, pero es el patrón habitual cuando la web solo estaba lastrada por rendimiento.
Cómo medirlos tú mismo
- PageSpeed Insights (pagespeed.web.dev): pegas la URL y te da las tres métricas con datos de laboratorio y, si tu web tiene tráfico suficiente, datos reales de usuarios de los últimos 28 días. Los datos reales son los que cuentan para Google.
- Search Console: sección "Core Web Vitals". Agrupa tus URLs en "Buenas", "Necesitan mejora" y "Deficientes" con datos de usuarios reales. Es la vista que hay que vigilar mes a mes.
- Lighthouse (dentro de las herramientas de desarrollador de Chrome, pestaña "Rendimiento"): útil para diagnosticar en una página concreta mientras se trabaja.
- Mide siempre en móvil, que es donde están la mayoría de tus visitas y donde los problemas se notan más.
Un matiz: la puntuación global de PageSpeed (el número sobre 100) es orientativa. Lo que Google usa para posicionar es si superas o no los umbrales de LCP, INP y CLS con datos reales.
Causas típicas en WordPress con plugins
- Demasiados plugins que cargan su propio CSS y JavaScript en todas las páginas, aunque no se usen ahí.
- Constructores visuales (page builders) que generan HTML pesado y anidado.
- Imágenes sin optimizar: fotos de 3.000 px y varios MB servidas tal cual, sin formato moderno (WebP o AVIF) ni carga diferida.
- Sliders y carruseles en la cabecera: de los mayores culpables de un LCP malo.
- Fuentes web mal cargadas que bloquean el render o provocan saltos (CLS).
- Hosting compartido barato con tiempos de respuesta del servidor altos.
- Falta de caché o caché mal configurada.
- Scripts de terceros: chats, píxeles de seguimiento, mapas incrustados, banners de cookies pesados.
Qué se puede hacer (de menos a más)
Mejoras rápidas
- Un buen plugin de caché y optimización, bien configurado.
- Comprimir y convertir las imágenes, activar la carga diferida.
- Quitar plugins que no se usan y scripts de terceros prescindibles.
- Subir a un hosting decente con PHP actual.
- Cargar las fuentes bien y reservar espacio para imágenes y anuncios.
Mejoras de fondo
- Sustituir el page builder por un tema ligero o una maquetación a medida.
- Revisar plugin a plugin qué carga y dónde.
- Replantear la cabecera: fuera slider, una imagen optimizada y un titular claro.
Cuando el WordPress no da más de sí
Si tras limpiar plugins, imágenes y hosting la web sigue sin pasar los umbrales, el problema es estructural. Ahí entra rehacer el front con una tecnología pensada para la velocidad. Una web en Next.js parte con LCP y CLS buenos "de fábrica" porque sirve HTML ligero y controla la carga de recursos. Tienes cuándo tiene sentido ese salto en migrar de WordPress a Next.js.
Cuidado con las "optimizaciones" que rompen cosas
Muchos plugins de velocidad prometen milagros con un botón, pero combinar minificación agresiva, aplazamiento de JavaScript y CSS crítico automático puede romper el menú, el formulario o el diseño en móvil. Hay que activar las opciones de una en una y comprobar la web después de cada cambio, sobre todo las páginas de contacto y de producto. Una web rápida que no deja enviar el formulario es peor que una web lenta.
Qué se gana al arreglarlo
En los proyectos que hago para pymes de Terrassa, Sabadell o Rubí, pasar una web de "deficiente" a "buena" en Core Web Vitals suele traer: menos rebote en móvil, más páginas por visita, más formularios enviados y una mejora gradual de posiciones en las semanas siguientes, sobre todo en búsquedas donde competías de tú a tú con webs igual de relevantes. No es magia ni es inmediato, pero es de las inversiones con retorno más medible.
Cómo lo abordo en GooWebs
Empiezo con una auditoría: datos reales de Search Console y PageSpeed, revisión de plugins, imágenes, hosting y plantilla, y un informe con lo que se puede arreglar sobre el WordPress actual y lo que solo se resuelve rehaciendo el front. Muchas veces con la optimización basta; cuando no, lo digo claro. Puedes ver el enfoque en desarrollo web, plantearte un plan de mantenimiento web para que no vuelva a degradarse, o contarme tu caso.
Preguntas frecuentes
¿Qué son LCP, INP y CLS?
LCP mide cuánto tarda en verse el contenido principal (bien: menos de 2,5 s); INP, cuánto tarda la web en responder a un toque o clic (bien: menos de 200 ms); CLS, cuánto se mueve el contenido mientras carga (bien: menos de 0,1).
¿Cómo sé si mi web pasa los Core Web Vitals?
Con PageSpeed Insights pegando tu URL y con el informe "Core Web Vitals" de Search Console, que usa datos de usuarios reales. Mira siempre la versión móvil.
¿Por qué mi WordPress va lento?
Lo más habitual: exceso de plugins, un constructor visual pesado, imágenes sin optimizar, un slider en la cabecera, fuentes mal cargadas y hosting compartido barato.
¿Puedo arreglarlo sin rehacer la web?
En muchos casos sí: caché, optimización de imágenes, limpieza de plugins y mejor hosting bastan para pasar los umbrales. Si tras eso sigue sin pasarlos, el problema es estructural y toca rehacer el front.
¿Mejorar la velocidad sube el posicionamiento?
Ayuda, sobre todo como desempate entre webs de relevancia parecida y porque mejora la experiencia y la conversión. No sustituye a tener buen contenido y enlaces.