Core Web Vitals: optimiza la experiencia de carga para SEO

Los Core Web Vitals son un conjunto de métricas de rendimiento web de Google —como LCP, FCP, CLS, TTFB e INP— que evalúan la velocidad de carga, interactividad y estabilidad visual. Optimizar estas métricas mejora la experiencia de usuario y contribuye a un mejor posicionamiento en Google. En este artículo (más técnico de lo normal 😊) intentamos explicar desde nuestra experiencia qué son, por qué importan y cómo optimizarlas.

¿Qué son los Core Web Vitals?

Los Core Web Vitals (o en español los “indicadores web principales”) son un grupo de métricas desarrolladas por Google para cuantificar la experiencia de usuario en aspectos que se consideran clave dentro del rendimiento web

Se lanzaron alrededor de 2020 con el objetivo de intentar simplificar las evaluaciones de rendimiento de los sitios. En lugar de analizar decenas de métricas posibles, Google identificó las métricas esenciales que todo propietario de sitio web debería medir y optimizar. Al principio solo eran tres métricas enfocadas en diferentes facetas de la experiencia:

• LCP (Largest Contentful Paint) – Rendimiento de carga del sitio (qué tan rápido se muestra el contenido principal).
• FID (First Input Delay) – Interactividad (qué tan rápido responde la página en la primera interacción).
• CLS (Cumulative Layout Shift) – Estabilidad visual (qué tan estable es el diseño durante la carga).

Con el tiempo, Google ha ajustado este conjunto. En 2024 introdujo INP (Interaction to Next Paint) en reemplazo de FID como métrica de interactividad más completa (Introducción de INP a Core Web Vitals).  Además, aunque FCP (First Contentful Paint) y TTFB (Time to First Byte) no forman parte del trío principal de Core Web Vitals, son métricas relacionadas muy importantes para diagnosticar la percepción de velocidad de carga.

En resumen, los Core Web Vitals son métricas centradas en el usuario (“user-centric metrics”). Cada una refleja un aspecto crítico de la experiencia: velocidad (¿cuánto tarda en mostrarse el contenido?), capacidad de respuesta (¿cuánto tarda en reaccionar la página?) y estabilidad visual (¿la página se mantiene estable mientras carga?).

A continuación, entraremos a ver la importancia SEO de estas métricas y luego explicaremos técnicamente cada una de ellas con sus umbrales considerados “buenos” por Google.

Importancia para el SEO y el ranking en Google

La velocidad de carga y la experiencia de usuario medidas a través de los Core Web Vitals se han vuelto factores importantes para el SEO. Google ha confirmado que las señales de experiencia de página, incluyendo los Core Web Vitals, son utilizadas por sus sistemas de ranking en los resultados de búsqueda (Qué es la experiencia en la página en los resultados de la Búsqueda de Google). Esto directamente nos indica que un sitio con métricas web pobres podría ver afectada negativamente su posición en Google, mientras que un sitio rápido y estable tiene más probabilidades de obtener mejor ranking (siempre y cuando el contenido sea relevante, ya que la calidad del contenido sigue primando sobre cualquier factor técnico).

La decisión de Google de incorporar estos indicadores en el algoritmo se debe a que están totalmente ligados a la satisfacción del usuario. Un sitio que carga rápido y no presenta saltos bruscos en su diseño ofrece una mejor experiencia, reduce la tasa de rebote y aumenta el tiempo de permanencia. De hecho, hay datos contundentes al respecto: por ejemplo, Google encontró que reducir solo 0,1 segundos el tiempo de carga móvil incrementó las conversiones en un 8,4% para sitios de retail y 10,1% para sitios de viajes (hay estudios sobre esto thinkwithgoogle.com).

Al contrario, otros estudios muestran que por cada segundo adicional de carga en móvil, las conversiones pueden caer hasta un 20%. Esto indica cómo la optimización web no solo mejora métricas técnicas, sino que también se traduce en beneficios de negocio: más ventas, más leads o más páginas vistas, según el tipo de sitio.

En cuanto al SEO específico, desde la llamada “Page Experience Update” (actualización de experiencia de página) lanzada en 2021, Google empezó a considerar oficialmente las Core Web Vitals en el posicionamiento. Si bien no garantizan automáticamente aparecer primero en las SERPs (páginas de resultados), sí pueden ser un factor de desempate importante entre dos sitios de calidad similar.

A continuación, revisaremos cada métrica en detalle, incluyendo cómo se mide y cuáles son sus criterios de puntuación.

Explicación técnica de cada métrica: LCP, FCP, CLS, TTFB, INP

