CORE WEB VITALS EN 2026

El trabajo relacionado con el rendimiento en 2026 se divide en dos enfoques. El enfoque reactivo optimiza páginas individuales cuando estas caen por debajo de un umbral. El enfoque estructural integra el rendimiento en la elección del marco de trabajo, el sistema de diseño, el proceso de implementación y la gestión del contenido, de modo que el rendimiento sea el resultado predeterminado del trabajo, y no una fase de optimización que se lleve a cabo posteriormente. Todos los sitios web que he visto tener éxito a largo plazo pertenecen al enfoque estructural.

Esta guía ofrece una visión general de la estructura. Incluye cifras concretas de sitios web que he optimizado, las comprobaciones que realizo, los errores más costosos que he cometido y aquellos consejos convencionales que, en la práctica, han resultado ser erróneos. Los datos de campo de CrUX siempre prevalecen sobre los datos de laboratorio de PageSpeed Insights, por lo que la mayoría de las cifras que aparecen a continuación proceden de usuarios reales situados en el percentil 75.

LCP (Largest Contentful Paint)

El tiempo que tarda en cargarse el elemento más grande que aparece en la parte visible de la página. Objetivo: menos de 2,5 segundos en el percentil 75. Es el indicador Core Web Vital más citado y, a menudo, el más fácil de solucionar una vez que se identifica correctamente el elemento LCP. La mayoría de los sitios web tienen una imagen o un bloque de texto destacado como elemento LCP; la solución consiste casi siempre en precargar la imagen, ajustar su tamaño correctamente y asegurarse de que ningún código JavaScript bloquee la carga.

CLS (desplazamiento acumulativo de la maquetación)

En qué medida el contenido de la página se desplaza de forma inesperada durante la carga. Objetivo: por debajo de 0,1. La métrica que más a menudo se incumple debido a imágenes con carga diferida sin anchura ni altura explícitas, a anuncios insertados tras la primera representación o a fuentes web que se sustituyen por otras con métricas diferentes a las de la fuente alternativa. En la mayoría de los casos, esto se puede solucionar siendo riguroso a la hora de especificar las dimensiones explícitas de cada elemento visual situado en la parte visible de la página.

INP (Interacción hasta el siguiente dibujo)

El tiempo de interacción más lento registrado durante el ciclo de vida de la página. Objetivo: menos de 200 ms. Sustituyó al FID en marzo de 2024. Es la métrica de CWV más difícil de manipular, ya que pone de manifiesto las dificultades reales que experimentan los usuarios con JavaScript en tareas de larga duración. Los sitios web con mucho código JavaScript del lado del cliente casi siempre tienen problemas en este aspecto. La solución consiste en enviar menos código JavaScript, dividir las tareas largas en fragmentos más pequeños y utilizar `requestIdleCallback` para las tareas no urgentes.

TTFB (tiempo hasta el primer byte)

Tiempo de respuesta del servidor antes de que pueda comenzar cualquier proceso de renderizado. Objetivo: menos de 600 ms. Aunque no es oficialmente un «Core Web Vital», es el factor que limita todas las demás métricas. Los sitios web con renderizado estático en una CDN suelen alcanzar valores de entre 50 y 150 ms. WordPress en un alojamiento compartido alcanza valores de entre 800 ms y 2,5 s con la caché vacía. La elección del alojamiento es el factor que más influye en el TTFB.

Conclusión clave: Considera «las cuatro métricas que realmente influyen en la clasificación» como una decisión operativa ante todo. Las herramientas solo funcionan cuando la responsabilidad es sincera.

Los datos de laboratorio indican lo que midió un equipo en una ubicación concreta en un momento determinado y en condiciones controladas. Los datos de campo indican la experiencia real de los usuarios a gran escala. Ambos tipos de datos difieren significativamente en la mayoría de los sitios web, y Google utiliza los datos de campo como señales de posicionamiento. Optimiza primero para los datos de campo y, en segundo lugar, para los datos de laboratorio.

Dónde consultar los datos de campo

Search Console > Informe «Core Web Vitals». Conjunto de datos de CrUX en BigQuery si deseas datos sin procesar a nivel de evento. PageSpeed Insights > Sección «Datos de campo» (cuando existen suficientes datos de usuarios reales para la URL). Calibre, SpeedCurve y Treo ofrecen paneles de control mejorados basados en CrUX para usuarios de pago. Las herramientas de RUM (monitorización de usuarios reales), como Vercel Analytics o Cloudflare Web Analytics, aportan un mayor nivel de detalle.

Dónde consultar los resultados de los análisis de laboratorio

