CORE WEB VITALS EN 2026

El trabajo de rendimiento en 2026 cae en dos campos. El campo reactivo ajusta páginas individuales una vez que caen por debajo de un umbral. El campo estructural construye rendimiento en la elección del framework, el sistema de diseño, el pipeline de deployment, y la disciplina de contenido para que el rendimiento sea el resultado por defecto del trabajo, no una pasada de optimización que sucede después. Cada sitio que he visto tener éxito a largo plazo está en el campo estructural.

Esta guía es la vista estructural. Números concretos de sitios que he lanzado, las verificaciones reales que ejecuto, los errores más costosos que he cometido, y las partes del consejo convencional que resultaron ser incorrectas en la práctica. Los datos de campo de CrUX siempre ganan contra datos de laboratorio de PageSpeed Insights, así que la mayoría de números abajo vienen de usuarios reales en el percentil 75.

LCP (Largest Contentful Paint)

El tiempo hasta que el elemento más grande visible sin desplazarse se renderiza. Objetivo: menos de 2.5 segundos en el percentil 75. La métrica Core Web Vital más citada, a menudo la más fácil de corregir una vez que identificas correctamente el elemento LCP. La mayoría de los sitios tienen una imagen o un bloque de texto hero como elemento LCP; la solución casi siempre es precargar la imagen, dimensionarla correctamente y asegurar que ningún JavaScript bloquee el renderizado.

CLS (Cambio de Diseño Acumulativo)

Cuánto se desplaza inesperadamente el contenido de la página durante la carga. Objetivo: menos de 0.1. La métrica que se rompe más a menudo por imágenes lazy-loaded sin ancho y alto explícitos, por anuncios inyectados después del primer renderizado, o por web fonts que cambian con métricas diferentes a las del fallback. Solucionable en la mayoría de los casos siendo disciplinado con dimensiones explícitas en cada elemento visual sobre el pliegue.

INP (Interacción al Siguiente Renderizado)

El tiempo de interacción más lento experimentado durante la vida de la página. Objetivo: menos de 200ms. Reemplazó a FID en marzo de 2024. La métrica CWV más difícil de manipular, porque expone fricción real del usuario con JavaScript en tareas de larga duración. Los sitios con JavaScript cliente pesado casi siempre luchan aquí. La solución es enviar menos JavaScript, dividir tareas largas en fragmentos más pequeños y usar requestIdleCallback para trabajo no urgente.

TTFB (Tiempo al Primer Byte)

Tiempo de respuesta del servidor antes de que cualquier renderizado pueda comenzar. Objetivo: menos de 600ms. No es oficialmente una Core Web Vital pero limita todas las otras métricas. Los sitios renderizados estáticamente en un CDN típicamente alcanzan 50 a 150ms. WordPress en hosting compartido alcanza 800ms a 2.5s en caché frío. La decisión de hosting es el mayor factor de TTFB.

Los datos de laboratorio te dicen qué midió una máquina en una ubicación en un momento bajo condiciones controladas. Los datos de campo te dicen qué experimentaron los usuarios reales a escala. Los dos divergen significativamente en la mayoría de los sitios, y los datos de campo son lo que Google usa para señales de ranking. Optimiza por datos de campo primero, datos de laboratorio segundo.

Dónde leer datos de campo

Search Console > reporte de Core Web Vitals. Dataset CrUX en BigQuery si quieres datos a nivel de evento raw. PageSpeed Insights > sección Field Data (cuando existen datos suficientes de usuarios reales para la URL). Calibre, SpeedCurve y Treo proporcionan dashboards enriquecidos sobre CrUX para usuarios de pago. Herramientas RUM (real user monitoring) como Vercel Analytics o Cloudflare Web Analytics añaden más granularidad.

Dónde leer datos de lab

PageSpeed Insights > sección Lab Data. Lighthouse en Chrome DevTools. WebPageTest para análisis granular de waterfall. Útil para diagnosticar el por qué detrás de una regresión de métrica field, no para medirla.