Para optimizar algo, primero tenemos que entender qué mide y cómo se evalúa. En esta sección desglosamos cada métrica clave (tanto las Core Web Vitals oficiales como FCP y TTFB) con sus definiciones técnicas y umbrales de referencia.

Google categoriza los resultados de estas métricas en tres rangos: “Bueno”, “Necesita mejora” y “Malo”. En general, los umbrales tienen unos valores óptimos son los siguientes:

Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) se traduce como “pintado con mayor contenido”. Esta métrica mide el tiempo que tarda en aparecer en pantalla el elemento de contenido más grande dentro de la ventana de visualización (viewport).

En la práctica, suele corresponder a la imagen de cabecera, un banner, o un bloque grande de texto que esté por encima del scroll inicial. LCP comienza a contabilizarse desde que el usuario inicia la carga de la página hasta el momento en que ese elemento más grande se renderiza por completo.

• ¿Qué indica? LCP refleja la velocidad de carga percibida por el usuario para el contenido principal. Un LCP rápido da la sensación de que la página carga rápido, mientras que un LCP lento implica que el usuario se queda mirando una página vacía o incompleta durante más tiempo. Es una métrica de loading (carga) pura y dura.

• Umbrales: Google considera bueno un LCP de 2,5 segundos o menos, medido en el 75º percentil de las cargas (es decir, el 75% de los usuarios experimentan ese LCP o mejor).

Entre 2,5 s y 4,0 s sería “necesita mejora”, y más de 4,0 s es “malo”

• Detalles técnicos: LCP puede ser disparado por diferentes tipos de elementos: imágenes <img> o <video> (la portada del video), elementos con imágenes de fondo vía CSS, o nodos de texto grandes dentro de contenedores de bloque. La métrica espera hasta que se renderiza el elemento más grande de todos estos. Importante: solo considera contenido en el viewport inicial (lo que cabe en pantalla sin hacer scroll).

• Contexto: antes de LCP, los desarrolladores usaban otras métricas como “First Meaningful Paint” para estimar cuándo se cargaba lo importante de la página, pero eran menos consistentes. LCP intentó estandarizar la medición de “¿cuándo está visible lo principal?”.

First Contentful Paint (FCP)

First Contentful Paint (FCP) significa literalmente “primer pintado con contenido”. Esta métrica registra el tiempo que transcurre hasta que cualquier contenido útil aparece por primera vez en pantalla. “Contentful” implica contenido real del DOM: texto, imágenes (incluidos los fondos de CSS con imágenes), SVGs, etc. (se excluyen fondos lisos o canvas en blanco). Es básicamente el momento en que el navegador renderiza el primer elemento de contenido (aunque no sea el más grande ni el completo).

• ¿Qué indica? FCP es una señal de inicio de carga visual. Le muestra al usuario que algo está pasando. Antes del FCP la página está en blanco; después del FCP, ya hay al menos un fragmento de contenido (por ejemplo, el logo, un fondo, un texto del menú) en pantalla. Esto mejora la percepción de velocidad, porque ver (aunque sea algo) de contenido es mejor que ver una pantalla vacía.

• Umbrales: según las referencias de Lighthouse (la herramienta de Google para análisis de rendimiento), un FCP por debajo de 1,8 segundos se considera rápido (verde).

Entre 1,8 s y 3 s es moderado, y más de 3 s es lento (rojo).

• Diferencia con LCP: FCP y LCP están relacionados, pero miden instantes distintos. FCP ocurre antes, cuando aparece el primer trozo de contenido; LCP ocurre cuando aparece el contenido más grande. Por ejemplo, una página podría mostrar primero un encabezado de texto a los 1,2 s (FCP), pero luego tardar hasta 2,5 s en cargar una imagen grande de banner (LCP). Ambos son relevantes: FCP asegura que algo apareció pronto, LCP asegura que lo más importante apareció pronto.

• Limitaciones: aunque FCP ayuda a evaluar la velocidad percibida, no distingue si ese primer contenido es significativo o no. Puede ocurrir que el primer elemento visible sea trivial (por ejemplo, el fondo de un header) y lo realmente útil aparezca más tarde. Por eso LCP suele tener más peso para la experiencia real. Aun así, FCP es útil para diagnosticar la cascada de carga: si el FCP es alto, significa que nada se mostró por mucho tiempo, indicando problemas en las etapas iniciales de carga (posibles bloqueos por CSS/JS, servidor lento, etc.).

Time to First Byte (TTFB)