PageSpeed Insights > Sección «Datos de laboratorio». Lighthouse en Chrome DevTools. WebPageTest para un análisis detallado en forma de cascada. Resulta útil para diagnosticar las causas de un retroceso en una métrica de campo, no para medirlo.

El proceso de diagnóstico que sigo

Regresión de métricas de campo en Search Console. Identificar el patrón de URL afectado. Realizar pruebas de laboratorio mediante WebPageTest en tres ubicaciones para reproducir el problema. Examinar el gráfico en cascada para localizar la solicitud problemática. Aplicar la corrección. Esperar 28 días a que se actualicen los datos de campo de CrUX. Confirmar la corrección.

Las cifras reales de LCP que he observado en el percentil 75 de los datos de campo en las plataformas en las que más envío:

Astro con generación estática en Netlify o Cloudflare Pages

LCP: entre 0,6 y 1,0 segundos, por lo general. El resultado predeterminado es una puntuación de 100 en Lighthouse en las cuatro métricas. Código JavaScript inicial inferior a 30 KB. Es el nivel más difícil de superar para los sitios web de contenido.

Next.js con generación estática (App Router con RSC, modo SSG)

LCP: de 1,0 a 1,5 segundos. JavaScript inicial: de 80 a 150 KB, dependiendo del número de componentes de cliente que se incluyan. Se puede alcanzar una puntuación de Lighthouse superior a 90, pero requiere una optimización específica.

ISR o SSR en Next.js

LCP: de 1,5 a 2,5 segundos, dependiendo de la tasa de aciertos de la caché y del tiempo de respuesta del servidor de origen. Los fallos de caché en frío duran entre 3 y 5 segundos. Una tecnología excelente con una curva de costes real y una variación real del rendimiento.

WordPress en Kinsta o WP Engine más Cloudflare

LCP de 1,8 a 2,8 segundos, por lo general. Es posible superar los umbrales de CWV con un poco de disciplina. Los sitios que gestiono con esta pila superan el umbral de CWV en el percentil 75 de forma constante tras la ronda de optimización.

WordPress en un alojamiento compartido

LCP de 3,5 segundos o más. Evítalo para cualquier sitio web en el que el rendimiento sea parte de los requisitos.

Las imágenes son el elemento LCP en aproximadamente el 70 % de las páginas de marketing. La gestión de las imágenes es, en mi opinión, el factor que más influye en el rendimiento.

Formato y compresión

El formato WebP con una calidad de 82 ofrece el equilibrio ideal entre calidad visual y tamaño de archivo. El formato AVIF ocupa menos espacio, pero la codificación es más lenta y la compatibilidad con los navegadores presenta algunas pequeñas carencias. Evita utilizar los formatos JPEG y PNG para cualquier imagen que no sea un original de referencia. El formato WebP con q=82 suele generar archivos entre un 70 % y un 90 % más pequeños que el PNG original, sin pérdida perceptible de calidad.

Ajustar el tamaño a las dimensiones reales de la imagen renderizada

Un archivo JPEG de 4K con un ancho de 1200 píxeles supone un desperdicio del 90 % del ancho de banda. Cambia siempre el tamaño a la dimensión mayor en la que se mostrará la imagen, además de incluir una versión de 2x o 3x para pantallas de alta densidad. Sharp lo hace con unas cinco líneas de código en cualquier proceso de compilación de Node.js.

Proceso de creación de héroes de FAL

Generamos imágenes principales mediante FAL flux-pro/v1.1-ultra e Imagen 4 directamente desde el proceso de publicación automática del blog. Las imágenes generadas son archivos JPEG de entre 600 KB y 1,5 MB con una resolución de 1200 x 675. Subir los archivos sin procesar a Supabase Storage supone que cada página envía aproximadamente 1 MB solo en la imagen principal. Antes de subirlas al almacenamiento, las procesamos mediante sharp(buf).resize({width:1600, fit:"inside"}).webp({quality:82}).toBuffer(). Esto reduce el tamaño del archivo en un 90 % sin pérdida perceptible de calidad. Tras aplicar este proceso, observamos un ahorro de 50 MB en todo el sitio web, repartido entre 53 imágenes principales, en un único sitio de Seahawk. Utiliza también cacheControl: 31536000 en la subida al almacenamiento.

Ancho y alto explícitos en cada etiqueta `img`

Los navegadores reservan espacio antes de que se cargue la imagen solo si se especifican el ancho y la altura en el código HTML. Sin ellos, el diseño se desplaza a medida que se cargan las imágenes y aumenta el CLS. Los componentes de imagen de Astro y Next.js gestionan esto automáticamente; las etiquetas `img` sin formato requieren que se haga manualmente.

Precarga de imágenes LCP

