La checklist definitiva de Core Web Vitals (2026)

Table of Contents!

• La checklist definitiva de Core Web Vitals
• Checklist de optimización de Core Web Vitals
  • Optimizar imágenes
  • Optimizar fuentes web
  • Optimizar scripts
  • Optimizar estilos
  • Optimizar resource hints
  • Optimizar iconos
  • Optimizar los tiempos de respuesta del servidor
  • Optimizar la interactividad
  • Monitorización de Core Web Vitals
  • Optimizar la ruta crítica de renderizado
  • Optimizar el consentimiento de cookies
  • Optimizar Single Page Applications
  • Evitar un tamaño excesivo del DOM
  • Optimizar peticiones a la API
  • Optimizar widgets de chat
  • Optimizar el rendimiento del service worker
  • Optimizar el contenido de vídeo

Optimizar imágenes

Una imagen grande dentro del viewport visible suele convertirse en el elemento del Largest Contentful Paint. Por eso, optimizar imágenes es una de las medidas más eficaces para el LCP. Consulta la estrategia completa en cómo optimizar la imagen del LCP.

• Redimensiona las imágenes al tamaño máximo con el que se muestran en pantalla. Cualquier byte gastado en píxeles que nadie ve es un desperdicio, y ajustar bien las dimensiones suele reducir el peso un 50 % o más sin pérdida visible de calidad. Combina esto con imágenes responsive para pantallas más pequeñas.
• Aplica lazy loading a las imágenes situadas bajo el primer scroll. El navegador no las descarga hasta que el usuario se acerca a ellas haciendo scroll; así, el ancho de banda inicial se dedica a lo que está en pantalla, lo que mejora el First Contentful Paint (FCP) y la carga general. Nunca apliques lazy loading a la imagen del LCP: harás que el navegador espere al layout antes de iniciar la descarga.
• Asigna fetchpriority="high" a la imagen del LCP y precárgala solo cuando el HTML la oculte. El preload scanner detecta de todos modos cualquier <img> presente en el HTML; este atributo se limita a colocarla al principio de la cola. El preload con <link rel="preload" as="image" fetchpriority="high"> está pensado para una imagen del LCP definida en CSS o cargada mediante JavaScript, invisible para el navegador en el HTML inicial.
• Define width y height en cada imagen. Los navegadores modernos usan ambos atributos para calcular el aspect ratio antes de que la imagen termine de cargar; así reservan el espacio exacto y nada se desplaza al llegar el archivo. Con eso eliminas una causa habitual de layout shifts.
• Usa WebP o AVIF en lugar de JPEG o PNG. Con una calidad equivalente, un archivo WebP suele ser entre un 25 y un 34 % más pequeño que un JPEG, y AVIF puede ahorrar hasta un 50 %. Un elemento <picture> con fallbacks garantiza la compatibilidad con cualquier navegador.
• Usa lazy loading nativo y desactiva cualquier solución de lazy loading basada en JavaScript. El atributo loading="lazy" hace lo mismo sin necesidad de parsear y ejecutar un script antes.
• Añade srcset a las imágenes, junto con el atributo sizes para un control preciso. El navegador elegirá la imagen óptima para cada dispositivo y el móvil dejará de descargar el archivo pensado para una pantalla grande de escritorio.
• Añade decoding="async". El navegador decodificará la imagen en paralelo y seguirá pintando el resto de la página mientras tanto.
• Elimina los metadatos de las imágenes. Los datos EXIF y similares solo suman bytes, y quitarlos no altera la calidad de la imagen. ImageOptim y Squoosh lo hacen de forma manual; Sharp puede encargarse automáticamente en el build.
• No uses una imagen de fondo en CSS para el elemento del LCP. El navegador descubre una imagen de fondo en CSS mucho más tarde que una etiqueta <img> en el HTML. Si no tienes otra opción, precárgala con una etiqueta <link rel="preload"> para que se detecte pronto. Más información sobre el LCP resource load delay.

Optimizar fuentes web

