Core Web Vitals en Webflow: 95+ en 2026

PageSpeed Insights es el examen que todos quieren aprobar y casi nadie aprueba bien. La diferencia entre un sitio Webflow con score 72 y uno con 95+ no es magia ni un plan más caro — es entender qué mide Google y dejar de pelearse con la herramienta.

Después de optimizar más de 80 sitios Webflow en LATAM hasta llegar a 95+ en mobile, esta es la guía técnica honesta de qué funciona, qué no, y dónde Webflow te ayuda o te limita.

Qué son los Core Web Vitals en 2026

Google mide tres métricas reales de experiencia de usuario:

LCP (Largest Contentful Paint)

El tiempo que tarda en renderizarse el elemento más grande visible above-the-fold (típicamente la imagen del hero o el H1).

Bueno: < 2.5s
Necesita mejora: 2.5s – 4.0s
Malo: > 4.0s

INP (Interaction to Next Paint) — reemplazó a FID en 2024

El tiempo entre que el usuario hace clic/tap y la página responde visualmente. Mide responsividad real durante toda la sesión, no solo la primera interacción.

Bueno: < 200ms
Necesita mejora: 200ms – 500ms
Malo: > 500ms

CLS (Cumulative Layout Shift)

Qué tanto se mueven los elementos en pantalla durante la carga. Un sitio que “salta” mientras carga frustra al usuario y mide mal.

Bueno: < 0.1
Necesita mejora: 0.1 – 0.25
Malo: > 0.25

Hay otras métricas (TTFB, FCP, TBT) pero estas tres son las que afectan ranking directamente.

Por qué Webflow parte con ventaja (y dónde se cae)

Webflow tiene cosas buenas de base:

Lo bueno:

CDN global (Cloudflare/Fastly) incluido
HTML semántico bien generado
CSS minificado automático
HTTP/2 + Brotli compression
Imágenes servidas en WebP automáticamente

Lo malo:

Si abusas de animaciones e interactions, INP se va al piso
Si subes imágenes sin optimizar, LCP se cae
Las fuentes web mal configuradas matan FCP
Custom code mal puesto bloquea el render

La buena noticia: el 90% de los problemas de performance en Webflow son por decisiones del que armó el sitio, no por la plataforma.

Cómo medir correctamente

Tres errores comunes al medir:

Error 1: medir solo en desktop

Google rankea con datos mobile. Si tu PageSpeed mobile es 60 pero el desktop es 95, te están rankeando con el 60. Mide siempre mobile primero.

Error 2: usar solo PageSpeed (Lab data)

PageSpeed usa datos simulados. Lo que Google realmente usa para rankear es CrUX (Chrome User Experience Report) — datos reales de usuarios.

Para ver CrUX:

PageSpeed Insights → ver sección “Discover what your real users are experiencing”
Google Search Console → Experience → Core Web Vitals
CrUX Dashboard

Si tu sitio tiene poco tráfico, no aparece en CrUX y Google usa datos del Chrome User Experience Report agregados. Es decir: necesitas suficientes usuarios para tener data real.

Error 3: optimizar solo home

PageSpeed mide URL por URL. Tu home puede ser 95 y tu página de servicios 60. Mide al menos: home, una landing pesada, una página de blog y una de servicio.