Time to First Byte (TTFB) se traduce como “tiempo hasta el primer byte”. Es una métrica clásica de rendimiento web que mide la rapidez de la respuesta inicial del servidor. Es decir, cuantifica el tiempo desde que el navegador hace la petición HTTP al servidor hasta que recibe el primer byte de la respuesta. El TTFB abarca varios pasos “invisibles” para el usuario, pero críticos en la cadena de carga:

1. El navegador resuelve el DNS del dominio, establece la conexión TCP y negocia TLS (si es una conexión HTTPS).
2. Envía la solicitud HTTP al servidor (por ejemplo, un GET de la página).
3. El servidor procesa la solicitud (ejecuta código, consultas a base de datos, etc.) y empieza a generar la respuesta.
4. Llega el primer byte de la respuesta al navegador.

El momento en que ese primer byte llega marca el fin del TTFB.

• ¿Qué indica? TTFB refleja el rendimiento del servidor y la infraestructura. Un TTFB alto suele significar que el servidor es lento procesando la petición (puede ser por muchas causas: por código no optimizado, base de datos lenta, alto tráfico sin los recursos adecuados) o que hay mucha latencia de red (por distancia geográfica o falta de CDN, por ejemplo). Un TTFB bajo significa que el servidor respondió casi inmediatamente.

• Umbrales: en la documentación de PageSpeed Insights, Google sugería que el tiempo de respuesta del servidor debería ser inferior a 200 ms, de hecho, PageSpeed muestra una advertencia de “Reduce el tiempo de respuesta del servidor” si excede 200 ms. Sin embargo, en análisis de campo (como en el reporte de UX de Chrome) se consideran rangos más amplios: en general un TTFB por debajo de 800 ms se suele calificar como “bueno”, entre 800 ms y 1,8 s “necesita mejora”, y por encima de 1,8 s “malo”.

• Importancia para Core Web Vitals: curiosamente, TTFB no es en sí mismo un Core Web Vital oficial. Aun así, influye indirectamente en métricas de carga como FCP/LCP: si el servidor tarda mucho en enviar el HTML inicial, ningún contenido puede aparecer hasta recibirlo. Un TTFB alto retrasa todo el proceso de renderizado. Por eso, Google y los SEOs seguimos resaltando la importancia de mejorar el TTFB (en GO2JUMP es uno de los 55 indicadores que analizamos en la auditoria SEO 😊).

• Causas típicas de TTFB alto: existen muchas casuísticas por las que podamos tener un TTFB alto, por ejemplo, una lógica del servidor lenta (código backend ineficiente), consultas a base de datos pesadas, falta de caché de contenido, uso de hosting de baja calidad o saturado, distancia física excesiva sin uso de CDN (los datos deben viajar más), entre otros. Es una métrica muy relacionada con el rendimiento web desde el lado del servidor.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) significa “cambio acumulativo de diseño”. Esta métrica mide la estabilidad visual de la página durante su carga (y ligeramente después). ¿Alguna vez entraste a un sitio y cuando estás por hacer clic, de repente el contenido se mueve porque se cargó una imagen o anuncio y terminas clicando otra cosa? CLS cuantifica ese fenómeno. Es esencialmente una medida de cuánto se desplaza inesperadamente el contenido en pantalla.

CLS se calcula sumando los “puntajes de cambio de layout” de todos los eventos de movimiento de elementos que ocurran mientras la página carga (y en la sesión inicial). Cada layout shift tiene una puntuación determinada por la fracción de pantalla afectada y la distancia que se movieron los elementos. El CLS total es esa suma, donde un valor 0 significa que nada saltó (estabilidad perfecta) y valores mayores indican más inestabilidad.

• ¿Qué indica? un CLS alto indica una mala experiencia visual: elementos que saltan, botones que se mueven, texto que se desplaza mientras lo lees, etc. Esto suele frustrar a los usuarios. Por el contrario, un CLS bajo significa que la página es estable, todo permanece donde debería mientras carga.

• Umbrales: Google define que un CLS ≤ 0,1 es bueno (verde), entre 0,1 y 0,25 necesita mejora, y > 0,25 es pobre.

• Causas típicas de un CLS alto: lo más común son imágenes o videos sin dimensiones fijas (el navegador no sabe cuánto espacio reservar hasta que cargan, y al cargar empujan el contenido), anuncios o iframes insertados dinámicamente sin espacio reservado, fuentes web que al cargar cambian el tamaño del texto y elementos DOM agregados tardíamente (por ejemplo, un banner de cookies que aparece y empuja todo hacia abajo).