La imagen principal situada en la parte superior de la página debe precargarse con el enlace `rel="preload" as="image"` en el encabezado. Normalmente, esto supone un ahorro de entre 100 y 400 ms. Es el cambio de una sola línea con mayor impacto que se puede aplicar en la mayoría de los sitios web de marketing.

JavaScript es el mayor obstáculo para el rendimiento en la mayoría de los sitios web modernos. El presupuesto con el que cuento en 2026:

Código JavaScript inicial de menos de 100 KB en sitios web de contenido

Por debajo de los 100 KB, el marco de trabajo, el sitio web y cualquier píxel de análisis o marketing, en conjunto, siguen cargándose y ejecutándose con la suficiente rapidez en un dispositivo móvil de gama media. Por encima de los 100 KB, el impacto se refleja en las métricas INP y TTI, a menudo de forma imperceptible para el desarrollador de aplicaciones de escritorio que realiza las pruebas en un portátil rápido.

Aplaza todo lo que no esté en la parte visible de la página

Herramientas de análisis, píxeles sociales, widgets de chat, scripts de pruebas A/B. Ninguno de ellos tiene por qué bloquear el «first paint». Utiliza el atributo «defer» o cárgalos cuando el usuario interactúe. La mejora en el CWV suele ser espectacular, y la pérdida de interacción suele ser nula.

Evita incluir componentes pesados del cliente en la parte visible de la página

Un carrusel de personajes que requiere React + framer-motion + 30 KB de código de apoyo para mostrar la primera imagen supone un lastre para el rendimiento. Muestra la primera diapositiva como HTML estático y rellena el carrusel solo cuando el usuario esté a punto de interactuar con él.

Revisar trimestralmente los scripts de terceros

Los scripts de marketing se acumulan sin que nos demos cuenta. Una página web que en 2020 tuviera una sola etiqueta de análisis tendrá ocho scripts en 2026 si nadie la revisa. Realiza una comprobación trimestral mediante Lighthouse o WebPageTest, identifica qué elementos siguen siendo necesarios y elimina todo lo que no lo sea.

Conclusión clave: Considera la «disciplina presupuestaria en JavaScript» ante todo como una decisión operativa. Las herramientas solo funcionan cuando la responsabilidad es sincera.

CSS crítico integrado, el resto aplazado

El CSS necesario para mostrar la parte visible de la página debe incluirse directamente en el elemento `head`. El resto puede cargarse de forma asíncrona. Astro y Next.js se encargan de esto automáticamente gracias a su sistema de ámbito de CSS; en el caso de los sitios web creados manualmente, es necesario realizar un paso de extracción del CSS crítico en el proceso de compilación.

Aloja tú mismo las fuentes y utiliza «font-display: swap»

Las fuentes web cargadas desde Google Fonts suelen añadir entre 100 y 300 ms. El alojamiento propio desde el mismo origen que el sitio web elimina la consulta de DNS. La propiedad `font-display: swap` muestra el texto de reserva de forma inmediata mientras se carga la fuente web, lo que elimina el FOIT (destello de texto invisible). Las fuentes variables, cuando son compatibles, ofrecen varios grosores a partir de un único archivo.

Limita las fuentes a los idiomas que realmente ofreces

Un subconjunto de fuentes latinas ocupa entre 30 y 60 KB. El archivo multilingüe completo suele superar los 250 KB. La creación de subconjuntos supone un cambio de una sola línea en la mayoría de los procesos de compilación y permite ahorrar una cantidad significativa de ancho de banda en cada carga de página.

La capa de alojamiento y de perímetro es más importante de lo que la mayoría de los equipos creen. Un consejo que no resulta obvio:

Cloudflare siempre delante del origen

Tanto si tu origen es Vercel, Netlify, AWS o un alojamiento gestionado de WordPress, colocar Cloudflare como capa frontal mejora la latencia global, absorbe el tráfico de bots y añade el almacenamiento en caché que, de otro modo, proporcionaría el origen. El plan gratuito es suficiente para la mayoría de los sitios web; los planes de pago añaden funciones de observabilidad y seguridad.

La generación estática de páginas es el principal factor que influye en el rendimiento

El HTML prerenderizado que se sirve desde los nodos periféricos de la CDN alcanza un TTFB inferior a 100 ms en todo el mundo. Sin salto al servidor de origen, sin consulta a la base de datos, sin renderización de plantillas. Si tu contenido no tiene que ser necesariamente dinámico, renderízalo de forma estática.

Funciones de borde para la superficie dinámica

Cuando se necesita un comportamiento dinámico (autenticación, personalización, pruebas A/B), las funciones de borde de Cloudflare Workers o Vercel Edge Functions se ejecutan más cerca del usuario que los servidores de origen. La latencia se reduce drásticamente sin la carga operativa que supone gestionar la infraestructura.