El flujo de diagnóstico que ejecuto

Regresión de métrica field en Search Console. Identifica el patrón de URL afectado. Ejecuta tests de lab vía WebPageTest en tres ubicaciones para reproducir. Inspecciona el waterfall para encontrar la solicitud ofensiva. Corrige. Espera 28 días para que los datos field de CrUX se actualicen. Confirma la corrección.

Números reales de LCP que he visto en el percentil 75 de datos field en las plataformas que más shipeo:

Astro renderizado estáticamente en Netlify o Cloudflare Pages

LCP típico de 0.6 a 1.0 segundos. Lighthouse 100 en las cuatro métricas es el resultado por defecto. JavaScript inicial bajo 30KB. El tier más difícil de superar para sitios de contenido.

Next.js renderizado estáticamente (App Router con RSC, modo SSG)

LCP de 1.0 a 1.5 segundos. JavaScript inicial de 80 a 150KB dependiendo de cuántos componentes del cliente se incluyan. Lighthouse 90+ es lograble pero requiere optimización deliberada.

ISR o SSR con Next.js

LCP de 1.5 a 2.5 segundos dependiendo de la tasa de aciertos de caché y el tiempo de respuesta del origen. Los fallos de caché frío son de 3 a 5 segundos. Tecnología excelente con una curva de costo real y una varianza de rendimiento real.

WordPress en Kinsta o WP Engine más Cloudflare

LCP típico de 1.8 a 2.8 segundos. Es lograble cumplir los umbrales de CWV con disciplina. Los sitios que ejecuto en este stack pasan CWV en el percentil 75 de forma consistente después del paso de optimización.

WordPress en alojamiento compartido

LCP de 3.5 segundos o peor. Evitar en cualquier sitio donde el rendimiento sea parte del proyecto.

Las imágenes son el elemento LCP en aproximadamente el 70% de las páginas de marketing. La disciplina en imágenes es la palanca de rendimiento de mayor impacto que conozco.

Formato y compresión

WebP a calidad 82 es el equilibrio ideal entre calidad visual y tamaño de archivo. AVIF es más pequeño pero la codificación es más lenta y el soporte de navegadores tiene brechas sutiles. Evita JPEG y PNG para cualquier imagen que no sea original de referencia. WebP a q=82 típicamente produce archivos 70 a 90% más pequeños que el PNG original sin pérdida perceptible.

Redimensiona a las dimensiones reales de renderizado

Un JPEG 4K renderizado a 1200 píxeles de ancho es un desperdicio de ancho de banda del 90%. Siempre redimensiona a la dimensión más grande en la que se renderizará la imagen, más una versión 2x o 3x para pantallas de alta densidad. Sharp lo hace en aproximadamente cinco líneas de código en cualquier pipeline de compilación Node.js.

Pipeline de héroe FAL

Generamos imágenes de héroe a través de FAL flux-pro/v1.1-ultra e Imagen 4 directamente desde el pipeline de auto-blog. Las imágenes generadas son JPEGs de 600KB a 1.5MB a 1200x675. Subir sin procesar a Supabase Storage significa que cada página carga ~1MB de héroe solamente. Procesamos a través de sharp(buf).resize({width:1600, fit:"inside"}).webp({quality:82}).toBuffer() antes de la carga a almacenamiento. Reduce el tamaño de archivo 90% sin pérdida perceptible. Vimos un ahorro de 50MB en todo el sitio entre 53 imágenes de héroe en un solo sitio de Seahawk después de aplicar este pipeline. Usa cacheControl: 31536000 en la carga a almacenamiento también.

Ancho y alto explícitos en cada img

Los navegadores reservan espacio antes de que la imagen se cargue solo si ancho y alto están presentes en el HTML. Sin ellos, hay cambios de diseño mientras las imágenes se cargan y el CLS aumenta. Los componentes Image de Astro y Next.js lo manejan automáticamente; las etiquetas img sin procesar lo requieren manualmente.