• Buenas prácticas para CLS: la principal es reservar el espacio para imágenes/iframes mediante atributos width/height o usando CSS, de forma que, aunque tarden en cargar no provoquen cambios de layout. Evitar inyectar contenido por encima de lo ya mostrado (si vas a mostrar un popup o banner, que sea como overlay no que empuje el sitio). Utilizar font-display: swap para que la fuente por defecto sea reemplazada sin ocultar texto (evita que aparezca texto de golpe más tarde). Asimismo, animaciones CSS deben realizarse sobre propiedades que no recalculen el layout (usar transform/opacidad en lugar de height/margin, por ejemplo).

• Más allá de la carga inicial: al principio, el CLS medía cambios durante toda la sesión, pero luego Google ajustó la definición para centrarse en la ventana de 5 segundos desde que se carga la página (o hasta la primera interacción del usuario, lo que ocurra primero). Esto para evitar penalizar páginas de una sola página (SPA) con cambios tardíos.

First Input Delay (FID) e Interaction to Next Paint (INP)

La métrica de interactividad original en Core Web Vitals fue First Input Delay (FID), que medía el retraso en la respuesta a la primera interacción del usuario (clic, pulsación de tecla…) después de cargar la página. Es decir, cuánto tiempo pasa desde que el usuario intenta interactuar hasta que el navegador puede responder (por ejemplo, el clic hace efecto). Un buen FID era considerado ≤ 100 ms, indicando respuesta casi instantánea, mientras que por encima de 300 ms era problemático.

Sin embargo, FID presentaba limitaciones: solo tomaba en cuenta la primera interacción y únicamente medía el delay inicial (tiempo hasta que el evento es manejado), pero no evaluaba si la página seguía respondiendo bien en interacciones posteriores. Por eso, a partir de marzo de 2024 Google reemplazó FID por INP (Interaction to Next Paint) como nueva métrica de interactividad, es una métrica más completa que observa todas las interacciones del usuario durante su visita a la página y registra el peor caso (el de mayor tiempo de respuesta).

• ¿Qué indica? INP captura la calidad general de la interacción con la página. Un INP bajo significa que prácticamente todas las interacciones son fluidas y rápidas. Un INP alto revela que al menos una interacción tuvo un tiempo de respuesta significativo.

• Umbrales: Google establece que un INP ≤ 200 ms indica buena respuesta (bueno), hasta 500 ms es necesita mejora, y > 500 ms es malo. Estos números, al igual que las otras métricas, se evalúan típicamente en el 75º percentil de los usuarios. Lograr ≤ 200 ms en la mayoría de los casos equivale a una experiencia casi instantánea, el usuario siente la aplicación “rápida como una app nativa”.

• Relación con FID: en la mayoría de los sitios, mejorar FID ayuda también a INP, porque ambas apuntan a reducir el tiempo en que el hilo principal está bloqueado. La diferencia es que INP exigirá que no solo la primera interacción sea rápida, sino todas (o casi todas). Por ejemplo, en una página web tipo app, puede que la primera interacción sea rápida, pero luego al abrir un menú complejo haya un retraso, FID no lo captaba, INP sí.

• Causas de INP alto: normalmente, ejecución excesiva de JavaScript en el hilo principal. Si hay tareas largas (>50 ms) ejecutándose (por renderizados pesados, loops intensivos, carga de librerías enormes…), el navegador no puede atender eventos hasta que termina esas tareas, generando tiempos de respuesta elevados. También pueden influir procesos pesados de estilo y layout si se recalcula la página entera, o si hay demasiados scripts de terceros (tags, ads, trackers…).

• Mejorar INP: para mejorar el INP, implica aplicar todas las buenas prácticas de optimización de JS (algo muy muy técnico): dividir el código (code-splitting) para cargar solo lo necesario en cada vista, eliminar código o funcionalidades no usadas (tree-shaking), diferir la carga de scripts no críticos (defer/async), optimizar el trabajo en fondo (usar Web Workers para tareas muy pesadas), y en general evitar tareas largas. También revisar el impacto de terceros (si un script de GA4 por ejemplo, bloquea el hilo 200 ms, afecta la interactividad).

Un tip muy útil es observar la métrica Total Blocking Time (TBT) en Lighthouse: suele correlacionar con INP, indicando cuántos milisegundos estuvo bloqueado el hilo principal durante la carga.

Herramientas para medir Core Web Vitals

Una vez explicadas y entendidas las métricas, necesitamos herramientas para medirlas y monitorearlas. Google proporciona varias herramientas gratuitas para evaluar Core Web Vitals tanto en un entorno controlado (a partir de ahora lo llamaremos “laboratorio” 😊) como con datos reales de usuarios. Las principales son PageSpeed Insights, Lighthouse y Search Console, cada una con su enfoque:

PageSpeed Insights

