Core Web Vitals en 2026: por qué la velocidad de tu web es factor de posicionamiento, de ingresos, y la prueba de que está bien construida

¿Qué son los Core Web Vitals, exactamente?

Son tres métricas con las que Google mide la experiencia real de cargar y usar una página, y cada una tiene un umbral “bueno” claro. Largest Contentful Paint (LCP) mide la carga —el momento en que el contenido principal, normalmente la imagen hero o el titular, termina de aparecer— y lo bueno es por debajo de 2,5 segundos (corewebvitals.io, 2026). Interaction to Next Paint (INP) mide la respuesta —cuán rápido reacciona la página a cada clic, toque y tecla— y lo bueno es por debajo de 200 milisegundos; reemplazó al First Input Delay en marzo de 2024 y es más estricto, porque reporta la peor interacción de toda la visita, y no apenas la primera (wwwhatsnew, 2026). Cumulative Layout Shift (CLS) mide la estabilidad visual —si el contenido salta mientras la página carga— y lo bueno es por debajo de 0,1 (Local Max, 2026).

El detalle que muchas guías omiten es cómo los mide Google. Las puntuaciones vienen de visitantes reales, no de una simulación de laboratorio: Google usa el percentil 75 de los datos de campo del Chrome User Experience Report en una ventana de 28 días, así que el 75% de tus visitas reales debe tener una buena experiencia para que la página apruebe (Local Max, 2026). Las tres métricas deben estar en verde a la vez; si una está en rojo, la página está en rojo. Por eso una conexión rápida en tu propia laptop casi no dice nada — el número que cuenta es la experiencia en un móvil de gama media, que es la siguiente sección.

¿De verdad son factor de posicionamiento?

Sí, y la versión honesta de esa respuesta tiene un matiz que conviene guardar. Los Core Web Vitals son una señal de posicionamiento confirmada desde 2021, dentro de la actualización de Page Experience — pero funcionan como desempate más que como palanca dominante. La calidad del contenido, la relevancia y la autoridad siguen pesando más, y una página rápida pero pobre no le gana a un contenido fuerte; cuando dos páginas son comparables, gana la más rápida (corewebvitals.io, 2026). Vender el rendimiento como el único arreglo de posicionamiento es deshonesto; venderlo como la ventaja que decide entre páginas igualadas es exacto.

La parte que sorprende a muchos es el dispositivo. Con el mobile-first indexing universal, los Core Web Vitals se volvieron un requisito de higiene: los sitios con métricas en rojo pierden posiciones de forma sistemática frente a competidores con las métricas en verde (Local Max, 2026). En la práctica, una experiencia ultrarrápida en una MacBook con fibra es irrelevante si el sitio se arrastra en un Android de gama media con 4G — esa experiencia más lenta es la que determina tu posición. Y más de la mitad de los sitios no alcanza los umbrales que Google exige (Aippix, 2026), así que el terreno está abierto para quien sí los cumple.

¿Cuánto te cuesta la lentitud?

Más de lo que la mayoría cree, y Google lo documenta en su propio repositorio de casos en vez de dejarlo a estimaciones. Del lado positivo: Rakuten 24 hizo una prueba A/B y halló que alcanzar buen LCP produjo un 33% más de conversiones y un 53% más de ingresos por visitante — un caso que Annie Sullivan, del equipo de Chrome, citó como ejemplo de cómo las métricas centradas en el usuario se traducen en resultados de negocio (ighenatt, 2026). Vodafone mejoró el LCP un 31% y vio un 8% más de ventas, y Amazon halló que cada 100 milisegundos de latencia le costaba un 1% en ventas (wwwhatsnew, 2026).

Del lado negativo, la lentitud pierde clientes en silencio. El 53% de los visitantes móviles abandona un sitio que tarda más de tres segundos en cargar — más de la mitad del público se va antes de ver nada (wwwhatsnew, 2026). Y una mejora de un segundo en el LCP puede aumentar las conversiones hasta un 27% (budaseo, 2026). El caso real lo ilustra: una tienda de moda en Madrid vio caer su conversión móvil un 22% en seis meses sin entender por qué — sus páginas de producto tardaban 4,7 segundos en mostrar la imagen, los banners empujaban el botón de compra mientras cargaba, y cada toque en los filtros congelaba el navegador 380 milisegundos (ighenatt, 2026). No era el producto ni el precio: era la experiencia.

¿Qué páginas corren más riesgo?

Distintos tipos de página fallan distintas métricas, lo que te deja priorizar en vez de adivinar. Los blogs y las páginas de inicio fallan sobre todo el LCP, porque una imagen hero grande suele ser el elemento más lento en cargar. Las páginas de producto y de categoría sufren con el CLS, porque el contenido que se inyecta de forma dinámica —precios, stock, recomendaciones— desplaza el diseño tras el primer pintado. Y los fallos de INP se concentran en las páginas más interactivas: pagos, formularios y listados con muchos filtros, donde un JavaScript pesado corre en cada toque (ighenatt, 2026).