Precarga de imagen LCP

La imagen de héroe arriba del pliegue debe precargarse con link rel="preload" as="image" en el head. Ahorra típicamente 100 a 400ms. El cambio de una sola línea con mayor impacto disponible en la mayoría de sitios de marketing.

JavaScript es la mayor responsabilidad de rendimiento en la mayoría de los sitios modernos. El presupuesto con el que trabajo en 2026:

JavaScript inicial menor a 100KB en sitios de contenido

Por debajo de 100KB el framework, el sitio, y cualquier píxel de análisis o marketing se combinan y aún se analizan y ejecutan lo suficientemente rápido en un dispositivo móvil de gama media. Por encima de 100KB el costo se ve en INP y TTI, frecuentemente invisible para el desarrollador de escritorio que prueba en una laptop rápida.

Difiere todo lo que no esté encima del pliegue

Analytics, píxeles sociales, widgets de chat, scripts de pruebas A/B. Ninguno de estos necesita bloquear el primer renderizado. Usa el atributo defer o carga en la interacción del usuario. La mejora en CWV es frecuentemente dramática, la pérdida de engagement usualmente es cero.

Evita componentes cliente pesados encima del pliegue

Un carrusel hero que requiera React + framer-motion + 30KB de código de soporte para renderizar el primer fotograma es una responsabilidad de rendimiento. Renderiza la primera diapositiva como HTML estático e hidrata el carrusel solo cuando el usuario está a punto de interactuar.

Audita scripts de terceros trimestralmente

Los scripts de marketing se componen silenciosamente. Un sitio con una etiqueta de analytics en 2020 tiene ocho scripts en 2026 si nadie audita. Ejecuta una revisión trimestral vía Lighthouse o webpagetest, identifica qué sigue ganándose su lugar, y elimina cualquier cosa que no lo esté.

CSS crítico en línea, el resto diferido

El CSS necesario para renderizar above-the-fold debe estar en línea en el head. El resto puede cargar de forma asincrónica. Astro y Next.js manejan esto automáticamente con su CSS scoping; los sitios manuales necesitan un paso de extracción de critical-css en el pipeline de compilación.

Aloja las fuentes localmente y usa font-display: swap

Las fuentes web cargadas desde Google Fonts agregan típicamente 100 a 300ms. Alojarlas localmente desde el mismo origen que el sitio elimina la búsqueda DNS. font-display: swap renderiza el texto de respaldo inmediatamente mientras carga la fuente web, eliminando FOIT (flash of invisible text). Las fuentes variables, donde están soportadas, entregan múltiples pesos desde un solo archivo.

Limita las fuentes a los idiomas que realmente sirves

Un subset de fuente latina pesa 30 a 60KB. El archivo completo multiidioma suele ser 250KB+. El subsetting es un cambio de una línea en la mayoría de los pipelines de compilación y ahorra ancho de banda significativo en cada carga de página.

El hosting y la capa edge importan más de lo que la mayoría de los equipos reconocen. El consejo no obvio:

Cloudflare frente al origen siempre

Ya sea que tu origen sea Vercel, Netlify, AWS u un host WordPress gestionado, poner Cloudflare frente mejora la latencia global, absorbe el tráfico de bots y agrega caché que el origen de otro modo serviría. El tier gratuito es suficiente para la mayoría de los sitios; los tiers pagados agregan observabilidad y características de seguridad.

La renderización estática es el mayor factor de rendimiento

HTML pre-renderizado servido desde nodos edge de CDN alcanza TTFB por debajo de 100ms globalmente. Sin salto al origen, sin consulta a base de datos, sin render de plantilla. Si tu contenido no necesita ser estrictamente dinámico, renderízalo estáticamente.

Edge functions para la superficie dinámica

