Rendimiento web: Core Web Vitals y optimización

El rendimiento web ha pasado de ser una preocupación puramente técnica a convertirse en un factor de negocio de primer orden. Estudios del sector demuestran consistentemente que cada segundo adicional de tiempo de carga impacta negativamente en las tasas de conversión, el tiempo de permanencia y la satisfacción del usuario. Y desde que Google incorporó los Core Web Vitals como factor de posicionamiento en 2021, el rendimiento tiene también un impacto directo en el tráfico orgánico.

Los Core Web Vitals son un conjunto de métricas definidas por Google que miden aspectos específicos de la experiencia de usuario: la velocidad de carga del contenido principal, la estabilidad visual durante la carga y la capacidad de respuesta a las interacciones del usuario. Estas métricas son medibles, objectivas y directamente correlacionadas con la experiencia real que tienen los usuarios en el sitio web.

Este artículo cubre en profundidad qué son los Core Web Vitals actuales, cómo medirlos con las herramientas adecuadas, cuáles son las causas más comunes de puntuaciones pobres y, lo más importante, cómo optimizarlos con técnicas concretas y aplicables a proyectos web reales. Tanto si trabajas con sitios WordPress como con aplicaciones Next.js o webs estáticas, las técnicas aquí descritas son aplicables.

Los tres Core Web Vitals actuales

LCP: Largest Contentful Paint

El LCP (Largest Contentful Paint) mide el tiempo que tarda en renderizarse el elemento de contenido más grande visible en el viewport: normalmente una imagen de cabecera, una imagen de producto o un bloque de texto principal. Un buen LCP debe ser inferior a 2,5 segundos. Entre 2,5 y 4 segundos necesita mejora. Por encima de 4 segundos se considera un LCP pobre.

El LCP es la métrica más directamente correlacionada con la percepción de velocidad del usuario. Un LCP lento hace que el usuario perciba que la página no carga, aunque otros elementos sí estén disponibles. Los factores que más impactan el LCP son los tiempos de respuesta del servidor, el bloqueo de renderizado por recursos CSS o JavaScript, los tiempos de carga de imágenes y la velocidad de renderizado del cliente.

INP: Interaction to Next Paint

El INP (Interaction to Next Paint) reemplazó al FID (First Input Delay) en marzo de 2024 como Core Web Vital oficial. Mide la latencia de todas las interacciones del usuario con la página durante toda su visita: clics, pulsaciones de teclas, taps en móvil. Específicamente, mide el tiempo desde que el usuario interactúa hasta que el navegador actualiza visualmente la pantalla. Un INP por debajo de 200 milisegundos es bueno; entre 200 y 500 ms necesita mejora; por encima de 500 ms es pobre.

El INP es especialmente relevante para aplicaciones web ricas en interactividad: formularios complejos, tablas de datos con filtros, editores online y aplicaciones SPA con mucha lógica de estado. Las causas más comunes de INP alto son JavaScript pesado que bloquea el hilo principal, renderizados costosos provocados por interacciones del usuario y operaciones síncronas largas que impiden al navegador pintar la pantalla.

CLS: Cumulative Layout Shift

El CLS (Cumulative Layout Shift) mide la estabilidad visual de la página: cuánto se mueven los elementos ya cargados cuando llegan nuevos contenidos. Un ejemplo clásico es un botón que se desplaza mientras el usuario está a punto de hacer clic porque acaba de cargarse un anuncio encima de él. Un CLS por debajo de 0,1 es bueno; entre 0,1 y 0,25 necesita mejora; por encima de 0,25 es pobre.

El CLS es la métrica que más directamente afecta a la frustración del usuario. Hacer clic en el enlace equivocado porque la página se ha reorganizado justo en ese momento es una experiencia universalmente molesta. Las causas principales son imágenes sin dimensiones definidas, anuncios o embeds que se insertan dinámicamente, fuentes web que provocan FOUT (Flash of Unstyled Text) y contenido inyectado por JavaScript que desplaza el contenido existente.

