Core Web Vitals en 2026: qué ha cambiado y qué sigue importando

Durante años se ha hablado de la velocidad web como si todo se redujera a sacar buena nota en PageSpeed Insights. En 2026 ese enfoque se queda corto. Las Core Web Vitals siguen siendo importantes, sí, pero el debate ya no es "sacar 100 en PageSpeed": es construir webs que se carguen rápido, respondan bien y no se muevan mientras el usuario las usa, en móvil y en condiciones reales.

En este artículo te contamos qué ha cambiado de verdad, qué métricas hay que mirar hoy y, sobre todo, cómo lo trabajamos nosotros en proyectos reales, incluida nuestra propia web.

1. Por qué seguimos hablando de Core Web Vitals en 2026

Muchas webs han mejorado visualmente en los últimos años, pero siguen siendo lentas. La causa más habitual no es un servidor barato: es la acumulación de capas. WordPress con un constructor visual encima, ese constructor con sus propios scripts, un par de plugins de formularios, otro de cookies, un chat, un píxel, una herramienta de mapas de calor y nadie revisa qué se carga en cada página.

El resultado lo vemos casi cada semana en auditorías:

• Webs bonitas que en móvil tardan 4 o 5 segundos en mostrar lo importante.
• Menús que se "atascan" medio segundo al pulsarlos.
• Imágenes hero de 800 KB que podrían pesar 60.
• Layouts que se mueven al cargar fuentes, banners de cookies o publicidad.

Las Core Web Vitals no son "el SEO", pero sí son una parte cada vez más importante de una web bien construida. Y, sobre todo, son síntomas: cuando una web va mal en estas métricas, casi siempre hay decisiones técnicas previas que también están frenando el posicionamiento y la conversión.

Una web rápida no garantiza posicionar. Una web lenta sí puede limitar mucho el rendimiento SEO.

2. Qué son las Core Web Vitals hoy

Hoy las tres métricas que Google considera principales son LCP, INP y CLS. Cada una mide una dimensión distinta de la experiencia: cuánto tarda en aparecer lo importante, cómo responde la página cuando interactúas y si el contenido se mueve mientras carga.

2.1. LCP - cuánto tarda en cargar lo importante

LCP (Largest Contentful Paint) mide el tiempo que tarda en aparecer el elemento más grande visible en la pantalla: normalmente la imagen principal, un H1 grande o un bloque destacado.

• Bueno: hasta 2,5 segundos.
• Necesita mejorar: entre 2,5 y 4 segundos.
• Malo: más de 4 segundos.

Qué suele empeorar el LCP:

• Imágenes hero gigantes sin comprimir y sin formatos modernos.
• Servidores lentos o con TTFB alto.
• CSS y JavaScript que bloquean el renderizado.
• Fuentes web cargadas sin preload ni font-display: swap.
• Sliders que cargan tres o cuatro imágenes "por si acaso".
• Plantillas pesadas que arrastran 200 KB de CSS antes de pintar nada.

2.2. INP - cómo responde la web cuando el usuario interactúa

Este es el cambio más importante de los últimos años, y todavía hoy lo vemos pasar por alto. Antes hablábamos de FID (First Input Delay), que solo medía la primera interacción. Desde marzo de 2024, Google sustituyó FID por INP (Interaction to Next Paint), que mide la capacidad de respuesta a lo largo de toda la visita, no solo del primer clic.

• Bueno: menos de 200 ms.
• Necesita mejorar: entre 200 y 500 ms.
• Malo: más de 500 ms.

Esto cambia las reglas. Una web puede tener un primer clic rápido, pero ir cada vez peor según el usuario abre el menú, hace scroll, pulsa filtros o envía un formulario. INP captura ese deterioro.

Qué afecta al INP:

• Acumulación de JavaScript (especialmente de terceros).
• Menús móviles construidos con frameworks pesados para un comportamiento que se puede resolver con 30 líneas de CSS y JS.
• Formularios con validaciones que bloquean el hilo principal.
• Chats, mapas de calor y píxeles que se ejecutan al mismo tiempo.
• Constructores visuales que generan HTML/JS innecesario alrededor de cada bloque.

2.3. CLS - que la página no "salte" mientras carga

CLS (Cumulative Layout Shift) mide la estabilidad visual: si el contenido se mueve mientras el usuario está leyendo o intentando pulsar algo.

• Bueno: menos de 0,1.
• Necesita mejorar: entre 0,1 y 0,25.
• Malo: más de 0,25.

Lo más habitual:

• Imágenes sin width y height definidos.
• Fuentes web que cambian el tamaño del texto al cargar.
• Banners de cookies, avisos o anuncios que aparecen tarde y empujan el contenido.
• Embeds (YouTube, mapas, formularios externos) sin espacio reservado.
• Elementos sticky que se activan tarde y reorganizan el layout.

3. Qué ha cambiado realmente en 2026

Mucho artículo nuevo habla como si cada año hubiera una revolución. No es así. En 2026 no ha aparecido una métrica que lo cambie todo. Lo que ocurre es que ahora INP ya está plenamente consolidada y muchas webs que en su día "pasaban" Core Web Vitals con FID hoy tienen problemas reales de interacción que antes ni se medían.

3.1. INP ha desenmascarado a muchas webs

FID era una métrica generosa: si la primera interacción iba bien, contabilizaba como buena. INP es mucho más exigente porque mide percentiles altos de respuesta a lo largo de toda la visita. Webs que antes tenían "todo verde" hoy aparecen en ámbar o rojo, sobre todo en móviles de gama media.

3.2. Ya no basta con optimizar la home

Es un error muy típico: la empresa optimiza la home, presume del 95 en PageSpeed y se olvida del resto. Pero los usuarios entran por landings SEO, fichas de servicio, artículos de blog y formularios. Y ahí es donde suelen estar los problemas:

• Fichas de servicio con sliders y testimonios animados.
• Categorías y listados con filtros lentos.
• Landings SEO heredadas de plantillas antiguas.
• Formularios largos con scripts de terceros.
• Páginas con mapas, calendarios o buscadores embebidos.

3.3. Laboratorio vs. datos reales

PageSpeed Insights y Lighthouse son datos de laboratorio: una simulación en un entorno controlado. Útiles, pero no son la verdad. La verdad la dan los datos de campo (CrUX) que Google muestra en Search Console: lo que están experimentando usuarios reales, con sus dispositivos y sus conexiones.

Una web puede sacar 95 en una prueba puntual de Lighthouse y, a la vez, tener un 30% de visitas en móvil con LCP por encima de 4 segundos. No es contradictorio: es que la prueba se hizo en un escenario ideal y los usuarios reales no están en ese escenario.

La regla práctica: PageSpeed te dice dónde mirar; Search Console te dice a quién le está pasando.

4. Qué sigue funcionando hoy para mejorar Core Web Vitals

4.1. Imágenes bien resueltas, no solo "comprimidas"

Convertir a WebP o AVIF, servir tamaños distintos según el dispositivo con srcset, definir siempre width y height, hacer lazy load solo donde tiene sentido (nunca en la imagen hero), y no servir un PNG de 2.000 px de ancho a un móvil que necesita 400. Suena básico, pero es donde más kilobytes se ganan en un día de trabajo.

4.2. Menos JavaScript, mejor JavaScript

En la mayoría de proyectos que auditamos el problema no es una imagen concreta: es la acumulación de scripts. Constructores visuales que generan código alrededor de cada bloque, plugins que cargan jQuery aunque ya esté en el tema, píxeles de Meta y de Google, un chat de soporte, un widget de reseñas, una herramienta de analítica adicional y entre todos pueden añadir 800 KB de JavaScript que el navegador tiene que procesar antes de responder a un clic.

Lo que hacemos en proyectos serios:

• Revisar todo lo que se carga y cuestionar cada script.
• Diferir o cargar bajo demanda lo que no es crítico.
• Sustituir librerías pesadas por código propio cuando aporta poco.
• Eliminar dependencias muertas que llevan dos años cargándose por inercia.

4.3. Buen hosting y buena arquitectura

Un buen hosting reduce el TTFB y mejora directamente el LCP. Caché bien configurada, HTTP/2 o HTTP/3, compresión Brotli o gzip, y CDN cuando el público está distribuido geográficamente. Nada de esto es "magia": es higiene técnica. Pero es lo que diferencia que una misma web tarde 1,2 s o 3,5 s en empezar a pintar.

4.4. El rendimiento se diseña, no se parchea

Esta es probablemente la idea más importante del artículo. El rendimiento no se arregla al final. Cuando una web nace pesada, los esfuerzos posteriores son siempre parches: comprimes imágenes, pero el constructor sigue ahí; quitas un plugin, pero el tema arrastra el doble.

Las decisiones que más impacto tienen se toman antes de escribir la primera línea de código:

• ¿Necesitamos sliders en la home? Casi nunca.
• ¿Necesitamos animaciones en cada sección? Casi nunca.
• ¿Necesitamos un CMS pesado para una web de 12 páginas? Casi nunca.
• ¿Reservamos espacio para cada imagen, embed y banner? Siempre.
• ¿Priorizamos lo que se ve above the fold? Siempre.

4.5. Desarrollo a medida vs. plantillas sobrecargadas

No todas las webs necesitan desarrollo a medida. Pero todas necesitan una base técnica coherente. Muchas veces, una web aparentemente sencilla acaba siendo lenta porque se ha construido sobre una plantilla pesada, con un plugin para cada cosa y sin una estrategia técnica detrás. Y al revés: una plataforma compleja, con filtros, listados y paneles, puede rendir muy bien si se desarrolla con criterio desde el primer día.

5. Lo que hemos hecho en nuestra propia web

Si vamos a hablar de Core Web Vitals con seriedad, lo mínimo es que nuestra propia web aguante el examen.

Cuando rediseñamos seoyconsultoria.com este año tomamos una decisión que va a contracorriente de lo que se hace en la mayoría de agencias: no usar WordPress. No por moda, sino porque para lo que tiene que hacer nuestra web (una web corporativa, centrada en SEO, sin necesidad de un panel de administración complejo), WordPress es exceso de equipaje.

La stack que elegimos:

1. HTML5 estático. Cada página es un archivo .html plano, servido directamente desde el servidor. Sin proceso de build innecesario, sin renderizado en servidor, sin hidratación.
2. CSS3 global. Un único archivo de estilos compartido entre todas las páginas, cacheado por el navegador después de la primera visita.
3. JavaScript vanilla. Lo justo, sin frameworks. Si una funcionalidad se resuelve con 40 líneas de JS estándar, no metemos 90 KB de librería.
4. Sin CMS ni framework de frontend. Nada de WordPress, nada de React, Vue ni Next. El navegador recibe HTML listo para pintar.
5. SEO técnico dentro del propio HTML. Meta tags, canonical y JSON-LD schema escritos directamente en la página, no inyectados por un plugin que puede fallar.

¿Resultado en Lighthouse? Estos son los datos reales de la home a fecha 27 de mayo de 2026:

Móvil:

• Rendimiento: 90
• Accesibilidad: 97
• Prácticas recomendadas: 100
• SEO: 100

Escritorio:

• Rendimiento: 99
• Accesibilidad: 97
• Prácticas recomendadas: 100
• SEO: 100

No lo enseñamos por presumir de números, sino porque es la consecuencia natural de las decisiones de arriba. Cuando el navegador recibe HTML ya armado, con CSS cacheado, sin JavaScript bloqueante y sin un constructor visual generando código alrededor, los Core Web Vitals salen bien casi solos.

Y no es solo nuestra web. Furgonetas.net, otro proyecto propio, marca en móvil 99 en Rendimiento, 91 en Accesibilidad, 100 en Prácticas recomendadas y 100 en SEO. Misma filosofía: base técnica limpia, código propio donde aporta, y nada superfluo.

La pregunta que conviene hacerse no es "¿con qué CMS construyo mi web?", sino "¿qué necesita realmente esta web y cuál es la base más simple que cumple ese requisito?".

Esto no significa que defendamos quitar WordPress de todas partes. WordPress tiene sentido en muchos proyectos editoriales, en tiendas con catálogos grandes, en webs donde el cliente publica a diario. Pero meterlo por inercia en una web corporativa de 15 páginas, llenarla de plugins y luego intentar acelerarla a posteriori es trabajo perdido. La base correcta evita ese trabajo desde el principio.

6. En qué hay que fijarse de verdad en 2026

6.1. Móvil primero, y casi en exclusiva

La mayoría de problemas serios aparecen en móvil: peor conexión, menos potencia de procesamiento, pantallas más pequeñas y mucha más sensibilidad a saltos visuales. Si tu web va bien en ordenador pero mal en móvil, tienes un problema, no una victoria parcial.

6.2. Plantillas, no URLs sueltas

Optimizar la home y olvidarse del resto es un clásico. Conviene revisar por tipos de página:

• Home.
• Páginas de servicio.
• Landings SEO.
• Categorías y listados.
• Fichas (de producto, de servicio, de proyecto).
• Artículos de blog.
• Páginas con formularios largos.
• Páginas con mapas, filtros o buscadores.

Cada plantilla suele tener un problema distinto. Y arreglar una plantilla suele arreglar decenas de URLs de golpe.