Cuando necesitas comportamiento dinámico (autenticación, personalización, A/B testing), las edge functions en Cloudflare Workers o Vercel Edge Functions se ejecutan más cerca del usuario que los servidores de origen. La latencia cae dramáticamente sin la carga operacional de ejecutar infraestructura.

Cuidado con la facturación de ISR en Vercel a escala

Incremental Static Regeneration es una tecnología excelente con una curva de costos real. Tuvimos un mes de facturación ISR de múltiples millones de eventos en Deluxe Astrology en marzo de 2026. La solución fue una regla explícita de "dos merges a producción por semana", ya que cada merge dispara aproximadamente seis millones de eventos de escritura ISR a escala de 91,000 páginas. Planifica esto si ejecutas ISR en un sitio grande.

Antes de declarar cualquier nuevo sitio o lanzamiento de plantilla como listo, ejecuto este checklist. Es corto a propósito. Los checklists largos nunca se usan.

1. La imagen hero está precargada con link rel preload como image. 2. Las imágenes above-the-fold tienen width y height explícitos. 3. Formato WebP, calidad 82, redimensionadas a dimensiones de render. 4. CSS crítico inline, el resto deferred. 5. Web fonts auto-alojadas con font-display: swap. 6. JavaScript inicial bajo 100KB. 7. Scripts de analytics y marketing deferred. 8. Columnas de CSS Grid usan minmax(0, 1fr) no 1fr para prevenir overflow en contenido largo. 9. Renderización estática donde el contenido lo permite. 10. Cloudflare al frente del origen. 11. Datos de campo medidos semanalmente vía Search Console. 12. Linter SEO en build-time falla el build en regresiones.

Los sitios que lanzan con los doce puntos en su lugar raramente tienen problemas de CWV. Los sitios que saltan tres o cuatro eventualmente fallan en el percentil 75 y el equipo se apresura a arreglarlo después de que Google ya lo haya notado.

No todos los sitios necesitan alcanzar Lighthouse 100. El planteamiento honesto para la pregunta "cuánta optimización de rendimiento es suficiente":

Sitios con menos de 10,000 visitantes mensuales sin dependencia comercial de rankings de búsqueda: alcanza los umbrales de CWV en el percentil 75 y detente. La optimización adicional produce retornos decrecientes. Dedica ese tiempo al contenido o al producto en su lugar.

Sitios con tráfico pagado donde la tasa de conversión importa: cada 100ms de LCP cuesta aproximadamente 1 a 4% de conversiones según benchmarks promedio. La optimización más allá de los umbrales de CWV típicamente se amortiza a escala. Haz las cuentas, prioriza en consecuencia.

Sitios donde el puntaje de Lighthouse es parte del brief de marca: alcanza Lighthouse 100 y trata cualquier regresión como un bug. El trabajo de optimización se compone porque el equipo no permitirá que regresiones lleguen a producción.

Sitios con equipos editoriales que no mantendrán disciplina de optimización: elige el framework que entrega rendimiento por defecto (Astro, Next.js renderizado estáticamente, WordPress headless con hosting administrado) y acepta la restricción. La optimización manual de rendimiento que el equipo no puede mantener vale menos que un default ligeramente menos óptimo que perdure.

El rendimiento en 2026 es una postura estructural: elección de framework, elección de hosting, disciplina en pipeline de imágenes, presupuesto de JavaScript, disciplina en CSS y fuentes, caching en edge, y la checklist de CWV aplicada en cada lanzamiento. Los sitios que construyen esto temprano obtienen un piso de rendimiento que se compone. Los sitios que lo añaden después gastan más por menos.

No necesitas cada línea de esta guía en el día uno. Necesitas saber cuál palanca aún no has accionado, y accionar la siguiente antes de que los datos de campo te digan que ya era demasiado tarde.

Si quieres una auditoría de Core Web Vitals para tu sitio específico, las realizamos en Seahawk Media a partir de 2,500 USD. 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.