PageSpeed Insights (PSI) es quizás la herramienta más accesible para obtener una radiografía rápida de tus Core Web Vitals. Solo necesitas copiar y pegar la URL en la página y Google analizará esa página, devolviéndote un informe con puntajes y sugerencias.

PSI combina datos de laboratorio (una ejecución Lighthouse simulando un dispositivo y conexión móvil por defecto) y datos de campo del Chrome UX Report (si los hay, basados en usuarios reales en los últimos 28 días).

Lo más útil de PSI es que te señala explícitamente los valores de LCP, FID/INP, CLS y FCP en la sección de resultados. Verás, por ejemplo, “LCP: 2.8 s (Necesita mejora)” o “CLS: 0.04 (Bueno)” acompañado de una señal de aprobado o advertencia según el caso. Además, proporciona una lista de recomendaciones específicas para mejorar, priorizadas por impacto.

Ventajas de PageSpeed Insights:

• Es muy fácil de usar para sacar un análisis (web, sin instalaciones).
• Combina métricas de campo y de laboratorio: puedes saber cómo está tu sitio en la vida real (con datos de usuarios) y al mismo tiempo obtener una auditoría reproducible con Lighthouse.
• Da sugerencias accionables y estima el ahorro potencial en cada optimización sugerida.

En un contexto puramente SEO, PSI es ideal para analizar regularmente páginas importantes (home, páginas contenedoras, …) y detectar problemas de Core Web Vitals. Google también ofrece una API de PageSpeed, útil si quieres automatizar monitoreos.

Lighthouse (en Chrome DevTools)

Lighthouse es la herramienta de auditoría de rendimiento de Google que se ejecuta en un entorno controlado (laboratorio). PageSpeed de hecho utiliza Lighthouse, pero también puedes ejecutar Lighthouse directamente. Hay varias formas: mediante Chrome DevTools, como módulo de Node.js, o a través de la interfaz web de PageSpeed. La más simple es usar Chrome DevTools:

1. Abrir Chrome en escritorio y cargar la página que quieres analizar.
2. Ir a Herramientas de desarrollador (tecla F12) → pestaña “Lighthouse”.
3. Configurar (puedes elegir dispositivo Móvil o Desktop, etc.) y ejecutar “Analizar carga de la página”.

Lighthouse generará un informe con puntajes de performance (donde destacan LCP, FCP, TBT, CLS, INP/FID) y diagnósticos detallados.

A diferencia de Search Console, Lighthouse no usa datos de usuarios reales, sino que simula una conexión y dispositivo (por defecto un móvil mid-tier con 4x CPU throttle, etc.).

Ventajas de Lighthouse:

• Permite ir haciendo debug paso a paso. Por ejemplo, en DevTools, tras correrlo puedes ver qué elemento fue marcado como LCP, en qué momento exacto ocurrió, etc., lo que ayuda a entender qué está afectando la métrica.
• Ofrece métricas de laboratorio adicionales como Speed Index, TBT, TTI (Time to Interactive) que no están en Core Web Vitals pero ayudan a diagnosticar.
• Puedes probar versiones locales de tu sitio (antes de desplegar cambios, correr Lighthouse para ver si mejoraron las métricas).
• Integración en flujos de desarrollo: se puede incluir en CI/CD para probar cada build.

Un enfoque recomendado para analizar es: primero detectas un problema vía Search Console/PSI (datos reales), luego usas Lighthouse para replicarlo en laboratorio, haces ajustes en tu código, y vuelves a probar hasta ver mejora en las métricas laboratorio; finalmente confirmas con los datos de campo más adelante.

Google Search Console (Informe de Core Web Vitals)

Google Search Console ofrece un informe específico de Core Web Vitals enfocado en el rendimiento de tus páginas en el mundo real. Es decir, se basa en los datos recopilados de usuarios de Chrome que visitan tu sitio. Para acceder, debes tener tu sitio verificado en Search Console. Una vez allí, en la sección “Experiencia” encontrarás el reporte de Métricas web principales.

Características del informe:

• Agrupación por URLs: Search Console agrupa las páginas de tu sitio en buckets de rendimiento (“Bueno”, “Necesita mejora”, “Deficiente”). Por ejemplo, podría indicarte “120 URL tienen LCP deficiente en móvil”. Esto ayuda a priorizar: quizá muchas páginas de una misma plantilla comparten un problema (p.ej., todas las fichas de producto con una imagen pesada).
• Métricas incluidas: actualmente reporta LCP, INP y CLS (tras la sustitución de FID por INP). No reporta FCP ni TTFB directamente, pero si estas influyen en LCP probablemente las páginas aparecerán con problemas de LCP.
• Umbral de aprobación: para que una URL se considere “Buena”, todas las métricas Core Web Vitals deben estar en buen estado. El informe te muestra el estado según la peor métrica de cada URL/grupo.
• Detalle y ejemplos: al hacer clic en un grupo, verás qué URLs representativas están en ese grupo y el valor de la métrica. No te da tanto detalle como Lighthouse, pero te orienta por dónde puedes buscar.