Consulta la facturación de ISR en Vercel a gran escala

La regeneración estática incremental (ISR) es una tecnología excelente con una curva de costes real. En marzo de 2026, alcanzamos un mes de facturación de ISR con varios millones de eventos en Deluxe Astrology. La solución consistió en establecer una norma explícita de «dos fusiones de producción a la semana», ya que cada fusión genera aproximadamente seis millones de eventos de escritura de ISR a una escala de 91 000 páginas. Ten esto en cuenta si utilizas ISR en un sitio web de gran tamaño.

Antes de dar por listo para su lanzamiento cualquier sitio web o plantilla nueva, reviso esta lista de comprobación. Es breve a propósito. Las listas de comprobación largas nunca se utilizan.

1. La imagen principal se precarga con el atributo «rel=preload» como imagen. 2. Las imágenes situadas en la parte visible de la página tienen un ancho y una altura explícitos. 3. Formato WebP, calidad 82, redimensionadas a las dimensiones de visualización. 4. CSS crítico integrado, el resto diferido. 5. Fuentes web alojadas en el propio servidor con «font-display: swap». 6. JavaScript inicial por debajo de 100 KB. 7. Los scripts de análisis y marketing se aplazan. 8. Las columnas de CSS Grid utilizan `minmax(0, 1fr)` en lugar de `1fr` para evitar desbordamientos en contenidos largos. 9. Representación estática siempre que el contenido lo permita. 10. Cloudflare delante del origen. 11. Datos de campo medidos semanalmente a través de Search Console. 12. El linter de SEO en tiempo de compilación falla la compilación en las pruebas de regresión.

Los sitios web que cumplen los doce criterios desde el principio rara vez tienen problemas con el CWV. Los que se saltan tres o cuatro de ellos acaban fallando en el percentil 75 y el equipo se ve obligado a apresurarse para solucionarlo después de que Google ya lo haya detectado.

No todos los sitios web tienen que alcanzar los 100 puntos en Lighthouse. La forma más sincera de plantear la pregunta «¿cuánto trabajo en el rendimiento es suficiente?» es la siguiente:

Sitios web con menos de 10 000 visitantes mensuales que no dependan comercialmente de los rankings de búsqueda: alcancen los umbrales de CWV en el percentil 75 y deténganse ahí. Seguir optimizando produce rendimientos decrecientes. Dediquen ese tiempo al contenido o al producto.

Sitios web con tráfico de pago en los que la tasa de conversión es importante: cada 100 ms de LCP supone una pérdida de entre el 1 % y el 4 % de las conversiones, según los valores de referencia medios. La optimización más allá de los umbrales de CWV suele resultar rentable a gran escala. Haz los cálculos y establece tus prioridades en consecuencia.

Sitios web en los que la puntuación de Lighthouse forma parte del briefing de la marca: hay que alcanzar los 100 puntos en Lighthouse y considerar cualquier retroceso como un error. El trabajo de optimización se intensifica porque el equipo no permitirá que se publiquen versiones con retrocesos.

Sitios web con equipos editoriales que no mantendrán la disciplina de optimización: elige el marco que ofrezca rendimiento por defecto (Astro, Next.js con renderizado estático, WordPress «Headless» con alojamiento gestionado) y acepta esa limitación. Un ajuste manual del rendimiento que el equipo no pueda mantener tiene menos valor que una configuración por defecto ligeramente menos óptima, pero que se mantenga en el tiempo.

El rendimiento en 2026 es una cuestión estructural: elección del marco de trabajo, elección del servidor, disciplina en el flujo de trabajo de imágenes, presupuesto de JavaScript, disciplina en CSS y fuentes, almacenamiento en caché en el borde y la lista de comprobación del CWV aplicada en cada lanzamiento. Los sitios web que incorporan estos elementos desde el principio consiguen un nivel mínimo de rendimiento que se va consolidando. Los que los añaden más tarde invierten más para obtener menos.

No necesitas todas las indicaciones de esta guía desde el primer día. Lo que sí debes saber es qué palanca aún no has accionado, y accionar la siguiente antes de que los datos de campo te indiquen que ya es demasiado tarde.

Si quieres una auditoría de Core Web Vitals en tu sitio específico, corro desde $1.5k. La auditoría produce análisis de datos de campo, remediación priorizada, y un perfil de métrica objetivo que puedes rastrear en el tiempo.

Conclusión clave: Considera «el resultado final» ante todo como una decisión operativa. Las herramientas solo funcionan cuando la responsabilidad es sincera.