Las fuentes web pueden retrasar el First Contentful Paint, provocar layout shifts y competir con otros recursos por el escaso ancho de banda disponible al inicio de la carga. Dónde alojar los archivos se explica en la guía sobre autoalojar Google Fonts.

• Configura font-display: swap en las reglas @font-face para acelerar el primer renderizado. El navegador muestra una fuente de fallback de inmediato y descarga la fuente web en segundo plano para intercambiarla cuando esté lista. Más detalles en cómo mantener el texto visible mientras cargan las fuentes web.
• Combina font-display: optional con un preload para eliminar los layout shifts causados por las fuentes. Con optional, el navegador espera unos 100 ms a la fuente web; si no llega a tiempo, mantiene el fallback durante esa vista y no hace ningún intercambio. El preload aumenta las probabilidades de que la fuente llegue dentro de esa ventana de tiempo.
• Ajusta las dimensiones de la fuente de fallback a las de la fuente web mediante descriptores de font-face. Define size-adjust, ascent-override, descent-override y line-gap-override en el fallback para que el texto apenas se mueva cuando la fuente web aparezca, manteniendo el CLS al mínimo.
• Haz subsetting de las fuentes para incluir solo los caracteres que tu contenido necesita. Una fuente latina completa de más de 100 KB suele bajar de 20 KB con un subsetting adecuado. Font Squirrel genera subsets online; pyftsubset y glyphhanger lo hacen desde la línea de comandos.
• Limita el número de grosores y estilos tipográficos. Cada variante extra suma entre 15 y 50 KB a la descarga. Quédate como mucho con 2 fuentes críticas (normalmente precargadas) y 2 de carga diferida, tras el primer render.

Optimizar scripts

Los scripts pueden causar problemas en el Interaction to Next Paint, provocar Cumulative Layout Shifts o retrasar el Largest Contentful Paint. Incluso un script ligero e inofensivo al inicio de la página compite por recursos y retrasa las métricas de pintado (LCP y FCP). Tienes todas las opciones disponibles en 14 métodos para diferir JavaScript.

• Elimina el JavaScript que no uses. La pestaña Coverage de Chrome DevTools muestra el código no utilizado; cada fragmento de código muerto que elimines ahorra tiempo de descarga y tiempo del main thread.
• Prioriza los scripts según su función. Si un script introduce cambios importantes en el viewport visible, debe ser render blocking. Los scripts importantes se difieren o cargan con async, y los secundarios esperan a que el navegador esté inactivo. La estrategia detallada está en la guía de priorización de recursos.
• Divide el código y aplica lazy loading a las partes secundarias. Separa los bundles grandes de JavaScript en chunks más pequeños que solo carguen cuando hagan falta; así aligeras la carga inicial. Cualquier bundler moderno (webpack, Rollup, esbuild) divide el código automáticamente con dynamic imports.
• Minifica y recompila siempre los archivos JavaScript con herramientas como SWC, Terser o esbuild. Esto suele reducir el tamaño del archivo entre un 30 y un 50 %.
• Limita los scripts de terceros. Cada uno añade consultas DNS, sobrecarga de conexión y tiempo de main thread. Valora si de verdad lo necesitas o si existe una alternativa más ligera. Revísalos periódicamente en el panel Network de Chrome DevTools.
• Carga los scripts de terceros con async o defer. Nunca sabes qué hará un servicio externo a continuación; no dejes jamás que bloquee el renderizado.
• Controla el coste de los scripts de terceros en tus usuarios reales. La API Long Animation Frames (LoAF) o CoreDash muestran su impacto en el INP y el LCP en field data. Define un performance budget para el JavaScript de terceros y revísalo con frecuencia.

Optimizar estilos

El CSS bloquea el renderizado por defecto. Por eso, cada hoja de estilos en el head retrasa el First Contentful Paint y aumenta el LCP element render delay. Mantén las hojas de estilos pequeñas y separadas, y evita trucos para dividir el CSS en dos partes. Encontrarás consejos para limpiar estilos sobrantes en cómo eliminar CSS no utilizado.