6.3. Mira los datos reales, no solo Lighthouse

Lighthouse y PageSpeed son herramientas de diagnóstico, no la verdad. La verdad está en el informe de Core Web Vitals de Search Console y en los datos de campo de CrUX. Ahí ves qué páginas están fallando para qué porcentaje de usuarios y en qué métrica.

6.4. Prioriza por impacto

No todo se arregla a la vez. El orden que solemos seguir en auditorías:

1. Plantillas que afectan a muchas URLs.
2. Páginas con más tráfico SEO.
3. Páginas que generan leads o ventas.
4. Problemas que afectan a móvil.
5. Scripts externos prescindibles.

Una optimización que toca una plantilla usada por 200 URLs siempre rinde más que una optimización microquirúrgica en una página puntual.

7. Errores que seguimos viendo en auditorías

Por orden de frecuencia, y sin tono de manual:

• Obsesionarse con sacar 100/100. Pasar de 78 a 92 en una plantilla que afecta a 300 URLs vale infinitamente más que pasar de 96 a 100 en la home.
• Cambiar imágenes pero no tocar JavaScript. Es lo más fácil y por eso lo más habitual. Funciona poco si el cuello de botella son los scripts.
• Instalar otro plugin para arreglar lo que rompió un plugin. El círculo vicioso del CMS sobrecargado.
• Sliders, popups y animaciones que no aportan conversión. Pesan, distraen y muchas veces ni siquiera están medidos.
• Medir solo la home. Ya lo hemos dicho, pero sigue pasando.
• No mirar Search Console. Las métricas de campo están ahí gratis y casi nadie las consulta.
• No diferenciar causas. Mezclar problemas de diseño, desarrollo, hosting y terceros lleva a soluciones a medias.
• No medir después. Se publican cambios y nadie comprueba si realmente han movido la aguja en datos de campo. Tres semanas de espera y vuelta a comparar.

8. Core Web Vitals y SEO: cuánto pesan en realidad

Pongámoslo claro: las Core Web Vitals son una señal de experiencia de página, no el factor decisivo del posicionamiento. Si tu contenido es pobre o no hay intención de búsqueda detrás, una web rápida no te va a salvar. Pero si tu estrategia SEO es sólida y compites en un sector donde varias webs tienen contenidos parecidos, las Core Web Vitals pueden marcar diferencia.

Y aunque no marcaran ninguna diferencia SEO, mejorarlas tendría sentido por otras razones: una web más rápida convierte mejor, retiene mejor, transmite más profesionalidad y reduce los costes de publicidad porque las landings de Google Ads dependen también de estas métricas.

La mejora técnica no sustituye a la estrategia SEO, pero elimina frenos que pueden estar limitando el rendimiento de una web bien planteada.

9. Checklist rápido para revisar tu web en 2026

• ¿La página principal carga en menos de 2,5 s en móvil con 4G?
• ¿La imagen hero está en formato moderno y con tamaño definido?
• ¿Los formularios responden en menos de 200 ms al pulsar enviar?
• ¿El menú móvil se abre instantáneamente o se nota un retardo?
• ¿Hay saltos visuales cuando carga el banner de cookies o las fuentes?
• ¿Cuántos scripts externos cargas? ¿Sabes qué hace cada uno?
• ¿Search Console te marca URLs con problemas de LCP, INP o CLS?
• ¿Tus landings SEO importantes están al mismo nivel que la home?
• ¿Las imágenes del blog están redimensionadas o subes el JPG original?
• ¿Cuántos plugins tienes activos? ¿Cuántos podrías quitar sin que pasara nada?

Si tres o más respuestas no te gustan, hay margen claro de mejora.

10. Conclusión: qué debería hacer una pyme

Para una pyme, las Core Web Vitals no deberían verse como una tarea técnica aislada, sino como parte de una web bien planteada: rápida, clara, estable y orientada a captar negocio. No hace falta una infraestructura de gran empresa ni un equipo de cinco desarrolladores. Hace falta tomar decisiones técnicas con criterio desde el principio y no acumular capas sobre una base débil.

Si tu web recibe tráfico pero no convierte, o si Search Console te está mostrando problemas de Core Web Vitals, podemos ayudarte a revisar qué está pasando y a priorizar las mejoras que realmente tienen impacto. No partimos de plantillas: partimos de tu caso.

¿Quieres que revisemos tu web? Hacemos auditorías técnicas y SEO orientadas a impacto, no a entregar un informe de 80 páginas que nadie va a leer. Contáctanos y vemos por dónde empezar.