Hay una referencia útil para el mercado hispano: para un e-commerce mediano en España, el benchmark realista es LCP < 2,2 s, CLS < 0,08 e INP < 180 ms, y alcanzarlo pide optimizar las imágenes de producto, gestionar los scripts de terceros y usar prerenderizado para las páginas de categoría (ighenatt, 2026). Los sitios de contenido tienen ventaja en LCP, porque su elemento principal es texto y no una imagen pesada, con líderes que bajan de 1,5 segundos. La lección es la misma de toda la guía: el rendimiento vive en la arquitectura y en los componentes compartidos, no en ajustar páginas de a una.

¿Por qué el INP reprueba a tantos sitios?

Porque el INP es un problema de arquitectura, no un retoque — y deja a la vista cómo se construyó un sitio. Cerca del 43% de los sitios reprueba el umbral de 200 milisegundos, lo que lo convierte en el Core Web Vital que más se falla en 2026 (Aippix, 2026). El LCP y el CLS tienen arreglos conocidos —precargar la imagen hero, fijar dimensiones— pero el INP no se resuelve comprimiendo un archivo ni añadiendo un atributo. Falla cuando el JavaScript bloquea el hilo principal mientras el usuario intenta interactuar, normalmente por scripts pesados de terceros como chats en vivo o trackeadores de marketing que congelan el navegador (Best Solution, 2026). Cómo auditar y domar esos scripts de terceros —la causa más común de ese bloqueo— lo cubre nuestra guía sobre scripts de terceros y rendimiento.

Aquí la arquitectura decide el resultado antes de optimizar nada. Una aplicación de una sola página envía un paquete grande de JavaScript que corre en cada interacción, así que tiende a fallar el INP y necesita un rework profundo para recuperarse — la misma construcción sobre-hidratada que, como cubrimos en nuestra guía sobre los creadores de páginas web y el sitio que posees, a los buscadores a menudo les cuesta leer. Un sitio liviano y prerenderizado envía casi nada de JavaScript, así que aprueba el INP por construcción — y cuál framework elijas decide en gran parte cuánto envías, un intercambio que nuestra guía sobre Astro o Next.js enmarca como contenido frente a aplicación. La métrica que más sitios fallan es la que una arquitectura sólida nunca tiene que perseguir. Para por qué el JavaScript es el recurso más caro de la web y cómo enviar menos, mira nuestra guía sobre JavaScript y rendimiento web.

¿Por qué Lighthouse 100 no basta?

Porque Lighthouse es una prueba de laboratorio, y Google posiciona con el campo. Lighthouse corre una carga simulada en una sola máquina y sirve de verdad para encontrar problemas, pero la evaluación que afecta tu posición viene del Chrome User Experience Report: visitas reales, dispositivos reales, redes reales, en el percentil 75 (corewebvitals.io, 2026). Una puntuación verde en laboratorio que no esté respaldada por datos de campo es una hipótesis, no un resultado, y muchos equipos celebran un Lighthouse perfecto que la variabilidad de los dispositivos reales reprueba después.

La solución no es desconfiar del laboratorio, sino construir para que ambos coincidan. Un sitio que es rápido porque es liviano —entrega estática, poco JavaScript, imágenes con el tamaño correcto, fuentes y diseño que no saltan— saca cerca de 100 en Lighthouse y aprueba en el percentil 75 en campo al mismo tiempo, porque los dos miden la misma realidad de fondo. La brecha entre laboratorio y campo solo se abre cuando la velocidad se pega al final, tapando una construcción pesada. Cuando el rendimiento es parte de cómo se hace la página, los dos números se mueven juntos.

¿Qué hace rápido a un sitio de verdad?

Cada métrica tiene causas distintas, así que los arreglos son específicos y no un interruptor mágico. El LCP suele estar limitado por cuánto tarda el elemento principal en cargar y renderizar: sirve la imagen hero con prioridad alta (fetchpriority="high") y nunca la cargues en diferido, usa formatos modernos como AVIF o WebP —que pesan entre un 30 y un 50% menos—, precarga los recursos críticos, baja el tiempo de respuesta del servidor (TTFB, idealmente < 300 ms) con caché y una CDN, y elimina el CSS y el JavaScript que bloquean el render (wwwhatsnew, 2026; Local Max, 2026) — los archivos que mantienen una página en blanco aun con su contenido listo, que cubre nuestra guía sobre recursos que bloquean el renderizado. Esa capa de caché merece entenderse por sí sola — nuestra guía sobre el caché web cubre cómo volver casi instantáneas las visitas repetidas. El CLS viene casi siempre de dimensiones ausentes: da a cada imagen, video e iframe un ancho y un alto explícitos, reserva espacio para lo que se inyecta, y reduce el salto de fuentes autoalojándolas con la configuración correcta de font-display (corewebvitals.io, 2026).

