Actualizado el 28 de agosto de 2026 · Escrito y verificado por Josué Pérez Suay, CEO de OrbitaClick
PageSpeed en verde no significa Core Web Vitals reales en verde. El laboratorio (Lighthouse) simula una sesión; el campo (CrUX) mide a tus usuarios de verdad durante 28 días — y es lo único que Google usa para ranking.
Umbrales de campo (p75): LCP < 2,5s, INP < 200ms, CLS < 0,1. Por encima de cualquiera, hay pérdida de ranking y de conversión.
Prioriza por ingresos, no por página: el LCP de una ficha de producto o un formulario de presupuesto pesa mucho más que el de un artículo de blog.
Los Core Web Vitals (LCP, CLS, INP) llevan años siendo factor de ranking en Google. Y aun así, en la mayoría de auditorías que hacemos en OrbitaClick encontramos webs que sacan «verde» en PageSpeed Insights pero pierden tráfico orgánico. La razón: la puntuación de laboratorio (Lighthouse) y los datos reales del usuario (CrUX, datos de campo) son cosas distintas — y Google solo cuenta los datos de campo.
Cuando hablamos de Core Web Vitals reales nos referimos a los datos de campo: el percentil 75 de LCP, CLS e INP medido sobre usuarios reales en los últimos 28 días, no una simulación de Lighthouse en un servidor de Google. Si el p75 de LCP supera 2,5s, ya no se está en «verde» aunque PageSpeed dé 95/100 en lab. Y eso es lo que Google penaliza.
Este artículo es para directores de marketing y dueños de PYME que quieren entender qué métrica vigilar realmente, dónde mirarla, qué valores son aceptables y cómo priorizar mejoras técnicas que se traducen en ingresos.
Las 3 métricas y sus umbrales de campo
| Métrica | Qué mide | Umbral bueno (p75) |
|---|---|---|
| LCP (Largest Contentful Paint) | Cuánto tarda en aparecer el elemento principal de contenido — cuándo el usuario percibe que la página «está ahí» | < 2,5 segundos |
| INP (Interaction to Next Paint) | Capacidad de respuesta ante cada interacción: clics, toques, teclado | < 200 milisegundos |
| CLS (Cumulative Layout Shift) | Estabilidad visual — si los elementos «saltan» mientras cargan | < 0,1 |
Para un director, la traducción es sencilla: LCP afecta a la percepción de velocidad, INP a la sensación de control y CLS a la confianza. Si estos indicadores van mal, el usuario siente que la web es lenta, torpe o poco fiable — y eso se traduce en abandono, menos solicitudes de presupuesto, menos ventas y menos recurrencia.
La diferencia crítica entre datos de laboratorio y Core Web Vitals reales
Las pruebas de laboratorio son útiles para diagnóstico técnico, pero se generan en condiciones controladas — un dispositivo concreto, una conexión simulada, una ubicación determinada — y no representan necesariamente la experiencia real del usuario. Un «90/100» en un informe de laboratorio puede esconder problemas graves en usuarios de ciertos países, dispositivos de gama media o conexiones móviles saturadas.
⚠️ Las decisiones de inversión deben basarse en Core Web Vitals reales (datos de campo), no en pruebas de laboratorio. El laboratorio ayuda a entender el «por qué»; el campo define el «cuánto» y el «dónde» priorizar.
Por qué muchos equipos se quedan atrapados en la «puntuación» y pierden de vista el negocio
En no pocas organizaciones, los equipos técnicos trabajan para «poner todo en verde» en determinadas herramientas, se celebra cuando las gráficas mejoran, pero nadie revisa si eso ha supuesto una mejora tangible en conversiones o valor de cada visita. Esto genera tres distorsiones:
- Optimización para la herramienta, no para el usuario. Se sacrifican funcionalidades de negocio solo por mejorar una métrica de reporte.
- Falsa sensación de trabajo hecho. Con las métricas «en verde», dirección puede pensar que lo técnico ya está resuelto, mientras siguen sin tocarse cuellos de botella en rutas críticas de conversión.
- Desconexión entre áreas. Performance, UX, SEO y negocio trabajan con indicadores distintos, sin cuadro de mando común, y nadie responde qué mejoras generan más impacto por unidad de esfuerzo.
Cómo leer Core Web Vitals reales desde dirección: 3 pasos
- Segmentar por tipo de página. No pesa igual el LCP de un artículo de blog que el de una ficha de producto o un formulario de presupuesto — las páginas más cerca de la decisión de negocio tienen prioridad absoluta.
- Segmentar por dispositivo y contexto. Los problemas críticos suelen concentrarse en móvil, y varían por país, tipo de conexión o campaña de adquisición — no tiene sentido invertir igual en todos los segmentos.
- Cruzar rendimiento con conversión. Al cruzar Core Web Vitals con conversión por plantilla, dispositivo o canal aparecen patrones claros: las páginas con peor rendimiento suelen tener tasas de abandono más altas. Esos patrones construyen el caso de negocio para priorizar.
Del KPI técnico al backlog de negocio: cómo priorizar mejoras
Con una visión clara de los Core Web Vitals reales por tipo de página, dispositivo y canal, el siguiente paso es convertir esos datos en un backlog priorizado con una matriz de tres variables:
| Variable | Qué se estima |
|---|---|
| Impacto en negocio | Volumen de tráfico por plantilla, proximidad a la conversión y sensibilidad del usuario a la velocidad en ese punto |
| Esfuerzo estimado | No es lo mismo diferir la carga de un script que rediseñar por completo una plantilla o el flujo de checkout |
| Riesgo de implementación | Ciertos cambios pueden introducir errores en épocas de alta demanda o afectar integraciones sensibles |
Las mejoras de alto impacto, bajo esfuerzo y riesgo asumible van a la parte alta del backlog. Las de impacto moderado y alto esfuerzo pasan a una fase posterior o se vinculan a proyectos de rediseño más amplios.
Qué necesita una empresa para trabajar esto con madurez
🎯 Tres elementos básicos: datos fiables, un marco de gobierno y criterio experto. Paneles que integren experiencia real, conversión y segmentación por tipo de página (no capturas puntuales); alguien responsable de coordinar decisiones entre desarrollo, UX, SEO y marketing; y un equipo o socio que entienda tanto la parte técnica como la de negocio.
Errores frecuentes que una dirección debería evitar
Delegar todo en un único perfil técnico. El rendimiento afecta a diseño, contenidos, SEO y modelos de atribución — no es solo cosa de desarrollo.
Tratar los Core Web Vitals como un proyecto puntual. Cada nueva funcionalidad, campaña o rediseño puede alterar estas métricas: es un proceso continuo, no una tarea que se tacha y se olvida.
No comunicar la lógica de priorización. Si dirección no entiende por qué se invierte tiempo en unos cambios y no en otros, aparece la sensación de «se está programando por programar».
Cómo encaja esto en una estrategia SEO y de marketing madura
Los Core Web Vitals reales no viven aislados: forman parte de un sistema con SEO, contenidos, UX, analítica, campañas de pago y equipo comercial. Cuando se trabaja de forma integrada, una mejora en una página de producto puede coordinarse con una actualización de contenidos, un ajuste SEO OnPage y la campaña de pago que atrae tráfico a esa página — y el impacto se multiplica: no solo carga más rápido, cada visita tiene más probabilidad de convertir.
Conclusión: una palanca de ingresos, no una checklist técnica
La diferencia entre tratar los Core Web Vitals como una simple checklist o como una palanca estratégica es enorme. En el primer caso se invierte en «ponerlo todo en verde» y se genera poco retorno real. En el segundo, se conectan con indicadores de negocio, se priorizan mejoras con criterio y se construye una web más rápida, más fiable y más rentable.
Preguntas frecuentes sobre Core Web Vitals reales
¿Por qué PageSpeed Insights me da buena nota pero pierdo tráfico?
Porque PageSpeed mezcla datos de laboratorio (una simulación) con datos de campo (CrUX) cuando existen. Google solo usa los datos de campo para ranking, así que una buena nota de laboratorio con mal p75 de campo no evita la pérdida de tráfico.
¿Dónde consulto los Core Web Vitals reales de mi web?
En el informe de Experiencia de Search Console, o en web.dev/measure, que muestra el percentil 75 de los últimos 28 días de usuarios reales cuando hay suficiente tráfico para generar el dato de CrUX.
¿Qué pasa si mi web no tiene suficiente tráfico para datos de campo?
Cuando el volumen no alcanza el umbral de CrUX, Google recurre a datos de laboratorio como referencia. En ese caso conviene tratar el laboratorio con más peso, pero sabiendo que no refleja variabilidad real de dispositivos y conexiones.
¿Qué página debo optimizar primero si tengo varias en rojo?
La que combine más tráfico con mayor proximidad a la conversión: normalmente páginas de producto, landings de campaña o formularios, antes que artículos de blog informativos.
¿INP sustituyó a otra métrica?
Sí, sustituyó a First Input Delay (FID) como métrica oficial de interactividad de Core Web Vitals, porque mide la respuesta a todas las interacciones del usuario durante la visita, no solo a la primera.
📚 Fuentes consultadas
📚 Sigue leyendo
- Cómo se satura una página web en WordPressLa aritmética real: procesos PHP disponibles y tu TTFB.
- Hosting SEO: las 4 clavesPor qué el servidor es la palanca de velocidad más ignorada.
- El coste oculto de una migración mal hechaCómo no perder velocidad ni tráfico al cambiar de web.
- SEO técnico para directivosLos 7 indicadores que anticipan caídas antes de que ocurran.
- Optimización de velocidad (WPO)Diagnóstico y mejora de rendimiento a 50 €/hora + IVA.
¿Quieres una auditoría real de Core Web Vitals?
Hacemos auditorías con datos de campo (CrUX), no solo de laboratorio. Entregamos las 5 acciones técnicas priorizadas por impacto en ingresos.
Josué Pérez Suay, CEO y fundador de OrbitaClick, agencia de marketing digital en Alicante desde 2018. Citado en 25 artículos de Computer Hoy como fuente experta.