La utilidad del Search Console es tener una vista más global de todo el sitio.

Usando las tres herramientas de forma complementaria se puede lograr un diagnóstico completo:

1. Identificar problemas globales en Search Console.
2. Ejecutar PSI/Lighthouse en páginas concretas para investigar causas y soluciones.
3. Implementar mejoras y luego verificar el impacto con Search Console en las semanas siguientes.

¿Cómo optimizar cada métrica? Recomendaciones técnicas

Ahora pasemos a la acción: ¿Cómo podemos mejorar los Core Web Vitals? Cada métrica tiene sus propios retos y posibles optimizaciones. A continuación, abordamos técnicas y buenas prácticas para mejorar LCP, FCP, TTFB, CLS e INP, con ejemplos técnicos.

Muchas de estas recomendaciones son complementarias (por ejemplo, optimizar imágenes beneficia a LCP, FCP y CLS a la vez), por lo que vale la pena abordarlas de forma integral.

Optimizar LCP (mejorar velocidad de carga del contenido principal)

Un LCP lento suele deberse a que el elemento principal de la página tarda en descargarse o renderizarse. Algunas técnicas para optimizar LCP son:

• Optimiza las imágenes de hero o banners: si el LCP de tu página es una imagen grande (caso común en portadas, páginas de producto, etc.), reduce su peso al máximo. Esto implica usar dimensiones adecuadas (no cargar una imagen de 2000px si se muestra a 800px), comprimirla (idealmente con compresión con pérdida leve) y utilizar formatos modernos como WebP o AVIF en lugar de JPEG/PNG.

• Pre-carga del recurso principal: si esa imagen hero (u otro recurso como una fuente o un CSS importante) es determinante para el LCP, indícale al navegador que tiene prioridad. Usando <link rel=»preload» as=»image» href=»…»> en el <head> puedes precargar la imagen LCP. Esto hace que la descarga de ese recurso empiece antes de lo normal. Ten cuidado de no abusar del preload (solo en recursos críticos), pero para el elemento LCP suele ser muy efectivo.

• Eliminar recursos que bloquean el renderizado: los render-blocking resources (principalmente CSS y JS en <head> sin defer/async) pueden retrasar el pintado de cualquier contenido del sitio. Asegúrate de minimizar CSS y JS bloqueantes. Del mismo modo, poner tus scripts al final o con defer para que no detengan la construcción del DOM.

• Mejorar el tiempo de respuesta del servidor (TTFB): aunque TTFB es métrica aparte, impacta el LCP porque hasta que no llega el HTML, el navegador no sabe qué renderizar. Implementar la caché de página en tu servidor o CDN para servir HTML más rápido.

• Evitar carga diferida (lazy-load) del elemento LCP: la carga diferida de imágenes (lazy-loading) es buena práctica general, pero si la imagen principal de tu contenido está marcada para lazy-load, puede demorar su aparición hasta que el JavaScript la cargue. Asegúrate de no aplicar lazyload (o de deshabilitarlo) para la imagen más importante.

• Optimizar fuentes web (si el LCP es texto): si tu LCP es un bloque de texto grande (por ejemplo, un titular) pero estás usando una fuente web personalizada, a veces el texto no se muestra hasta que se carga esa fuente – lo que retrasa el LCP. Para evitarlo, usa font-display: swap en las @font-face, de modo que si la fuente tarda, el texto igualmente se renderice con la fuente por defecto inmediatamente y luego cambie.

Optimizar FCP (mejorar el primer pintado de contenido)

Muchas de las optimizaciones indicadas anteriormente en el LCP también benefician a FCP, ya que acelerar la entrega del HTML, el CSS crítico y recursos principales hará que cualquier contenido aparezca antes. Aun así, podemos destacar acciones puntuales enfocadas en lograr un FCP más temprano:

• Minimizar el trabajo en la etapa inicial: cuando el navegador carga la página, debe descargar y procesar HTML, CSS y JS antes de mostrar algo. Reducir el tamaño del HTML inicial (por ejemplo, eliminar comentarios o espacios innecesarios, o enviar solo lo necesario con SSR ligero si es una SPA) ayuda a que el primer fragmento llegue antes. Minificar HTML, CSS y JavaScript es una práctica estándar (y muy recomendado por los SEO 😊) para reducir bytes.