• Minifica el CSS. Usa cssnano o PostCSS, o la compresión integrada de tu preprocesador CSS, para eliminar espacios en blanco y comentarios. No cuesta nada y debes hacerlo, aunque ahorre solo unos pocos kilobytes y ningún usuario lo note.
• Elimina el CSS que tus páginas no usan. Menos CSS implica menos descarga y menos tiempo de parseo. PurgeCSS o la pestaña Coverage de Chrome DevTools te ayudan a detectar el CSS no utilizado. Hazlo en tu propio build y desactiva la función para eliminar CSS no utilizado de plugins como WP Rocket, Perfmatters o LiteSpeed: genera tantos problemas como el critical CSS.
• No insertes CSS inline y descarta el critical CSS. El CSS inline infla el HTML, que es justo el archivo por el que todo lo demás espera. Además, el navegador no suele cachear ese HTML, con lo que cada visita vuelve a descargar el mismo CSS, mientras que una hoja de estilos independiente se sirve desde caché a partir de la segunda página. El critical CSS ahorra un round trip en la primera visita, sí, pero el resto del CSS llega después del primer renderizado: un restyle, un repaint y, con frecuencia, un layout shift.
• Mantén cada hoja de estilos render blocking por debajo de unos 15 KB comprimidos. Es aproximadamente lo que cabe en el primer round trip de una conexión nueva; tómalo como un límite al que aspirar. El waterfall de una conexión 4G lenta muestra los dos extremos problemáticos: una hoja de 60 KB tarda demasiado y una lista de archivos de 0,3 KB paga el coste de arranque de cada request. Combina los archivos diminutos y divide o recorta los grandes.
• No te acostumbres a cargar CSS con async. El truco de media="print" solo sirve para CSS que tengas la certeza absoluta de que no se usa en el primer pantallazo, algo que casi nunca se sabe con seguridad. Separar el CSS del primer pantallazo del resto es critical CSS con otro nombre.
• Elimina cualquier @import del CSS. Cada uno genera una cadena de hojas de estilos que el navegador solo puede descargar de forma secuencial, y el preload scanner no puede ver los archivos al final de la cadena. Enlázalos desde el HTML o combínalos en el build.

Optimizar resource hints

Los resource hints ayudan al navegador a descargar primero los recursos críticos. Un archivo con preload suele encolarse y estar disponible mucho antes que sin esa indicación. Bien utilizados, reducen el LCP resource load delay; para la versión avanzada, lee sobre 103 Early Hints.

• Elimina los hints de recursos que no hagan falta en la primera vista. El ancho de banda inicial es escaso, y cada preload o conexión innecesaria se lo quita a los archivos que sí importan.
• Usa preconnect con los dominios que necesites pronto, como una red de distribución de contenidos (CDN) o un proveedor de fuentes. Así, la resolución DNS, la conexión TCP y el handshake TLS se completan antes de enviar la primera petición a ese dominio. Usa <link rel="preconnect" href="https://example.com"> para orígenes de terceros críticos.
• Valora DNS prefetch cuando un preconnect resulte excesivo. Preconnect establece la conexión completa, mientras que <link rel="dns-prefetch"> solo resuelve el nombre de dominio por anticipado. Es suficiente para un dominio que probablemente usarás más adelante, cuando el coste de abrir una conexión completa aún no compensa.
• Precarga la imagen del LCP cuando no esté en el HTML. El LCP mide el tiempo que tarda en mostrarse el contenido principal, y precargar el elemento del LCP mueve ese recurso al principio de la cola. Para una <img> que ya está en el HTML, fetchpriority="high" hace lo mismo sin necesidad de añadir otra etiqueta.
• Precarga las fuentes críticas con <link rel="preload" as="font" type="font/woff2" crossorigin>. El navegador las descargará antes, el texto se mostrará más rápido y el intercambio de fuentes causará menos layout shifts.
• Envía tus resource hints como 103 Early Hints siempre que puedas. Con una respuesta 103, el servidor envía los hints antes de tener lista la respuesta definitiva, que es lo más pronto que el navegador puede enterarse de la existencia de un recurso. Si el servidor no admite 103, recurre a cabeceras de respuesta Link; si tampoco puedes usarlas, añade elementos <link> en el <head> de la página como fallback.
• Precarga las fuentes antes de que el CSS las descubra. Una fuente referenciada en CSS solo se detecta tras descargar y parsear ese archivo CSS. Un preload en el <head> del HTML elimina esa espera: la fuente se descarga en paralelo y se reducen tanto el FCP como el riesgo de layout shift.

