Tu página web es lenta y te está costando clientes: qué son los Core Web Vitals y cómo arreglarlos

Google mide la experiencia de tu sitio con tres métricas: LCP (cuánto tarda en aparecer el contenido principal, debe ser ≤ 2,5 s), INP (cuánto tarda en responder a un clic, ≤ 200 ms) y CLS (cuánto se mueve el contenido mientras carga, ≤ 0,1). Se miden en el percentil 75 de tus visitas reales, no en una prueba de laboratorio. Menos de la mitad de los sitios del mundo aprueba las tres en móvil, y cada décima de segundo que recortas se traduce en conversión medible.

Publicado el 1 de julio de 2026 · Actualizado el 1 de julio de 2026

Las tres métricas, en español y sin tecnicismos

Los Core Web Vitals son tres métricas de Google que sirven para medir la experiencia real de una página en tres momentos: cuándo se ve, cuándo responde y si se queda quieta. Miden qué siente una persona con un celular de gama media y datos móviles al abrir tu sitio.

El LCP (Largest Contentful Paint) es el tiempo que tarda en pintarse el elemento más grande de la pantalla y sirve para saber cuándo el visitante percibe que la página ya cargó. Es cuánto se demora el mesero en traerte la carta.

El INP (Interaction to Next Paint) es la métrica que mide cuánto tarda la página en responder después de que tocas un botón, y sirve para detectar interfaces trabadas aunque hayan cargado rápido. Es el mesero que te oye pedir pero no anota nada.

El CLS (Cumulative Layout Shift) es un puntaje sin unidades que mide cuánto se desplaza el contenido mientras la página carga, y sirve para detectar los saltos que hacen que el usuario le pegue al botón equivocado. Es la mesa que se mueve cuando pones el vaso.

Un detalle que invalida buena parte de las guías que hay en internet: INP reemplazó oficialmente a FID el 12 de marzo de 2024, y los umbrales considerados buenos son LCP ≤ 2,5 s, INP ≤ 200 ms y CLS ≤ 0,1, medidos en el percentil 75 de las visitas, según la documentación de Core Web Vitals de web.dev, de Google Chrome (2024). Si una guía todavía te habla de FID, está desactualizada.

Cómo medir tu web hoy, gratis, en 5 minutos

Para saber cómo está tu sitio no necesitas contratar a nadie: con PageSpeed Insights y Search Console, ambas gratuitas y de Google, tienes el diagnóstico. Una te dice qué le pasa a una URL; la otra, cuántas URLs del sitio están mal.

1. Abre pagespeed.web.dev, pega la URL de tu portada y quédate en la pestaña móvil.
2. Lee primero el bloque superior, el de datos de campo: ahí están tus tres métricas con visitantes reales.
3. Repite el análisis con tu página de servicios, una ficha de producto y un artículo del blog. Cuatro URLs muestran patrones; una sola, una anécdota.
4. Entra a Search Console, abre el informe de Core Web Vitals y mira cuántas URLs están en rojo.
5. Anota las tres URLs con más tráfico que estén reprobando. Esas se arreglan primero, no las que peor puntúan.

PageSpeed Insights y por qué mirar los datos de campo, no los de laboratorio

PageSpeed Insights muestra dos cosas que la gente confunde. Los datos de campo vienen del Chrome UX Report: son mediciones de visitantes reales de tu sitio durante los últimos 28 días. Los datos de laboratorio son una simulación que corre en ese momento, en un dispositivo y una conexión virtuales.

La calificación de Google se construye con los datos de campo. El laboratorio sirve para diagnosticar y para comprobar si un cambio funcionó sin esperar el mes. Si tu sitio tiene poco tráfico, ese bloque aparece vacío: trabajas con laboratorio como aproximación.

Search Console: el informe de Core Web Vitals

El informe de Core Web Vitals de Search Console agrupa las URLs por plantilla y estado, y sirve para ver el problema a escala en vez de página por página. Si 400 fichas de producto reprueban por el mismo motivo, es una corrección en la plantilla, no 400. Revisa la pestaña de móvil antes que la de escritorio.

Por qué tu web "va rápida" en tu computador y lenta para tus clientes

Tu sitio te parece rápido por tres razones: tu navegador ya guardó los archivos de la última visita, estás en fibra o en la red de la oficina, y tu computador es mejor que el teléfono promedio de tu cliente. Prueba así: celular de gama media, datos móviles, ventana de incógnito, fuera de tu oficina.

¿Cuánto dinero cuesta cada segundo que tarda tu web en cargar?

La velocidad no es un asunto estético: es un multiplicador de conversión medible. Los dos estudios que mejor lo muestran son internacionales, no colombianos: léelos como orden de magnitud, no como promesa de resultado.

Una mejora de apenas 0,1 segundos en la velocidad móvil produjo un aumento del 8,4% en la conversión de sitios de retail y del 21,6% en el envío de formularios de sitios de generación de leads, según el estudio de Deloitte para Google, "Milliseconds Make Millions" (2019), hecho sobre 37 marcas y más de 30 millones de sesiones. La muestra es de marcas grandes de Europa y Norteamérica, no de pymes latinoamericanas.