Herramientas de medición: campo vs laboratorio

Existe una distinción importante entre las métricas de laboratorio y las métricas de campo. Las métricas de laboratorio se miden en condiciones controladas con herramientas como Lighthouse (integrado en Chrome DevTools) o PageSpeed Insights en modo laboratorio. Son reproducibles y útiles para el desarrollo, pero no reflejan necesariamente la experiencia real de los usuarios.

Las métricas de campo se recopilan de usuarios reales usando el Chrome User Experience Report (CrUX). Son las que Google usa para el posicionamiento. PageSpeed Insights muestra ambas cuando hay suficientes datos de campo para la URL analizada. La diferencia entre ambas puede ser significativa: un sitio puede tener un LCP excelente en laboratorio (donde se usa una conexión rápida) pero pobre en campo (donde muchos usuarios acceden desde conexiones móviles lentas).

Herramientas principales para medir Core Web Vitals

• PageSpeed Insights: análisis combinado de laboratorio y campo para cualquier URL pública
• Chrome DevTools > Lighthouse: análisis completo de rendimiento, accesibilidad y SEO
• Chrome DevTools > Performance panel: análisis detallado del timeline de renderizado
• web.dev/measure: interfaz simplificada de Lighthouse para análisis rápido
• Search Console > Core Web Vitals: vista agregada de datos de campo para todo el sitio
• WebPageTest: análisis avanzado con múltiples ubicaciones, dispositivos y condiciones de red
• web-vitals (biblioteca npm): medición de CWV en producción en tiempo real desde el código

Optimización del LCP: estrategias concretas

Priorización del recurso LCP con preload

La técnica más impactante para mejorar el LCP cuando el elemento principal es una imagen es añadir una etiqueta link de preload en el head del HTML: esto le indica al navegador que descargue esa imagen con la máxima prioridad, antes de que el parser del HTML la encuentre en el cuerpo del documento. En Next.js, la propiedad priority del componente next/image hace exactamente esto: añade el preload y marca la imagen con fetchpriority='high'.

Optimización de imágenes

Las imágenes son el factor de LCP más frecuente y también el más fácil de optimizar. Los formatos modernos WebP y AVIF ofrecen una compresión significativamente mejor que JPEG y PNG con calidad visual equivalente o superior. AVIF puede reducir el tamaño de una imagen a la mitad respecto a JPEG equivalente. Next.js gestiona automáticamente la conversión y servicio de imágenes en formatos modernos con next/image; para otras tecnologías, herramientas como Sharp (Node.js) o servicios como Cloudinary, Imgix o Bunny.net ofrecen transformación y optimización de imágenes en tiempo real.

Mejora del Time to First Byte (TTFB)

El TTFB (Time to First Byte) es el tiempo que tarda el servidor en responder al primer byte. Un TTFB alto impacta directamente en el LCP porque todo ocurre más tarde. Las estrategias para mejorarlo incluyen: acercar el servidor a los usuarios con una CDN global, implementar caché de páginas en el servidor, optimizar las consultas a la base de datos que bloquean la respuesta inicial y usar edge computing (como Vercel Edge Functions o Cloudflare Workers) para generar respuestas más cerca del usuario.

Optimización del INP: reducir el trabajo en el hilo principal

El INP alto es consecuencia de tener demasiado trabajo en el hilo principal de JavaScript. El navegador tiene un solo hilo principal para ejecutar JavaScript, gestionar el DOM y pintar la pantalla. Si ese hilo está ocupado ejecutando JavaScript, no puede responder a las interacciones del usuario ni actualizar la pantalla, lo que resulta en un INP alto.

División de tareas largas con scheduler API

Las tareas largas (Long Tasks) son tareas de JavaScript que bloquean el hilo principal durante más de 50 milisegundos. Chrome DevTools las marca en rojo en el panel Performance. La estrategia para eliminarlas es dividirlas en tareas más pequeñas que cedan el control al navegador entre ejecuciones. La forma moderna de hacer esto es con la Scheduler API (scheduler.yield()), disponible en Chromium, que permite interrumpir la ejecución para que el navegador procese interacciones pendientes antes de continuar.