Optimizar iconos

Es fácil excederse con los iconos: cargar un set completo solo para los cinco iconos que usa la página. Los iconos SVG grandes inline inflan el HTML, y una fuente de iconos suele arrastrar miles de glifos innecesarios. Gestionar bien los iconos beneficia al LCP (menos HTML y CSS que cargar) y al CLS (espacio reservado para cada icono).

• No insertes iconos SVG grandes inline en el HTML. Aumentan el tamaño del HTML, ralentizan la página y el navegador no puede cachearlos de forma independiente. Un sprite sheet SVG externo suele ofrecer el mejor equilibrio entre rendimiento y flexibilidad, aunque usar archivos independientes o una fuente de iconos (con cuidado) también mantiene el HTML ligero.
• Nunca cargues un set de iconos grande como Font Awesome al completo. El paquete entero puede superar los 100 KB, mientras que un subset de 20 iconos puede quedarse por debajo de 5 KB. Reduce el set a una fuente de iconos más pequeña o usa SVG individuales.
• Reserva width y height para los iconos, igual que con las imágenes. Así el navegador reserva el espacio y los iconos no provocan layout shifts al cargar. Define los atributos width y height en los elementos SVG o dales dimensiones explícitas con CSS.
• No apliques preload ni insertes inline iconos que no se necesiten en el primer pantallazo; deja que el contenido esencial cargue primero. Aplica lazy loading a los iconos que queden bajo el primer scroll.

Optimizar los tiempos de respuesta del servidor

El tiempo de respuesta del servidor, medido como Time to First Byte (TTFB), precede a cualquier métrica de pintado; un servidor lento retrasa todo lo que viene detrás. Si buscas estrategias detalladas, consulta las guías sobre diagnosticar problemas de TTFB y configurar Cloudflare para el rendimiento.

• Elige un proveedor de hosting rápido y fiable con una infraestructura sólida. Compara proveedores según el TTFB que tú mismo midas en el mundo real. Las cifras de su publicidad son sintéticas.
• Registra cuánto tardan tu código y las consultas a la base de datos, y hazlo con frecuencia. El profiling de consultas y las herramientas de APM (Application Performance Monitoring) te señalan directamente los endpoints lentos.
• Implementa caché en el navegador y en el servidor para evitar recalcular datos recurrentes en cada petición. El full-page caching puede reducir el TTFB de varios segundos a menos de 100 ms. Tienes todos los detalles en la guía de optimización de la duración de la caché.
• Renderiza las pequeñas partes dinámicas en el cliente o en el edge. El contador del carrito, el estado de sesión o un pequeño ajuste de menú no deberían invalidar la caché de toda la página. Conserva el full-page cache y completa esos detalles en el cliente o mediante edge rendering.
• Afina el servidor web: parámetros de keep-alive, número de procesos worker, asignación de memoria y valores de timeout. Un servidor mal configurado malgasta recursos y responde con mayor lentitud.
• Usa una red de distribución de contenidos (CDN). Sirve el contenido estático desde nodos edge (servidores) cercanos al usuario, lo que acorta la distancia física que recorren los datos y acelera la carga para una audiencia global. Además, un CDN suele estar mejor configurado que un servidor propio. Consulta la guía para configurar Cloudflare si buscas un tutorial práctico de configuración.
• Reduce el trabajo por petición. Procesa las tareas pesadas por anticipado, usa algoritmos eficientes y traslada cualquier proceso prescindible a un background job. Después, repasa de nuevo el ciclo de vida de las peticiones en tu aplicación y elimina cada paso que no sea imprescindible.
• Usa HTTP/3. QUIC establece la conexión en un solo round trip, frente a los dos o más que requieren TCP y TLS, y la pérdida de un paquete ya no bloquea el resto de peticiones en esa conexión. Esto se nota sobre todo en redes móviles. La ganancia radica en la conexión, por lo que se refleja en el TTFB y, por extensión, en el LCP. La primera visita suele seguir haciéndose por HTTP/2, ya que el navegador descubre HTTP/3 a través de la cabecera Alt-Svc o de un registro DNS HTTPS. Más información en optimización de la duración de la conexión.
• Añade cabeceras Server-Timing. Indican cuánto tarda cada proceso del servidor en una página para que puedas localizar el cuello de botella y trabajar en la parte que frena el Largest Contentful Paint (LCP). Puedes verlas en el panel Network de Chrome DevTools, y herramientas de RUM como CoreDash pueden recopilarlas.
• Registra las consultas lentas a la base de datos y corrígelas periódicamente. Activa el registro de slow queries (cualquier base de datos conocida lo incluye) y revisa el log cada semana. Mejorar índices, reescribir consultas y añadir una capa de caché para las más frecuentes puede recortar el TTFB de forma drástica.
• Comprime los archivos de texto (HTML, CSS, JavaScript) con GZIP o, mejor aún, Brotli. El servidor los comprime al vuelo antes del envío y terminan pesando cerca de un 70 % menos. Por lo general, Brotli comprime entre un 15 y un 20 % mejor que GZIP.