El efecto no es lineal: un sitio que carga en 1 segundo convierte cerca de 3 veces más que uno que carga en 5 segundos en generación de leads B2B, según el análisis de Portent (2022) sobre más de 100 millones de páginas vistas en 20 sitios. Traducido: pasar de 5 a 4 segundos vale mucho más que pasar de 2 a 1, y esa diferencia la ves en el costo por lead de tu pauta.

Las 7 causas más comunes de lentitud en un sitio WordPress

Casi todos los sitios lentos que llegan a revisión repiten las mismas siete causas, y ninguna es "WordPress es lento". Son decisiones acumuladas: una imagen que nadie comprimió, un plugin instalado hace dos años, un hosting contratado por precio.

Imágenes sin comprimir ni en formato moderno

Es la causa número uno y la más barata de resolver: una foto de 4 MB subida desde el celular arruina el LCP sola. Sirve WebP o AVIF, redimensiona a lo que se muestra en pantalla y declara width y height para que el navegador reserve el espacio y evite saltos de CLS.

Exceso de plugins y scripts de terceros

Cada plugin activo carga su propio CSS y JavaScript en todas las páginas, incluso donde no se usa: un formulario que solo aparece en Contacto suele cargarse también en el blog. El problema rara vez es cuántos plugins tienes, sino cuántos meten código en el frontend.

Hosting compartido de bajo costo

Tu sitio comparte procesador y memoria con decenas de sitios: cuando uno tiene un pico, tu tiempo de respuesta sube. Se detecta con el TTFB. Si el servidor tarda más de medio segundo en enviar el primer byte, ninguna optimización de imágenes te salva.

Sliders y videos en la portada

Un slider carga todas sus diapositivas aunque el visitante solo vea la primera, y un video de fondo puede pesar más que el resto de la página junta. Son los dos elementos que más veces vuelven lenta una portada.

Fuentes web cargadas de forma bloqueante

Si el navegador debe descargar la tipografía antes de mostrar el texto, tu contenido queda invisible mientras tanto. Aloja las fuentes en tu servidor, precarga solo las que usas y aplica font-display: swap: eso evita el bloqueo y el salto cuando entra la fuente definitiva.

Píxeles de publicidad y chats en vivo

El píxel de Meta, la etiqueta de Google Ads y el chat en vivo cargan código de otro servidor sobre el que no tienes control. Son la causa más frecuente de un INP malo: la página se ve, pero no responde. La solución es retrasar su carga hasta la primera interacción.

Falta de caché y de CDN

Sin caché, WordPress reconstruye la misma página desde la base de datos en cada visita. Una CDN es una red de servidores distribuidos que sirve para entregar tus archivos desde un punto cercano al visitante.

Qué arreglar primero: el orden por impacto vs esfuerzo

El orden correcto es de arriba hacia abajo en esta tabla: primero lo de impacto alto y esfuerzo bajo, y solo al final lo que exige migración o rediseño. La mayoría de los sitios cambia de estado en Search Console con las tres primeras filas, sin tocar el diseño.

Advertencia sobre la última fila: cambiar de hosting es lo que más gente hace primero y lo que más veces resulta innecesario. Mide el TTFB antes. Si vas a rehacer el sitio, revisa lo que realmente necesita tu página web en WordPress para no construir sobre las mismas causas.

¿Por qué tu portada suele ser la página más lenta del sitio?

Porque es la página donde todo el mundo quiere poner algo: el slider de mercadeo, el video institucional, el mapa de sedes, el feed de Instagram y el chat en vivo. Cada área suma un elemento y nadie quita ninguno.

Los datos confirman el patrón. Solo el 48% de los sitios aprueba las tres métricas de Core Web Vitals en móvil y el 56% en escritorio, y las páginas de inicio rinden peor que las internas —45% frente a 56% en móvil—, según el Web Almanac 2025 de HTTP Archive, con datos de CrUX. La página que usas para tu pauta es, en promedio, la peor del sitio.

Qué hacer. Deja una sola imagen destacada arriba, precárgala y no le pongas lazy loading: ese error es una de las causas más frecuentes de un LCP malo, porque el navegador retrasa justo la imagen que define la métrica. Reemplaza el video de fondo por una imagen con botón de reproducción y difiere la carga del feed de Instagram.

¿Optimizar o rehacer? Cómo decidir

Optimizar tiene sentido cuando la estructura funciona y el problema es de peso y de orden de carga. Rehacer tiene sentido cuando el problema es la base. Y hay un tercer caso, el más incómodo de decir: cuando no deberías gastar en ninguna de las dos cosas todavía.

No compres una optimización de velocidad si estás en alguno de estos escenarios. Si tu sitio recibe menos de unos cientos de visitas al mes, el cuello de botella es de tráfico y el dinero rinde más en contenido. Si tu página carga en 2 segundos y ya aprueba las tres métricas, estás pagando por decimales que ningún cliente va a notar. Si vas a rediseñar en los próximos meses, optimizar el tema actual es tirar plata: se pierde en la migración. Y si el problema real es que la página no explica qué vendes ni tiene un formulario visible, ninguna mejora de LCP arregla eso.