• CSS crítico inline: identifica los estilos CSS necesarios para pintar el contenido y colócalos en línea en el <head> (o usando una herramienta que lo haga). De esta forma, el navegador puede renderizar ese contenido sin esperar el archivo CSS completo. El CSS no crítico puede cargarse con media=»print» o con rel=»preload» + swap a rel=»stylesheet» mediante JS para no bloquear.

• Deferir JavaScript no esencial: todo script externo que no sea necesario para el primer pintado debería llevar defer (o async si es independiente). Esto asegura que la parsing del HTML y CSS no se detenga por ejecutar JS. A veces incluso se recomienda mover ciertas lógicas al final de body. Ten especial cuidado con scripts de terceros (tags de analítica, anuncios): cargarlos asíncronamente o mediante gestor (siempre recomendamos hacerlo con Google Tag Manager) ayuda a que no bloqueen el render inicial.

• Priorizar contenido por encima del pliegue: audita qué se está cargando antes de que aparezca el primer contenido. Por ejemplo, si tienes un slider de imágenes abajo en la página que carga JS pesado, retrásalo hasta después del FCP. Carga diferida de imágenes debajo del fold (lazy-load) es útil aquí: las imágenes que no se ven inmediatamente no deben interferir en mostrar el contenido que sí se ve.

• Servidor rápido y CDN: al igual que con LCP, un buen TTFB mejora FCP. Si el HTML llega rápido, el primer elemento también. Considera usar una CDN para servir contenido estático (CSS/JS/imágenes) desde ubicaciones cercanas al usuario, lo que acelera su descarga. Por ejemplo, si tu sitio tiene visitantes globales, una CDN garantiza que el CSS llegue rápido tanto a usuarios en Europa como en América, mejorando el FCP global.

Optimizar TTFB (mejorar el tiempo de respuesta del servidor)

Para mejorar TTFB debemos abordar el rendimiento backend y de infraestructura. Algunas recomendaciones clave:

• Usa caché de servidor o páginas estáticas: si tu sitio es dinámico (por ejemplo, un WordPress, Magento, etc.), implementa mecanismos de caché de página para no generar el HTML desde cero en cada visita. Existen plugins y soluciones muy conocidas para esto. En WordPress, por ejemplo, plugins como WP Super Cache o WP Rocket almacenan versiones estáticas de las páginas

• Optimiza la base de datos y lógica del servidor: si no puedes cachear (por ejemplo, en páginas con contenido muy personalizado para el usuario), revisa consultas a la base de datos para que sean eficientes (añadir índices, evitar SELECT * innecesarios, etc.), utiliza técnicas de cacheado de objetos/memorias para datos frecuentes, y en general mejora la complejidad de tu código servidor.

• CDN y servidores geográficamente distribuidos: la latencia de red influye en TTFB, especialmente para usuarios lejanos al servidor. Usar un CDN puede servir no solo para las imágenes sino también el HTML (algunas CDNs tienen Edge Computing o cache para HTML estático). Si tus usuarios están en múltiples países, considera tener tu infraestructura en regiones múltiples o usar servicios que acerquen los datos a los usuarios. Por todos es conocido recursos como Cloudflare, Akamai, Fastly… que ofrecen aceleración de contenido que reduce la distancia y el ping.

• Hosting adecuado y recursos suficientes: a veces, el problema de TTFB es simplemente que el servidor no da abasto (CPU o RAM saturadas). Monitorea el rendimiento de tu hosting. Si constantemente está al límite, la respuesta será lenta. Aumentar a un plan mejor, optimizar el servidor (por ejemplo, usar PHP-FPM en lugar de mod_PHP, ajustar el pool de hilos, etc.) o incluso migrar a un hosting especializado más rápido puede ser una inversión necesaria.

• Redirecciones innecesarias: evita redirecciones extra al cargar la página (por ejemplo, tener siempre la URL final insertada). Cada 301/302 agrega algo de latencia y empeora TTFB total. Si tu sitio redirige http -> https, o /index, haz que los enlaces insertados ya apunten a la versión final para ahorrar ese paso.

Optimizar CLS (mejorar la estabilidad visual)

Para reducir el CLS debemos evitar o reducir las causas de esos saltos de contenido inesperados. Las prácticas más recomendadas son:

• Reservar espacio para imágenes y iframes: ya lo explicamos antes, siempre que agregues una imagen en el HTML, especifica sus atributos width y height (o en CSS, establece dimensiones fijas o relaciones de aspecto). En HTML actual, declarar width/height permite al navegador calcular un espacio reservado incluso antes de cargar la imagen, manteniendo el layout estable. Si la imagen es responsive (se escala con CSS), igual pon los atributos proporcionados, el navegador ajustará el espacio en base a ellos. Con aspect-ratio en CSS también puedes lograrlo fácilmente (por ejemplo .img-placeholder { aspect-ratio: 16/9; }). Esto previene el clásico empujón de texto cuando la imagen finalmente carga.

• Cuidado con anuncios o embeds de terceros: si integras anuncios, vídeos de YouTube, mapas, etc., intenta conocer sus dimensiones de antemano o insertarlos en un div de tamaño fijo. Así, cuando el script del anuncio inserte el contenido, ya el espacio estaba allí y no mueve nada. En el caso de anuncios de ads que pueden cambiar de tamaño, puedes considerar opciones como no anclar contenido directamente debajo de ellos, para que si empujan no afecten elementos interactivos que el usuario intenta clicar.

• Evitar insertar contenido dinámico arriba: si vas a mostrar un banner, anuncio o alerta después de cargada la página, colócalo de manera que no reorganice el layout existente. Por ejemplo, en vez de insertarlo en el flujo del documento empujando todo hacia abajo, puedes mostrarlo como un overlay flotante, o insertarlo al final del <body> visualmente posicionándolo con CSS. Un caso muy común aquí es el banner de GDPR/cookies: es mejor usar position: fixed; bottom: 0 que insertarlo al inicio del <body> con static positioning.

• Fuentes personalizadas: como mencionamos, si usas fuentes web, configura font-display: swap o fallbacks para que el texto sea legible inmediatamente con una fuente por defecto. El FOIT (Flash of Invisible Text) ocurre cuando el texto no aparece hasta cargar la fuente, lo que puede resultar que produzca un salto cuando por fin se muestra. Si utilizamos swap, el texto aparece con la fuente del sistema y luego cambia (lo cual sí puede provocar un ligero cambio cuando la fuente se actualiza, pero al menos el contenido es visible).

Optimizar INP (mejorar la interactividad y respuesta a las acciones)

Por último, para mejorar la métrica de Interaction to Next Paint (INP) (y en general la respuesta de tu página) el enfoque principal es optimizar y reducir las tareas en el hilo principal de JavaScript. Algunas recomendaciones y ejemplos concretos:

• Dividir el código (Code-splitting): ya lo habíamos visto antes, en lugar de entregar un bloque de código gigantesco de JS para toda la web, separa tu código por páginas o funcionalidades. Por ejemplo, utilizando importaciones dinámicas (import() en Webpack/Vite) o lazy loading de módulos. De esa manera, cuando el usuario visita la página X, solo se ejecuta el código necesario para X, no también el de Y y Z. Esto reduce el trabajo que el navegador tiene que hacer tras cargar, y libera el hilo para responder interacciones. En frameworks como React, aprovecha React.lazy y Suspense para cargar componentes bajo demanda.

• Eliminar código inútil (Tree-shaking): existen herramientas que ya permiten eliminar código no utilizado de las librerías. Asegúrate de tener activado el tree-shaking en tu proceso de build. Por ejemplo, si importaste una librería, pero solo usas una función, que el bundler pueda descartar el resto.

Menos código = menos que ejecutar = mejor respuesta

• Reducir impacto de código de terceros: los scripts de terceros (GA4, tags de marketing, widgets) pueden retrasar la interactividad. Revisa y analiza cuáles se están cargando y ejecutando. Muchos navegadores tienen en la pestaña de Performance una sección de “Attribution” donde puedes ver qué tareas se ejecutan y a que dominio/script pertenecen. Si detectas uno de un tercero muy amplio, evalúa cargarlo después de la interacción inicial o en diferido, o buscar alternativas más ligeras.

Checklist final de buenas prácticas para optimizar Core Web Vitals

Para terminar, resumamos en modo checklist las acciones clave que puedes tomar para mejorar las métricas Core Web Vitals de tu sitio web. Usa esta lista como guía rápida y verificación final:

¿Listo para llevar tu sitio al siguiente nivel de velocidad y fluidez?
Empieza hoy mismo a optimizar tus Core Web Vitals y comprueba cómo una mejor experiencia de carga se traduce en un mejor SEO y, sobre todo, en una mejor impresión en tus visitantes.

• Realiza una auditoría de tu propio sitio con las herramientas que te indicamos, identifica cuellos de botella y pon en práctica las mejoras sugeridas.

• Prioriza las acciones según el impacto (usa la checklist para guiarte) y no olvides hacer un seguimiento de los resultados en herramientas como Search Console o PageSpeed Insights.