Optimizar la interactividad

El Interaction to Next Paint (INP) mide la rapidez con la que una página responde a las interacciones del usuario. Un INP deficiente suele deberse a tareas largas de JavaScript que bloquean el main thread. Cada una de las tres fases del INP cuenta con su propia guía: input delay, processing time y presentation delay.

• Aplica el patrón idle-until-urgent en scripts costosos. El trabajo crítico se ejecuta primero y el JavaScript no esencial espera a que el main thread esté libre; así el renderizado y la interacción del usuario nunca quedan bloqueados por un script prolongado. Programa las tareas no urgentes con requestIdleCallback y ejecútalas de inmediato si el resultado hace falta antes. Más información en cómo optimizar el processing time.
• Divide las long tasks haciendo yielding al main thread. Una long task bloquea el main thread y la página deja de responder. Divídela en chunks más pequeños y devuelve el control al navegador entre uno y otro; así podrá procesar clics o pulsaciones de teclas en esos intervalos. Usa scheduler.yield() donde sea compatible o setTimeout(0). Consulta la guía sobre cómo mejorar el INP eliminando el scroll por JavaScript.
• Pinta la respuesta visual antes del trabajo pesado. El INP contabiliza hasta el siguiente pintado, así que cambia primero el estado del botón o muestra un spinner; después haz yield (scheduler.yield() o un setTimeout) y ejecuta la parte pesada a continuación. Un estilo :active o una transición CSS solo se muestran cuando el main thread está libre para pintarlos; un handler que mantenga ocupado el hilo congelará esa respuesta junto con el resto de la página.
• Haz que los listeners de scroll y touch sean pasivos con { passive: true }. Esto indica al navegador que el handler nunca llamará a preventDefault(), permitiéndole iniciar el scroll de inmediato en lugar de esperar a JavaScript. Se nota sobre todo en móvil. El scroll en sí no es una interacción medida por el INP, por lo que esto influye más en la fluidez del desplazamiento que en la cifra de INP.

Monitorización de Core Web Vitals

Monitoriza de forma continua tus Core Web Vitals: es la única forma de detectar regresiones a tiempo y confirmar que un fix funciona como esperabas. Lo que cuenta son los field data en el p75; las pruebas de lab data sirven para entender el porqué. Empieza por el p75 de cada métrica en móvil, los grupos de páginas señalados por Search Console y la tendencia de las últimas semanas: una caída repentina suele apuntar a un deploy, mientras que un deterioro progresivo suele deberse a scripts de terceros que se van acumulando.