Hidratación progresiva y Islands Architecture

En aplicaciones React con renderizado del lado del servidor (SSR), la hidratación —el proceso de conectar el HTML estático con los event handlers de React en el cliente— puede ser costosa en páginas complejas. Técnicas como la hidratación progresiva (hidratar solo los componentes visibles o interactivos primero) o la Islands Architecture (hidratar solo los 'islas' interactivas de la página) pueden reducir significativamente el trabajo del hilo principal en la carga inicial.

Optimización del CLS: estabilidad visual

Reservar espacio para imágenes y embeds

La causa más común de CLS elevado es la carga de imágenes sin dimensiones predefinidas. El navegador no puede reservar el espacio para una imagen hasta que sabe sus dimensiones, lo que provoca que el contenido siguiente se desplace hacia abajo cuando la imagen carga. La solución es siempre definir los atributos width y height en las imágenes, o usar el truco del padding-bottom para mantener el aspect ratio en imágenes responsive con CSS. En Next.js, next/image calcula y reserva automáticamente el espacio según las dimensiones proporcionadas.

Fuentes web: eliminar el Flash of Unstyled Text

Las fuentes web pueden causar CLS cuando la fuente de respaldo (la que usa el navegador mientras descarga la fuente custom) tiene métricas diferentes a la fuente definitiva, provocando un salto de layout cuando la fuente carga. La propiedad CSS font-display: optional evita el FOUT usando la fuente custom solo si ya está en caché, garantizando CLS cero en fuentes. Para el caso general, font-display: swap junto con las nuevas propiedades CSS de ajuste de fuente (ascent-override, descent-override, line-gap-override, size-adjust) permiten aproximar las métricas de la fuente de respaldo a la definitiva, minimizando el desplazamiento.

JavaScript: carga diferida y code splitting

El JavaScript es el recurso que más impacta al rendimiento general de una aplicación web moderna. Un bundle JavaScript grande tarda más en descargarse, parsearse, compilarse y ejecutarse. El code splitting —dividir el bundle en múltiples chunks que se cargan bajo demanda— es la técnica fundamental para reducir el JavaScript en la carga inicial.

En React, React.lazy y Suspense permiten cargar componentes de forma diferida. Next.js extiende esto con next/dynamic, que además permite deshabilitar el SSR para componentes que no necesitan ser renderizados en el servidor. La importación dinámica de módulos también puede usarse para diferir la carga de bibliotecas pesadas que no se necesitan hasta una interacción específica del usuario.

Análisis del bundle con herramientas especializadas

Antes de optimizar, hay que medir. Webpack Bundle Analyzer y @next/bundle-analyzer (para proyectos Next.js) generan una visualización del tamaño del bundle donde es fácil identificar dependencias innecesariamente pesadas, módulos duplicados y oportunidades de code splitting. Bundlephobia es otra herramienta muy útil para evaluar el coste en KB de cualquier paquete npm antes de añadirlo al proyecto.

CSS: eliminación del código no usado y rutas críticas

El CSS tiene un impacto específico en el rendimiento de carga: los archivos CSS son render-blocking por defecto, lo que significa que el navegador no renderiza nada hasta haber descargado y procesado todo el CSS. Para CSS de frameworks como Bootstrap o incluso Tailwind sin la configuración de purga correcta, esto puede significar cientos de kilobytes de CSS que bloquean el renderizado.

El CSS crítico (above-the-fold CSS) es el CSS necesario para renderizar el contenido visible sin scroll en la carga inicial. Inlinearlo en el head del HTML permite que el navegador renderice el contenido visible antes de que se haya descargado el resto del CSS. Herramientas como Critical o Penthouse extraen automáticamente el CSS crítico de una página. Next.js con Tailwind gestiona esto eficientemente en producción gracias a la generación solo del CSS utilizado.

