Tu web tarda y te está costando clientes: Core Web Vitals explicado sin tecnicismos
Google mide tres cosas concretas de la experiencia de tus visitantes y las usa como señal de posicionamiento. Qué son, cómo saber cómo estás y qué arreglar primero cuando el presupuesto es corto.
Si has pedido alguna vez una auditoría de tu web, habrás visto un informe con tres siglas y unos círculos de colores. Y probablemente te lo entregaron sin traducir. Vamos a traducirlo, porque detrás de esas siglas hay tres preguntas que cualquiera entiende.
Las tres métricas, en cristiano
LCP: ¿cuándo aparece lo importante?
Mide el tiempo que tarda en dibujarse el elemento principal de la pantalla: normalmente la imagen grande de portada o el titular. No cuándo empieza a cargar la página, sino cuándo el visitante ve algo que le sirve.
El umbral de Google: por debajo de 2,5 segundos está bien; por encima de 4 segundos, mal (documentación de LCP en web.dev).
Por qué importa para el negocio: es el tiempo durante el cual tu visitante está mirando una pantalla en blanco preguntándose si esto funciona. En móvil y con datos, esa paciencia es corta.
INP: ¿responde cuando toco?
Mide cuánto tarda la página en reaccionar cuando el usuario hace algo: pulsar un botón, abrir el menú, desplegar una pregunta. Sustituyó a la antigua métrica FID porque esta solo miraba la primera interacción, y el problema real suele estar más adelante.
El umbral: por debajo de 200 milisegundos está bien; por encima de 500, mal (documentación de INP en web.dev).
Por qué importa: la sensación de "esta web va rara" casi siempre es esto. El usuario toca, no pasa nada, vuelve a tocar, y acaba abriendo dos veces lo mismo o marchándose.
CLS: ¿se mueve el contenido mientras leo?
Mide cuánto salta el contenido mientras la página termina de cargar. Empiezas a leer un párrafo, carga una imagen o una fuente por encima y el texto baja de golpe. O peor: vas a pulsar un enlace y en ese instante aparece un banner y pulsas el banner.
El umbral: por debajo de 0,1 está bien; por encima de 0,25, mal (documentación de CLS en web.dev).
Por qué importa: es el que más irrita y el más barato de arreglar, casi siempre.
Lo que nadie te cuenta sobre la medición
Dos matices que cambian por completo cómo interpretas tu informe.
Se mide en móvil y con conexiones normales. Tu web va rapidísima en tu ordenador, con fibra y con todo en caché. Esa no es la medición que cuenta. La que cuenta es la de alguien con un móvil de gama media y cobertura regular.
Los datos que valen son de usuarios reales. Las herramientas dan dos cosas: una simulación de laboratorio (útil para depurar) y datos de campo recogidos de visitantes reales durante los últimos días. Google usa los segundos. Si tu web tiene poco tráfico, puede que no haya datos de campo, y entonces te guías por el laboratorio sabiendo que es una aproximación.
Se evalúa por URL, no por sitio. Tu portada puede ir bien y tus fichas de producto fatal. Mira el informe por grupos de páginas, no el número global.
Las tres causas del 80 % de los problemas
Después de bastantes auditorías, los culpables se repiten con una monotonía asombrosa.
1. Imágenes enormes
La foto de portada de 4 MB directamente de la cámara. Es, con diferencia, la causa número uno de un LCP malo, y también la más fácil de arreglar.
Qué hacer: exportar en formatos modernos como WebP o AVIF, servir tamaños distintos según el dispositivo (nadie necesita 3000 píxeles de ancho en un móvil), cargar de forma diferida todo lo que esté por debajo de la primera pantalla, y no cargar de forma diferida la imagen principal, que es el error contrario y también lo vemos mucho.
Una portada bien optimizada puede pasar de varios megas a unos pocos cientos de kilobytes sin que se note a simple vista.
2. Scripts de terceros
El chat, el mapa incrustado, el píxel de publicidad, la herramienta de mapas de calor, el reproductor de vídeo, el gestor de etiquetas con nueve etiquetas dentro. Cada uno se trajo por una buena razón y ninguno se quitó nunca.
Es el sospechoso habitual del INP malo: todos esos scripts compiten por el mismo hilo de ejecución que necesita el navegador para responder a tu clic.
Qué hacer: hacer inventario y quitar sin piedad lo que no se está usando de verdad; cargar el chat solo cuando el usuario se desplaza o pasa unos segundos en la página; sustituir el mapa incrustado por una imagen que abra el mapa al pulsarla; y usar un reproductor ligero para los vídeos.
3. Tipografías y huecos sin reservar
El texto que aparece con una fuente y cambia a otra al segundo, moviéndolo todo. O el hueco de un banner que no estaba reservado y empuja la página cuando carga.
Qué hacer: reservar el espacio de imágenes, vídeos y anuncios indicando sus dimensiones desde el principio; alojar las tipografías en tu propio dominio en vez de pedirlas a un tercero; y precargar la fuente principal para que no haya cambio.
Por dónde empezar si el presupuesto es corto
En este orden, porque es el orden de retorno por euro invertido:
- Optimizar las imágenes. Suele ser media jornada de trabajo y produce la mejora más visible.
- Reservar espacios y arreglar el CLS. Barato, rápido y elimina la irritación del visitante.
- Limpiar scripts de terceros. Requiere decisiones de negocio (¿de verdad usamos ese chat?), no tanto trabajo técnico.
- Alojamiento y caché. Si el servidor tarda un segundo en empezar a responder, ninguna de las optimizaciones anteriores te va a salvar.
- Lo demás. A partir de aquí entra el trabajo fino, que cuesta más y rinde menos.
Una advertencia sobre el número 100
Se puede caer en la obsesión de la puntuación perfecta, y es una trampa. Pasar de 60 a 90 puntos cambia la experiencia del visitante. Pasar de 90 a 100 suele consumir tanto esfuerzo como los treinta puntos anteriores y no lo nota nadie.
Y hay algo más importante: la velocidad no compensa un contenido que no responde a lo que la gente busca. Una web instantánea que no explica bien qué vendes seguirá sin vender. Estas métricas son higiene, no estrategia. Pero es higiene que se mide, y por eso conviene tenerla en verde.
Si quieres saber cómo está tu web y qué tres cosas arreglaríamos primero, escríbenos: miramos tus datos reales y te lo decimos en quince minutos, sin coste y sin informe de cuarenta páginas.
Fuentes
- Core Web Vitals · web.dev (Google) — definición y umbrales oficiales de las tres métricas.
- PageSpeed Insights — medición de laboratorio y datos de usuarios reales de una URL.
- Informe de Core Web Vitals en Search Console — URLs agrupadas por problema, que es lo que sirve para priorizar.
Preguntas frecuentes
Lo que más nos preguntan sobre esto.
¿Qué son los Core Web Vitals?
Tres métricas con las que Google mide la experiencia de carga y de uso de una página: LCP (velocidad de aparición del contenido principal), INP (capacidad de respuesta a las interacciones) y CLS (estabilidad visual del contenido). Forman parte de las señales de experiencia de página que utiliza el buscador.
¿Cuánto influyen los Core Web Vitals en el posicionamiento?
Son una señal real pero secundaria: no compensan un contenido que no responde a la búsqueda. Su efecto grande no está en el buscador sino en el negocio, porque una página lenta pierde visitantes antes de que lleguen a leerla.
¿Cómo mido los Core Web Vitals de mi web?
PageSpeed Insights de Google da tanto la medición de laboratorio como los datos de usuarios reales de los últimos días, si tu web tiene tráfico suficiente. Search Console incluye un informe con las URLs agrupadas por problema, que es lo más útil para priorizar.
¿Cuánto cuesta arreglar unos Core Web Vitals malos?
Los dos arreglos que más rinden, optimizar imágenes y reservar los espacios para que el contenido no salte, suelen ser una o dos jornadas de trabajo en una web pequeña. El presupuesto se dispara solo cuando el problema es estructural: una plantilla muy cargada o un alojamiento lento. En ese caso ya no estás optimizando, estás rehaciendo.
¿Tu caso se parece? Cuéntanoslo.
15 minutos, gratis. Te decimos qué se puede construir, cuánto cuesta y cuándo lo tendrías.