• Ejecuta Lighthouse con regularidad. Es la herramienta de auditoría gratuita y open source de Google para detectar problemas de rendimiento en una página. Lighthouse no mide las Core Web Vitals tal como las experimentan los usuarios reales, pero es excelente para probar y comparar tu web siempre bajo condiciones estandarizadas. Una prueba estándar de Lighthouse no mide el INP en absoluto, ya que nadie hace clic durante el test; lo más cercano que ofrece es el Total Blocking Time. Integra Lighthouse en tu pipeline de CI/CD para detectar regresiones antes de pasar a producción.
• Revisa el historial de CrUX periódicamente. CrUX (Chrome User Experience Report) es el conjunto público de datos de rendimiento real de Google, y es la fuente que Google utiliza para decidir si apruebas las Core Web Vitals. Cada cifra de CrUX representa el p75 de los últimos 28 días, por lo que una regresión se va filtrando a lo largo de semanas y un fix tarda cerca de cuatro semanas en reflejarse por completo. PageSpeed Insights muestra únicamente los 28 días actuales; el histórico está disponible en CrUX Vis y en la CrUX History API.
• Implementa medición con RUM. El Real User Monitoring mide cuánto tardan realmente las páginas para tus usuarios, en sus ubicaciones y dispositivos reales. Lighthouse es una prueba de laboratorio y CrUX te da el p75 de los últimos 28 días sin indicar qué elemento o script causó el problema. RUM cubre ese vacío. Recomiendo CoreDash, una herramienta que desarrollé para obtener datos detallados de atribución en Core Web Vitals.
• Establece performance budgets: objetivos concretos por métrica en el p75 en móvil, por ejemplo un LCP inferior a 2,5 segundos, un INP por debajo de 200 ms y un CLS menor de 0,1. Mide frente a ellos con regularidad y verás de inmediato qué áreas requieren atención prioritaria.
• Segmenta los datos. Monitoriza por separado a los perfiles de usuario más valiosos y los diferentes tipos de página; el resto del tráfico puede enmascarar un problema que solo les afecte a ellos. Filtra primero por dispositivo y plantilla de página; la velocidad de conexión y el país vienen después.

Optimizar la ruta crítica de renderizado

La ruta crítica de renderizado abarca cada paso que da el navegador para transformar HTML y CSS (y JavaScript) en píxeles en pantalla. Una ruta más corta se traduce en un First Contentful Paint más rápido y en un menor LCP element render delay. Consulta también cómo evitar un tamaño excesivo del DOM.

• Minimiza el número de recursos críticos. Todo recurso render blocking, sea CSS o JavaScript síncrono, debe descargarse y procesarse antes de que el navegador pueda pintar. Difiere los scripts prescindibles y mantén pocas hojas de estilos y de tamaño reducido.
• Ajusta bien el orden de carga: primero las hojas de estilos, luego la imagen del LCP y las fuentes del primer pantallazo, después el resto de imágenes situadas en la parte visible y, por último, los scripts diferidos. El atributo fetchpriority y los resource hints de priorización indican al navegador qué es prioritario.
• Mantén el árbol del DOM con poca profundidad. El anidamiento excesivo multiplica el cálculo de estilos y el trabajo de layout. Intenta no superar los 32 niveles y quédate por debajo de 1500 elementos en total siempre que puedas; un DOM más plano pinta más rápido y mejora el INP presentation delay.
• Prioriza clases e IDs frente a etiquetas de elementos y atributos en tus selectores. Escribe .important en vez de p.important para que el navegador compruebe menos reglas durante el style matching y recalcule estilos más rápido.
• No anides selectores en profundidad. Cada nivel extra supone más trabajo para el navegador. Reestructura el HTML para reducir el anidamiento o coloca una clase más específica directamente en el elemento, limitándote a un máximo de 3 niveles.
• Reduce el uso de selectores descendientes. Un selector como .container .content obliga al navegador a recorrer los ancestros de cada elemento .content buscando el contenedor. Una clase asignada directamente al elemento de contenido hace match mucho más rápido.
• Agrupa los selectores que compartan estilos en una sola clase o utiliza la metodología BEM (Block Element Modifier). Resulta más fácil de mantener y reduce el tamaño del CSS.