Optimización de fuentes: un impacto mayor de lo esperado

Las fuentes web son un recurso que a menudo se pasa por alto en las optimizaciones de rendimiento. Cargar múltiples pesos y estilos de una fuente puede añadir cientos de kilobytes al peso de la página. Las mejores prácticas incluyen: cargar solo los pesos y estilos de fuente que realmente se usan, usar el subconjunto de caracteres apropiado para el idioma del sitio (latin en lugar de latin-ext para sitios en español, por ejemplo), y preferir las fuentes variable (una sola fuente que incluye múltiples pesos) cuando están disponibles.

next/font en Next.js 13+ descarga las fuentes en tiempo de build y las sirve localmente con los encabezados HTTP correctos, eliminando la petición a Google Fonts en tiempo de ejecución y garantizando la privacidad del usuario. Adicionalmente, aplica automáticamente las propiedades CSS de ajuste de fuente para minimizar el CLS. Es uno de los ejemplos más claros de cómo los frameworks modernos pueden gestionar la optimización de rendimiento de forma transparente para el desarrollador.

Caché y CDN: la optimización de mayor impacto a largo plazo

Una CDN (Content Delivery Network) distribuye el contenido estático del sitio web desde servidores próximos a los usuarios en todo el mundo, reduciendo la latencia de descarga. Para activos estáticos (imágenes, fuentes, JavaScript, CSS), la CDN es la optimización con mayor impacto en el rendimiento global, especialmente para sitios con usuarios en múltiples regiones. Cloudflare, AWS CloudFront, Fastly y Vercel Edge Network son las opciones más utilizadas.

La política de caché de los diferentes tipos de recursos debe estar correctamente configurada. Los activos inmutables (JavaScript y CSS con hash en el nombre de archivo) pueden cachearse indefinidamente con Cache-Control: public, max-age=31536000, immutable. El HTML debe tener una caché más corta o usar revalidación condicional con ETags para garantizar que los usuarios reciben el contenido actualizado tras publicaciones.

Rendimiento web no es un proyecto puntual: es una disciplina continua. Cada nueva funcionalidad puede introducir regresiones que solo se detectan si se monitorizan las métricas de forma sistemática.

Monitorización continua del rendimiento

La optimización del rendimiento es un proceso continuo, no un proyecto con fecha de finalización. Cada nuevo feature, cada dependencia añadida y cada cambio de arquitectura puede impactar en los Core Web Vitals. La clave es integrar la monitorización del rendimiento en el proceso de desarrollo para detectar regresiones antes de que lleguen a producción.

Lighthouse CI permite ejecutar Lighthouse automáticamente en cada pull request como parte del pipeline CI/CD, bloqueando merges que degraden significativamente las métricas de rendimiento. Para la monitorización en producción con datos de usuarios reales, la biblioteca web-vitals puede enviar las métricas a cualquier plataforma de analítica (Google Analytics 4, Datadog, o una base de datos propia).

Conclusión: el rendimiento como ventaja competitiva

Los Core Web Vitals son el marco de referencia más sólido disponible para medir y mejorar la experiencia de usuario desde el punto de vista del rendimiento. Su impacto en el posicionamiento orgánico hace que la inversión en optimización de rendimiento tenga un retorno directo y medible en tráfico y negocio. Más allá del SEO, un sitio rápido convierte mejor, retiene más usuarios y refleja la calidad del equipo que lo ha construido.

La prioridad de optimización debe seguir el impacto: empieza por las imágenes y el JavaScript, que suelen ser los mayores contribuidores a un rendimiento pobre. Usa las herramientas de medición para identificar los problemas reales antes de optimizar, y establece un proceso de monitorización continua para detectar regresiones. Con un enfoque sistemático y las técnicas correctas, alcanzar puntuaciones de rendimiento excelentes en Core Web Vitals es un objetivo perfectamente alcanzable para cualquier aplicación web.