Rehacer sale mejor cuando se juntan varias condiciones: el tema tiene más de cuatro o cinco años y ya no recibe actualizaciones, el sitio arrastra un constructor visual pesado con capas de plugins encima, o el diseño no convierte aunque cargue rápido. Si dudas entre las dos rutas, agenda una asesoría estratégica y pide la medición de campo antes de cualquier propuesta. Para dimensionar la inversión de un sitio nuevo, este análisis de cuánto cuesta una página web profesional en Colombia tiene los rangos actualizados.

Qué esperar después: plazos y resultados realistas

Los cambios técnicos se ven de inmediato en laboratorio y tardan hasta un mes en verse en Google. Los datos de campo del Chrome UX Report se calculan sobre una ventana móvil de 28 días, según la documentación de Core Web Vitals de web.dev, de Google Chrome (2024). Un sitio optimizado el 1 de julio no muestra su estado real en Search Console sino hacia finales de ese mes.

Los plazos son cortos: comprimir imágenes, activar caché y quitar el slider toma días; retrasar scripts y ordenar las fuentes, una o dos semanas. Copia esta lista y verifica cada punto antes de dar el trabajo por cerrado:

• ☐ LCP de campo en móvil ≤ 2,5 s en la portada y en las tres URLs con más tráfico
• ☐ INP de campo ≤ 200 ms en móvil
• ☐ CLS de campo ≤ 0,1 en móvil
• ☐ La imagen principal de la portada NO tiene loading="lazy" y está precargada
• ☐ Imágenes en WebP o AVIF, con width y height declarados
• ☐ Chat, píxeles y scripts de terceros cargan tras la primera interacción
• ☐ TTFB por debajo de 0,5 s, medido varias veces y a horas distintas
• ☐ Caché de página activa, verificada en incógnito
• ☐ Plugins sin uso desinstalados, no solo desactivados
• ☐ Informe de Search Console revisado 28 días después del cambio
• ☐ Prueba manual en celular de gama media

Una expectativa honesta: aprobar las tres métricas no te sube a la primera posición ni multiplica tus ventas. Quita una fricción que estabas pagando en cada visita.

Preguntas frecuentes

¿Cuánto debe tardar en cargar una página web?

El objetivo concreto es un LCP de 2,5 segundos o menos, el umbral que Google considera bueno para el contenido principal. Lo importante es cómo se mide: no es el promedio de tus visitas ni una prueba en tu computador, sino el percentil 75 de las visitas reales de los últimos 28 días. Es decir: 3 de cada 4 personas que entran a tu sitio deben ver ese contenido antes de los 2,5 segundos.

¿Los Core Web Vitals afectan mi posición en Google?

Sí, pero menos de lo que muchas agencias venden. Son una señal de experiencia de página dentro de un sistema que pondera sobre todo la relevancia y la calidad del contenido. Entre dos páginas que responden igual de bien a la búsqueda, la más rápida tiene ventaja; una página rápida con contenido pobre no supera a una lenta con contenido excelente. El argumento fuerte para optimizar no es el ranking: es la conversión.

¿Puedo arreglar la velocidad solo con un plugin de caché?

Ayuda bastante, pero rara vez alcanza. Un plugin de caché guarda una versión ya construida de la página para no rehacerla en cada visita, y eso mejora el tiempo de respuesta del servidor. Lo que no resuelve es el peso de tus imágenes, el JavaScript de los plugins que cargan en todas las páginas, los scripts de terceros que traban la interacción ni los saltos que generan un CLS malo.

¿Mi hosting es el problema?

A veces, y hay una forma de comprobarlo antes de gastar en una migración. Mide el TTFB, el tiempo que tarda el servidor en enviar el primer byte: es el dato que separa un problema de hosting de uno de la página. Si se mantiene por encima de medio segundo en mediciones repetidas y en varias URLs, el servidor sí aporta al problema. Si el TTFB es bajo y la página igual tarda, la culpa está en lo que cargas.

¿Cuánto cuesta optimizar la velocidad de un sitio en Colombia?

DINOLABS trabaja en Colombia con un rango de referencia de 1.000.000 a 6.000.000 de pesos para un proyecto de página web y de 50.000 a 300.000 pesos mensuales de mantenimiento. Una intervención de velocidad se cotiza dentro de ese marco y depende del diagnóstico: no cuesta lo mismo comprimir imágenes y activar caché que reordenar los scripts de un sitio con veinte plantillas. Pide siempre la medición de campo antes de la propuesta.

¿En cuánto tiempo veo el cambio en Search Console?

Hasta 28 días. Los datos de campo que usa Google se calculan sobre una ventana móvil de 28 días, así que el informe de Core Web Vitals mezcla, durante todo ese periodo, visitas anteriores y posteriores a tu optimización. Para verificar de inmediato que el cambio funcionó, usa los datos de laboratorio de PageSpeed Insights: confirman el efecto técnico el mismo día, aunque no sean lo que Google evalúa.