Optimizar el consentimiento de cookies

El RGPD y normativas similares exigen un banner de consentimiento de cookies, pero cargarlo sin cuidado puede retrasar el LCP, causar CLS y disparar el INP. Para profundizar, lee sobre cómo optimizar widgets de terceros para Core Web Vitals.

• Renderiza el banner de consentimiento en el servidor si la página ya se renderiza ahí. Llegará en la primera respuesta HTML, lo que suele ser más rápido que depender de una solución en JavaScript: sin peticiones de red adicionales ni scripts que evaluar.
• En páginas cacheadas, carga el script de consentimiento con async y considera aplicarle fetchpriority="high" para que aparezca antes de que el usuario interactúe.
• Muestra el banner como un overlay en posición fija. Un banner insertado en la parte superior empuja hacia abajo todo el contenido, generando un layout shift en cada primera visita. Fijado en la parte inferior de la pantalla, se superpone al contenido y nada se desplaza.
• Aloja tú mismo los scripts y hojas de estilos del aviso de cookies siempre que puedas, y aplícales caché. Te ahorrarás las resoluciones DNS y las conexiones con la plataforma de gestión de consentimiento (CMP), y mantendrás el control absoluto sobre cómo carga.

Optimizar Single Page Applications

Las Single Page Applications (SPA) creadas con React o Vue presentan desafíos específicos en Core Web Vitals: el renderizado en cliente retrasa tanto el FCP como el LCP, y la hidratación puede bloquear el INP.

• Utiliza siempre server-side rendering o prerendering. Una SPA que solo renderiza en cliente obliga al navegador a descargar y ejecutar todo ese JavaScript antes de mostrar nada. Con SSR (Next.js, Nuxt, SvelteKit) o prerenderizado estático entregas HTML que el navegador puede pintar al instante.
• Prioriza el prerenderizado estático frente al dinámico. Una versión prerenderizada estática se genera en tiempo de build y se sirve directamente desde un CDN sin procesamiento en el servidor, lo que la hace mucho más rápida que una generada en cada petición. Usa generación estática en cualquier página que no requiera datos específicos por petición.
• Carga los scripts de terceros después de la hidratación. La hidratación ya consume demasiado tiempo del main thread para hacer la página interactiva, y ejecutar scripts de terceros al mismo tiempo empeora el input delay. Difiere cualquier script no esencial hasta que la hidratación haya concluido.

Evitar un tamaño excesivo del DOM

Un DOM excesivo (más de 1500 elementos o más de 32 niveles de profundidad) consume más memoria, ralentiza el cálculo de estilos y provoca costosos reflows de layout. Esto se refleja en el INP presentation delay y en las métricas de pintado. Consulta cómo corregir un tamaño excesivo del DOM.

• Elimina los elementos del DOM innecesarios. Busca elementos contenedores que no aporten nada a nivel de diseño o estructura y sustituye estructuras de <div> profundamente anidadas por HTML semántico. Puedes virtualizar listas largas con librerías como react-window o virtual-scroller para mantener el DOM activo reducido.
• Mantén selectores y consultas al DOM eficientes. Los selectores CSS complejos y las consultas amplias en JavaScript (por ejemplo, un querySelectorAll genérico) se vuelven cada vez más lentos a medida que el DOM crece. Emplea selectores de clase específicos y limita cada consulta a un subárbol siempre que puedas.
• Aplica content-visibility: auto al contenido fuera de pantalla. El navegador omitirá el renderizado de esos elementos hasta que el usuario llegue a ellos con el scroll, lo que puede reducir de forma notable el trabajo inicial de renderizado en páginas con secciones largas.

Optimizar peticiones a la API

Las peticiones a la API que bloquean el renderizado o retrasan el contenido perjudican el LCP y el TTFB; en Single Page Applications, los datos descargados desde el cliente son una de las razones habituales de un LCP lento.