Optimizando LCP (el problema #1 en Webflow)

LCP suele ser la métrica que más jode. Estos son los fixes que más impacto tienen:

Fix 1: Comprimir y dimensionar imágenes hero correctamente

El hero image suele ser el LCP element. Reglas:

Resolución máxima: 1920px ancho (si tu hero es full-width). No subas imágenes 4000px.
Formato: Webflow ya convierte a WebP automáticamente. Asegúrate de subir el original en JPEG/PNG y deja que Webflow lo haga.
Peso: menos de 250KB por imagen hero. Idealmente 80-150KB.

Herramientas:

Squoosh.app para comprimir manualmente
TinyPNG para batch processing
ImageOptim (Mac) para automatizar

Fix 2: Usar `loading="eager"` en hero image

Webflow por defecto pone loading="lazy" en muchas imágenes. Esto está mal para el hero — debe cargar eager (inmediatamente).

En Webflow:

Selecciona la imagen del hero
Settings panel → desactiva “Lazy load”
Re-publica

Si tu hero usa background-image, asegúrate de que la URL esté en el HTML inicial, no inyectada vía JavaScript.

Fix 3: Preload de la fuente principal

Si usas Google Fonts o fuentes custom, agrega un preload en el <head>:

<link rel="preload"
      href="/fonts/Inter-Variable.woff2"
      as="font"
      type="font/woff2"
      crossorigin>

En Webflow: Project Settings → Custom Code → Head.

Fix 4: Reducir el “Largest Contentful Paint Element” si es texto

Si tu LCP element es un H1 (no una imagen), el problema suele ser la fuente. Mientras la fuente carga, el navegador no puede pintar el texto.

Solución: usa font-display: swap en tu @font-face para mostrar fuente fallback mientras carga la custom.

Optimizando INP (el problema #2)

INP es la métrica más nueva y la más difícil de optimizar en Webflow.

Fix 1: Reducir interactions complejas en el menú

Webflow Interactions consumen JavaScript. Si tu menú móvil tiene 8 transiciones encadenadas, el INP del primer tap del usuario será alto.

Regla: interactions críticas (menú, navegación) deben ser simples. Reserva las animaciones complejas para elementos no-críticos.

Fix 2: Lazy load de scripts third-party

HubSpot, Calendly, chat widgets — todos cargan JavaScript que bloquea el thread principal. Carga estos scripts después del onLoad:

<script>
window.addEventListener('load', function() {
  setTimeout(function() {
    var script = document.createElement('script');
    script.src = 'https://js.hsforms.net/forms/...';
    document.body.appendChild(script);
  }, 1000);
});
</script>

Esto retrasa 1 segundo después del load — el usuario no nota, INP mejora dramáticamente.

Fix 3: Eliminar Webflow Interactions innecesarias

Cada interaction añade event listeners. Audita tu sitio y elimina las que no agregan valor real:

Hover effects en mobile (no tiene sentido, no hay hover)
Scroll triggers en elementos que nadie ve
Animations en footer que nadie scroll para ver

Fix 4: Click handlers eficientes

Si tienes custom code con jQuery o handlers pesados, refactoriza a vanilla JS con delegation:

// ❌ Mal: listener por cada elemento
$('.cta-button').on('click', handleClick);

// ✓ Bien: delegación
document.addEventListener('click', function(e) {
  if (e.target.matches('.cta-button')) handleClick(e);
});

Optimizando CLS (lo más fácil de arreglar)

CLS suele estar entre 0.05 y 0.15 en sitios Webflow. Llevarlo a < 0.05 es bastante directo.

Fix 1: Dimensiones explícitas en imágenes

Webflow añade automáticamente width/height en imágenes, pero si usas background-image en divs sin altura definida, el contenido salta cuando cargan.

Regla: cualquier elemento que tenga imagen debe tener altura mínima reservada.

Fix 2: Reservar espacio para embeds

YouTube, Vimeo, Calendly embeds — todos cargan en iframe. Si no les reservas espacio, el contenido debajo salta cuando el iframe se carga.

Solución: dale al wrapper del embed un aspect-ratio: 16/9 o altura fija.

Fix 3: Cuidado con web fonts que cambian de tamaño

Si tu fuente fallback es muy distinta a la custom, hay un “FOUT” (Flash of Unstyled Text) que mueve el layout cuando carga la custom.

Solución avanzada: usa font-size-adjust o ajusta el size-adjust en @font-face para hacer match de métricas.

El stack de checks que aplicamos a cada sitio

Esto es lo que corremos en cada lanzamiento:

Pre-launch (en staging)

PageSpeed Insights mobile + desktop → ambos en verde (LCP, INP, CLS)
Lighthouse en modo Mobile Emulated Slow 4G
WebPageTest en Brasil/Chile (no en US, porque tu audiencia está en LATAM)
Auditoría de waterfall: ¿qué carga primero? ¿hay render-blocking?
Validación de imágenes: ninguna pesa > 250KB

Post-launch (continuo)

Search Console → Experience → Core Web Vitals (después de 2 semanas con tráfico real)
Real User Monitoring (RUM) si el cliente lo necesita
Re-medición mensual para detectar regresiones

Si algo está rojo

Iteramos hasta verde. Sin excusas. Un sitio Webflow bien hecho debe estar entre 90-100 en mobile sin trucos.

Trucos que NO funcionan (mitos comunes)

Mito 1: “Cargar todo lazy resuelve performance”

Cargar lazy el hero image te baja el LCP. Cargar lazy las imágenes del footer no mueve la aguja. Lazy load es una herramienta, no una bala de plata.

Mito 2: “Comprimir más siempre mejor”

Hay un punto donde la imagen se ve mal y la mejora de KB es marginal. Apunta a 80% quality en JPEG/WebP — más allá pierdes mucha calidad por poco peso.

Mito 3: “Quitar todas las animaciones”

Las animaciones bien hechas no afectan performance. Las animaciones mal hechas (continuas, sin will-change, sobre propiedades caras como width) sí. Aprende a animar transform y opacity solamente.

Mito 4: “Cambiar de Webflow a otro CMS resuelve el problema”

He visto sitios WordPress con score 35 migrados a Webflow y siguen en 60 porque el problema era el contenido (imágenes pesadas, scripts mal puestos), no la plataforma.

Cuándo Webflow no es suficiente

Para el 95% de los sitios marketing, Webflow puede llegar a 95+. Pero hay casos donde no:

Caso 1: Sitios con cientos de componentes pesados

Si tu sitio tiene 30 secciones animadas con interactions complejas, no vas a llegar a 95+ sin sacrificar funcionalidad. Considera Astro o Next.js con Webflow como diseño.

Caso 2: E-commerce de alto volumen

Webflow E-commerce no es tan performante como Shopify Hydrogen o un stack custom. Para tiendas con 1000+ SKUs y mucho tráfico, evalúa headless.

Caso 3: Apps interactivas, no sitios

Si tu “sitio” es realmente una app (dashboard, calculadora compleja, configurador 3D), Webflow no es la herramienta. Es para sitios marketing, no apps.

Próximos pasos

Si tu sitio actual está debajo de 80 en mobile y quieres llevarlo a 95+, hacemos auditorías de performance que entregan un plan claro de qué tocar y en qué orden. Solicita la auditoría — incluye análisis de Core Web Vitals y plan de optimización priorizado.

Si vas a construir un sitio nuevo en Webflow, agenda una llamada y diseñamos desde el día uno pensando en performance — no como un fix post-launch.

Y si esto es para tu propio aprendizaje, recuerda: la performance es un hábito, no un sprint. Cada vez que subes una imagen o agregas una interaction, piensa en cómo afecta a los Core Web Vitals. Esa disciplina es lo que separa los sitios de 70 de los sitios de 95+.