El INP es el de arquitectura: divide las tareas largas en pedazos, difiere el JavaScript no crítico, cede el hilo principal durante las interacciones y, sobre todo, envía menos JavaScript de entrada. Fíjate en el patrón de las tres: las mayores ganancias son estructurales —qué cargas, cuánto código corre, cómo se arma la página— no cosméticas. Y la data lo confirma: los sitios que mejor rinden adoptaron arquitecturas de generación estática como Astro con CDN en el borde, donde un LCP por debajo de 1,2 segundos es alcanzable (ighenatt, 2026). Una página construida liviana desde el inicio ya tomó la mayoría de estas decisiones bien — por eso los sitios más rápidos rara vez parecen “optimizados para velocidad”. Solo están bien hechos. Para un recorrido paso a paso de cómo diagnosticar y arreglar cada métrica, mira nuestra guía sobre cómo aprobar los Core Web Vitals. Y como las imágenes son la causa más común de un LCP lento, nuestra guía sobre cómo optimizar las imágenes para la web suele ser el lugar más rápido para empezar. Las fuentes web son la otra mitad de ese primer pintado — la cubre nuestra guía sobre autoalojar tus fuentes para el rendimiento.

¿Por qué el número verde es el mismo trabajo que la accesibilidad, la legibilidad-IA y el coste?

Porque todos descansan sobre un mismo cimiento: una página liviana, semántica y entregada de forma estática. Es la idea del signo de nuestro nombre —un infinito, donde cinco asuntos son un mismo lazo continuo y no cinco facturas separadas. La página que aprueba los Core Web Vitals envía poco JavaScript y HTML limpio, que es justo la página que un rastreador y un asistente de IA pueden leer, el tema de nuestra guía sobre si tu sitio es legible para la IA. Ese mismo marcado semántico y bien estructurado es el que recorre un lector de pantalla, que es cómo el sitio cumple la ley de accesibilidad de nuestra guía sobre si la accesibilidad web es obligatoria.

Y la misma construcción que es rápida, legible y accesible no se degrada hacia las facturas aplazadas que describimos en nuestra guía sobre cuánto cuesta una página web — no pierde tráfico orgánico, no reprueba una auditoría ni pide una reconstrucción para recuperarse. No compras rendimiento, accesibilidad, legibilidad-IA y bajo costo de propiedad como cuatro partidas. Construyes una buena página, y satisface las cuatro a la vez. La puntuación verde de Core Web Vitals es la más visible de las cuatro — el marcador que, cuando marca 100, te dice que las otras tres también son verdad.

¿Vale la pena perseguir el 100/100?

Vale la pena alcanzarlo, no obsesionarse — y la diferencia importa. Perseguir un número de laboratorio perfecto puede llevar a un equipo a rendimientos decrecientes, ajustando para una prueba sintética mientras los usuarios reales en dispositivos reales siguen sufriendo; el objetivo que Google de verdad premia es aprobar los umbrales en el percentil 75 de los datos de campo. Un sitio que aprueba para usuarios reales con, digamos, un 95 en laboratorio está en mejor lugar que uno que sacó 100 en Lighthouse y reprueba en campo.

La razón por la que igual mantenemos nuestras propias páginas en 100 es que, para un sitio construido liviano, la puntuación perfecta no es una meta a la que uno se esfuerza por llegar — es lo que produce una arquitectura correcta, y de paso sirve de prueba. Nuestra página principal se audita a sí misma frente a ti, subiendo de cero a cien mientras carga, porque un estudio que presume de rendimiento debería estar dispuesto a mostrar el propio. La puntuación no es vanidad; es evidencia de que el sustrato de abajo —el mismo que hace al sitio legible, accesible y duradero— es sólido. Cuando el número es honesto, es la forma más corta de demostrar el conjunto.

¿Cómo mantienes el sitio rápido con el tiempo?

Tratas el rendimiento como una práctica, no como un arreglo único — porque un sitio cambia sin parar, y cada cambio te puede costar milisegundos. Imágenes nuevas, un script de terceros, un widget de reseñas o un banner de última hora en la zona visible pueden volver a romper el CLS o empujar el INP por encima del límite en un solo despliegue. Los equipos que sostienen buenas puntuaciones son los que vigilan los datos de campo de forma continua y protegen lo ganado, en vez de optimizar una vez y suponer que aguanta.

El enfoque que dura es un presupuesto de rendimiento defendido en el tiempo: mira el Chrome UX Report en Search Console, caza las regresiones a nivel de plantilla antes de que se esparzan por el sitio, y recuerda que los datos de campo se mueven con un retraso de 28 días, así que un arreglo real no aparece al instante. Nada de esto es exótico, y la mayoría sobra cuando la velocidad se diseñó en vez de pegarse después. Un sitio construido liviano arranca con el presupuesto intacto, lo que vuelve el trabajo continuo en mantener bueno algo bueno — mucho más barato que rescatar un sitio pesado que nunca fue rápido. El rendimiento, como el resto del lazo, es más fácil cuando nunca se pegó al final. Y como un sitio más liviano es también uno más bajo en carbono, la misma disciplina encoge en silencio la huella de carbono de tu sitio — velocidad y sostenibilidad son una sola optimización.