• Haz menos peticiones a la API. Cada una penaliza la carga de la página; revisa qué necesita realmente la primera vista y elimina el resto. El batching (varias peticiones combinadas en una sola) y GraphQL ahorran round trips.
• Acelera las propias API. El diseño y la construcción de una API impactan de lleno en la página que espera su respuesta. Añade caché del lado de la API para los datos solicitados con frecuencia.
• Precarga las peticiones críticas a la API con <link rel="preload" as="fetch" crossorigin>. Igual que el preload de una imagen, inicia la petición antes de tiempo para que los datos estén disponibles en cuanto el primer render los necesite. Si omites crossorigin, el preload no coincidirá con la llamada fetch() y el navegador descargará los datos dos veces. La guía de priorización de recursos incluye más técnicas.

Optimizar widgets de chat

Los widgets de chat suelen ser una causa habitual de layout shifts e incluso pueden perjudicar al LCP si cargan demasiado pronto. Para un enfoque paso a paso, lee cómo implementar un widget de chat con Core Web Vitals perfectas.

• Carga el widget de chat después de que el contenido principal haya cargado. Nadie en la historia de internet ha necesitado chatear antes de ver el contenido de la página. Inícialo cuando termine el primer render, mediante requestIdleCallback o cuando el usuario empiece a hacer scroll.
• Oculta el widget de chat hasta que esté listo. Si provoca un layout shift, mantenlo con opacity: 0 hasta que haya renderizado por completo; así calculará su propio layout en segundo plano sin desplazar el contenido visible. Luego muéstralo con un fade in mediante una transición CSS.
• Busca y compara widgets de chat ligeros. Algunos causan muchísimos menos problemas de Core Web Vitals que otros. Antes de decidirte, compara el tamaño del bundle de JavaScript, el número de peticiones de red y el impacto en el INP de cada proveedor.

Optimizar el rendimiento del service worker

Un service worker puede acelerar drásticamente las visitas recurrentes cacheando assets e incluso páginas completas, lo que reduce el TTFB para los usuarios que vuelven. Si lo implementas mal, solo conseguirás ralentizar la navegación. Obtén más información sobre la optimización de la duración de la caché.

• Guarda los assets críticos en la caché del service worker. Una estrategia cache-first para recursos estáticos (CSS, JavaScript, fuentes, imágenes) permite que los usuarios recurrentes carguen el sitio de forma casi instantánea desde la caché local. Haz precache de los recursos más importantes en el evento install.
• Mantén limpio y ligero el código del service worker. Una lógica de enrutamiento compleja, el uso abusivo de event.waitUntil() y un manifiesto de precache gigante ralentizan la instalación. Para recursos que cambian con frecuencia pero no requieren frescura inmediata en el instante exacto del cambio, usa stale-while-revalidate.

Optimizar el contenido de vídeo

Un vídeo se convierte en el elemento del LCP cuando es el contenido visible más grande dentro del viewport; además, si es pesado, roba ancho de banda al resto de recursos críticos.

• Comprime los vídeos con un códec moderno (H.264, VP9 o AV1) y un ajuste de calidad razonable. Codifica al tamaño exacto con el que se mostrará el vídeo: uno que se ve a 400 px de ancho no necesita 1920 px. La codificación en dos pasadas ofrece la mejor calidad respecto al tamaño de archivo.
• Aplica lazy loading a los vídeos situados bajo el primer scroll. Añade loading="lazy" a los <iframe> o pospón la carga del vídeo con la API Intersection Observer. Sustituye vídeos de fondo con autoplay por una imagen de poster y carga el vídeo únicamente cuando el usuario se acerque a él haciendo scroll.
• Aloja los vídeos en un CDN rápido. Los archivos de vídeo son pesados y mejoran notablemente con la distribución mediante CDN. Un CDN o servicio de alojamiento dedicado a vídeo (Cloudflare Stream, Mux, Bunny.net) añade además streaming con bitrate adaptativo, distribución geográfica y entrega optimizada.
• Define siempre el atributo poster en los elementos <video>. El navegador podrá pintar el poster de inmediato mientras el vídeo carga; además, el poster puede ser el propio elemento del LCP, así que optimízalo como cualquier otra imagen del LCP.