En Core Web Vitals 2026 siguen centrados en tres métricas de Google: LCP, INP y CLS. Para su proyecto, esto cambia sobre todo las prioridades: cargar rápido el elemento principal, responder con rapidez a las interacciones y evitar los desplazamientos visuales. No es una garantía de mejor posicionamiento, pero un sitio lento cuesta en conversiones, en presupuesto de medios y en confianza del usuario.
Core Web Vitals 2026: lo que Google mide realmente
En 2026, Google no ha anunciado un nuevo trío de métricas. La documentación de Search Central mantiene LCP, INP y CLS como señales de Core Web Vitals para la búsqueda. Los umbrales considerados buenos siguen siendo: LCP en 2,5 segundos, INP por debajo de 200 ms y CLS por debajo de 0,1.
El LCP, de Largest Contentful Paint, mide el tiempo necesario para mostrar el elemento visible más grande durante la carga: a menudo una imagen de banner, un bloque de texto o un vídeo de portada. El INP, Interaction to Next Paint, mide la capacidad de respuesta tras una interacción del usuario, por ejemplo un clic en un botón o la apertura de un menú. El CLS, Cumulative Layout Shift, mide los desplazamientos visuales inesperados, como un botón que baja en el momento en que el usuario iba a hacer clic.
El cambio reciente que hay que tener en cuenta es del 12 de marzo de 2024: el INP sustituyó al FID, First Input Delay, como Core Web Vital de capacidad de respuesta. Es más exigente, porque el INP observa el conjunto de las interacciones lentas de una página, no solo la primera.
El verdadero impacto SEO: útil, pero no mágico
La pregunta de negocio es sencilla: ¿hay que invertir en los Core Web Vitals 2026 para ganar posiciones en Google? Sí, si su sitio es lento o inestable. No, si piensa que un score verde va a compensar un contenido débil, una oferta poco clara o una arquitectura SEO mal planteada.
Google indica que unos buenos Core Web Vitals, o unos buenos rapports proporcionados por herramientas de terceros, no garantizan las primeras posiciones. Sus sistemas buscan recompensar una buena experiencia de página global, no solo una o dos métricas técnicas. Los artículos SEO que presentan estas señales como un factor decisivo o como un criterio confirmado para los AI Overviews suelen ir más allá de las fuentes primarias de Google.
En la práctica, el impacto rara vez es aislado. Un sitio más rápido mejoraore también la tasa de conversión, la tasa de rebote, la performance de las páginas de destino Anuncios Google y la percepción de seriedad. Si está decidiendo entre SEO y adquisición de pago, la performance web debe entrar en el cálculo, como se explica en nuestro enfoque de reparto del presupuesto entre Google Ads y SEO.
Sinceramente, corrigir 300 milisegundos en un sitio que ya está muy sano no cambiará su año. En cambio, pasar de una página de producto con 5 segundos de LCP móvil a menos de 2,5 segundos puede reducir una fricción comercial real.
¿Qué herramientas utilizar sin perderse en los scores?
Google recomienda varias fuentes complementarias: el rapport de Core Web Vitals de Search Console, PageSpeed Insights, el Chrome UX Report también llamado CrUX, y las herramientas de medición asociadas. Su principal interés es distinguir los datos de campo, procedentes de usuarios reales, de las pruebas de laboratorio realizadas en condiciones simuladas.
PageSpeed Insights utiliza los datos de CrUX cuando están disponibles y muestra métricas reales como FCP, LCP, CLS e INP. Google se basa en el percentil 75: dicho de otro modo, se observa una experiencia representativa de los usuarios que ya sufren cierta frustración, no la media confortable.
Una trampa frecuente: lanzar PageSpeed Insights sobre una página de inicio, obtener un score correcto y luego creer que todo el sitio está sano. Las páginas de categorías, fichas de producto, formularios de presupuesto, artículos de blog y páginas de destino publicitarias pueden tener comportamientos muy diferentes. En los proyectos que llevamos, a menudo vemos páginas internas más críticas que la página de inicio, porque acumulan filtros, scripts de marketing, opiniones de clientes, mapas integrados y vídeos.
| Métrico | Umbral de Google “bueno” | Lo que revela | Correcciones típicas |
|---|---|---|---|
| LCP | En 2,5 s | Velocidad de visualización del contenido principal | Imágenes optimizadas, caché, CDN, servidor más rápido |
| INP | Menos de 200 ms | Capacidad de respuesta tras clic, escritura o interacción | JavaScript aligerado, tareas largas divididas, scripts de terceros limitados |
| CLS | Menos de 0,1 | Estabilidad visual durante la carga | Dimensiones de imágenes, espacios reservados, fuentes mejor cargadas |
Las optimizaciones que de verdad importan
El LCP rara vez se consigue con un solo botón mágico. La recomendación de web.dev actualizada en 2025 consiste en descomponer el LCP en subpartes para encontrar el cuello de botella: tiempo del servidor, retraso antes de la carga del recurso, duración de la descarga o retraso de renderizado. Este diagnóstico evita comprimir encore una imagen alors que el verdadero problema proviene de un servidor saturado.
Para un sitio WordPress, las mejoras más rentables suelen ser bastante concretas: caché de página, imágenes WebP o AVIF, tema menos pesado, fuentes locales o mejor precargadas, limitación de las extensiones que inyectan JavaScript por todas partes. Lors de una rediseño WordPress con reto SEO, tratar estos puntos antes de la puesta en línea cuesta menos que reparar después de una caída de rendimientormance.
El INP requiere otra lógica. Hay que identificar las interacciones lentas y luego corrigirlas una por una. Google recuerda que, después de haber corrigido una interacción lenta, pueden aparecer otras como nuevos puntos débiles; es normal, y por eso una medición en campo importa más que una prueba puntual.
El CLS, por su parte, suele deberse a detalles descuidados. Imágenes sin anchura ni altura declaradas, anuncios o iframes sin espacio reservado, contenido inyectado dinámicamente y fuentes web que cambian la maquetación figuran entre las causas recurrentes enumeradas por web.dev en 2025. Un banner de cookies o un módulo de reseñas que empuja el contenido después de la carga puede bastar para degradar la experiencia.
- Priorice los modelos de página que se reporten: páginas de venta, presupuesto, inscripción, ficha de producto.
- Mida primero en móvil, sobre todo si su tráfico proviene de Google Search o de las redes sociales.
- Elimine los scripts de terceros innecesarios antes de optimizar el código de la aplicación.
- Reserve el espacio de imágenes, vídeos, embeds, anuncios y banners desde el HTML inicial.
- Pruebe después de la puesta en producción, porque los datos de campo pueden diferir del staging.
Presupuesto y plazos: qué esperar en Francia
Una auditoría seria de Core Web Vitals para un sitio web corporativo o un WordPress de pyme suele situarse en torno a 800 a 2 500 € sin IVA según el número de plantillas de página y la profundidad de las pruebas. Para un e-commerce o una aplicación web con recorrido conectado, el alcance puede subir hasta alrededor de 3 000 a 7 000 € sin IVA, porque hay que probar estados de usuario, filtros, carritos, formulaires y scripts de pago.
La correction varía aún más. En un sitio sano pero mal configurado, bastan unos pocos días: caché, compresión, imágenes, CDN vía Cloudflare o ajustes del servidor en OVHcloud, Scaleway o un proveedor de alojamiento gestionado. En un front-end pesado, con mucho JavaScript React, Vue, Next.js o un tema WordPress sobrecargado, cuente más bien con dos a seis semanas de trabajo.
Con ese presupuesto, a veces es mejor rehacer una plantilla crítica que intentar salvar una acumulación de extensiones. Es el caso típico de una página de inicio construida con un maquetador visual, varios sliders, un vídeo de fondo, tres píxeles publicitarios y una biblioteca de animaciones. La solución evidente, instalar una extensión adicional de performance, se convierte entors en la mala solución.
El coste también debe compararse con la pérdida de ingresos. Si una página de captación de pago recibe 10 000 visitas al mes, una mejororación modesta de la tasa de conversión puede financiar la optimización. Por el contrario, optimizar al milímetro una página institucional con pocas visitas no es necesariamente prioritario.
Casos particulares: rediseño, migración y aplicación web
Un rediseño es el momento de mayor riesgo. El diseño cambia, las imágenes cambian, los scripts cambian y, a veces, el alojamiento también cambia. Las performances pueden mejororar notablemente o degradarse sin que nadie lo vea antes de la puesta en producción.
Para reducir el riesgo, integre las Core Web Vitals en el pliego de validación al mismo nivel que las redirecciones, las etiquetas title o los formulaires. Si se prevé una migración, la lista de comprobación de migración de sitio debe incluir mediciones antes/después en las páginas con mucho tráfico. De lo contrario, no sabrá si una bajada de tráfico viene del SEO, de la técnica o de ambos.
Las aplicaciones web plantean un problema distinto: el usuario no se limita a leer, hace clic, filtra, guarda, carga tablas y abre modales. El INP se vuelve entors más sensible que el LCP. La elección del runtime JavaScript del lado del servidor, por ejemplo entre Node.js, Deno o Bun, también puede influir en ciertos tiempos de respuesta en arquitecturas modernas; el tema merece un arbitraje técnico aparte, como en nuestra comparación de los runtimes JavaScript en 2026.
Del lado de la agencia, el reflejo es no prometer un score universal, sino fijar objetivos por tipo de página y por contexto: móvil, país objetivo, alojamiento, volumen de scripts de marketing, restricciones del RGPD y dependencias del negocio. Es menos espectacular que un score de 100, pero mucho más fiable para gestionar un presupuesto.
Lo que hay que evitar en 2026
Primera trampa: confundir performance y apariencia de performance. Un sitio puede mostrar un loader elegante y al mismo tiempo retrasar el contenido útil. Para Google como para el usuario, eso no es una mejora.
Segunda trampa: tratar las Core Web Vitals después de todas las decisiones gráficas. Una tipografía exótica, un vídeo a ancho completo o un carrusel pesado pueden ser aceptables, pero hay que medir su coste. La buena decisión no siempre es eliminar; a veces, comprimir, diferir o reservar el espacio es suficiente.
Tercera trampa: apilar herramientas. Tag Manager, píxeles publicitarios, chat, heatmaps, A/B testing, reseñas, consentimiento de cookies, captcha, monitoring. Cada uno parece razonable. En conjunto, pueden degradar el INP y ralentizar el renderizado. Una auditoría periódica de los scripts de terceros suele ser más rentable que una optimización avanzada del framework.
Por último, no base una estrategia de 2026 en promesas sobre las AI Overviews. Un estudio de arXiv publicado el 13 de mayo de 2026 observa que cerca del 30 % de los dominios citados en las AI Overviews no figuran en la primera página organique, lo que sugiere un mecanismo de selección distinto. No demuestra que las Core Web Vitals determinen esas citas.
Definir este tipo de proyecto con antelación evita la mayoría de las malas sorpresas: perímetro de las páginas, métricas objetivo, restricciones de marketing, alojamiento y seguimiento tras la puesta en producción. A menudo es ahí donde una mirada externa ahorra tiempo, sobre todo cuando la performance afecta a la vez al SEO, al diseño y al desarrollo.
FAQ sobre las Core Web Vitals 2026
¿Cuáles son los Core Web Vitals en 2026?
Los Core Web Vitals 2026 son LCP para la carga principal, INP para la capacidad de respuesta y CLS para la estabilidad visual. Google no ha anunciado ningún cambio de métricas ni de umbrales en las fuentes primarias recientes.
¿Basta con un buen Core Web Vitals para ser el primero en Google?
No. Google recomienda encarecidamente unos buenos Core Web Vitals para la experiencia del usuario y la búsqueda, pero precisa que eso no garantiza un buen posicionamiento. El contenido, la intención de búsqueda, la popularidad y la experiencia global siguen siendo determinantes.
¿Cuánto cuesta una optimización de Core Web Vitals?
En Francia, una auditoría suele empezar en torno a 800 a 2 500 € HT para un sitio web de pyme. Las corrections pueden ir de unos pocos días a varias semanas según el CMS, el JavaScript, el alojamiento y el número de páginas críticas.
¿Es suficiente PageSpeed Insights para decidir?
PageSpeed Insights es un buen punto de partida, sobre todo gracias a los datos de CrUX cuando existen. Para decidir un presupuesto, compáralo con Search Console, pruebas por plantilla de página y los datos reales de conversión.