Velocidad web 2026: Core Web Vitals explicados + cómo pasar de 50 a 95 en PageSpeed

Velocidad web 2026: Core Web Vitals explicados + cómo pasar de 50 a 95 en PageSpeed

La velocidad web en 2026 no es opcional. Google usa los Core Web Vitals como factor de ranking desde 2021, y cada 100ms extra de carga te cuesta un 7% de conversión (Akamai). Aquí la guía completa para entender las métricas y pasar tu web de 50 a 95 en PageSpeed.

(Este artículo es parte de nuestro cluster CRO para eCommerce. Si buscas info de diseño, mira diseño web para PYMEs 2026.)

Por qué la velocidad importa en 2026 (datos verificables)

4 razones que importan al negocio

1. SEO (Google confirmado en 2021)

• Core Web Vitals son factor de ranking oficial
• Mobile: penaliza más fuerte que desktop
• Impacto especialmente en "page experience signals"

2. Conversión (Akamai 2017, sigue vigente)

• 0-2s de carga: mejor conversión posible
• 2-3s: -7% conversión
• 3-5s: -20% conversión
• > 5s: -50% conversión

3. Bounce rate (Google 2016, sigue vigente)

• 1s → 3s = +32% bounce rate
• 1s → 5s = +90% bounce rate
• 1s → 10s = +123% bounce rate

4. UX y marca

• El 47% de usuarios espera < 2s de carga
• El 64% dice que la web lenta hace que pierdan la confianza en la marca
• El 79% no vuelve a una web lenta

Dato demoledor: Amazon calculó que 1 segundo extra de carga les costaba $1.6 BILLONES en ventas al año (2008, sigue vigente).

Qué son los Core Web Vitals (las 3 métricas oficiales)

Google mide 6 Core Web Vitals (desde 2024), pero las 3 principales son:

1. LCP — Largest Contentful Paint (pintura del contenido más grande)

Qué mide: cuándo aparece el elemento visual más grande de la página (imagen hero, video, bloque de texto grande).

Umbrales:

• Good: < 2.5s
• Needs improvement: 2.5s - 4.0s
• Poor: > 4.0s

Por qué importa: si tarda 4s en aparecer el hero, el usuario se ha ido a los 2s.

Cómo mejorarlo (lo más importante):

• Optimizar imagen hero (WebP/AVIF, < 100KB)
• Preload imagen LCP: <link rel="preload" as="image" href="/hero.webp">
• CDN global (Cloudflare, BunnyCDN)
• Critical CSS inline
• Servir HTML en edge

2. INP — Interaction to Next Paint (interactividad)

Qué mide: cuánto tarda la página en responder a una interacción (click, tap, key press). Reemplazó a FID en marzo 2024.

Umbrales:

• Good: < 200ms
• Needs improvement: 200ms - 500ms
• Poor: > 500ms

Por qué importa: si haces click en "Añadir al carrito" y tarda medio segundo en responder, parece que la web está rota.

Cómo mejorarlo:

• Reducir JS bloqueante
• Code-splitting (cargar JS solo donde se necesita)
• Eliminar third-party scripts pesados
• Web Workers para tareas pesadas
• defer vs async en scripts

3. CLS — Cumulative Layout Shift (estabilidad visual)

Qué mide: cuánto "salta" el contenido mientras se carga. Ejemplo: estás leyendo y de repente el texto se mueve porque ha cargado una imagen arriba.

Umbrales:

• Good: < 0.1
• Needs improvement: 0.1 - 0.25
• Poor: > 0.25

Por qué importa: pulsar el botón equivocado porque se ha movido = conversión perdida.

Cómo mejorarlo:

• Reservar espacio para imágenes (width y height en <img>)
• No insertar contenido por encima del fold dinámicamente
• Usar font-display: optional o font-display: swap con size-adjust
• Reservar espacio para anuncios y embeds

Las otras 3 métricas (oficialmente)

• FCP (First Contentful Paint): cuándo aparece el primer contenido
• TTFB (Time to First Byte): cuánto tarda el servidor en responder
• TTI (Time to Interactive): cuándo la página es completamente interactiva

Estas son importantes pero Core Web Vitals son las que Google usa como factor de ranking.

Cómo medir Core Web Vitals (gratis)

Herramientas principales

1. PageSpeed Insights (Google oficial, gratis)

• https://pagespeed.web.dev
• Datos de campo (usuarios reales últimos 28 días) + datos de laboratorio (test controlado)
• Score 0-100 con recomendaciones específicas
• Empieza aquí

2. Lighthouse (Chrome DevTools)

• F12 → Lighthouse tab
• Test en local (sin red real)
• Bueno para CI/CD

3. Chrome User Experience Report (CrUX)

• Datos REALES de usuarios de Chrome
• PageSpeed Insights los usa por debajo
• Si no hay datos de CrUX, no verás "datos de campo"

4. WebPageTest (gratis, muy detallado)

• https://www.webpagetest.org
• Test desde múltiples ubicaciones y dispositivos
• Waterfall chart detallado
• Vídeo de la carga

5. GTmetrix (gratis + premium)

• Interfaz amigable
• Histórico de tests

Monitorización continua (RUM)

Real User Monitoring (RUM) es diferente a PageSpeed:

• PageSpeed = test sintético
• RUM = datos de usuarios reales

Herramientas RUM:

• Cloudflare Web Analytics (gratis, privacy-first)
• Vercel Analytics (gratis si usas Vercel)
• Plausible (10 €/mes, privacy-first)
• Fathom (14 $/mes)
• Google Analytics 4 (gratis, completo)

Mi recomendación: Cloudflare Web Analytics + Plausible para PYMEs. GA4 si necesitas análisis avanzado.

Diagnóstico: ¿dónde está tu cuello de botella?

Waterfall chart (lo que muestra WebPageTest)

Un waterfall te dice qué recursos se cargan, cuándo y cuánto tardan. El 80% del tiempo de carga está en 3-5 recursos (imágenes pesadas, JS bloqueante, fuentes externas).

Cómo leer un waterfall: 1. Línea azul = request iniciada 2. Línea verde = TTFB (servidor responde) 3. Línea naranja = download (recurso descargando) 4. Línea roja = bloqueante (paraliza el resto)

Patrones problemáticos:

• CSS o JS cargando muy tarde (después de imágenes)
• Imágenes > 200KB sin optimizar
• 3+ requests a la misma API
• Third-party scripts bloqueando (Google Analytics, Facebook Pixel, Hotjar)
• Fonts externas sin font-display: swap

Cómo optimizar Core Web Vitals (guía práctica)

Optimizar LCP

1. Imagen hero optimizada (impacto: 30-50% mejora)

<picture>   <source srcset="/hero.avif" type="image/avif">   <source srcset="/hero.webp" type="image/webp">   <img src="/hero.jpg"         alt="Auditoría SEO técnica"         width="1200"         height="630"        fetchpriority="high"        loading="eager"> </picture>

• AVIF > WebP > JPEG (mejor compresión)
• Tamaño hero: 1200-1920px de ancho
• Peso: < 100KB ideal, < 200KB aceptable
• fetchpriority="high" (en hero image)
• loading="eager" (no lazy en hero)

2. Preload imagen LCP

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

3. Critical CSS inline

<head>   <style>     /* Solo el CSS crítico para above the fold */     body { font-family: system-ui; margin: 0; }     .hero { ... }   </style>   <link rel="preload" href="/css/full.css" as="style" onload="this.rel='stylesheet'"> </head>

4. CDN global

• Cloudflare: 0 €/mes (plan free) hasta 100k visitas
• BunnyCDN: 0.01 USD/GB
• AWS CloudFront: 0.085 USD/GB (primeros 10 TB)

5. Servidor rápido (TTFB < 200ms)

• Hosting premium: Cloudways, Kinsta, Vercel, Netlify
• Evitar hosting barato (SiteGround 3 €/mes = TTFB 800ms)
• Edge compute (Cloudflare Workers, Vercel Edge)

Optimizar INP

1. Reducir JS bloqueante

<!-- MAL: bloquea el parseo de HTML --> <script src="/js/app.js"></script></p><p><!-- BIEN: defer (se ejecuta cuando el HTML está parseado) --> <script src="/js/app.js" defer></script></p><p><!-- BIEN: async (no bloquea, pero no espera DOM) --> <script src="/js/analytics.js" async></script></p><p><!-- MEJOR: cargar solo cuando se necesita --> <script>   document.querySelector('#cart-button').addEventListener('click', () => {     import('/js/cart.js');  // dynamic import   }); </script>

2. Code-splitting

// En lugar de cargar todo: import App from './App';</p><p>// Cargar solo lo necesario: const Dashboard = lazy(() => import('./Dashboard'));

3. Eliminar third-party scripts innecesarios

Antes de añadir un script, pregúntate:

• ¿Es realmente necesario?
• ¿Cuánto peso añade?
• ¿Bloquea el render?

Top third-party scripts por peso (medir antes de añadir):

• Google Tag Manager: 80-150KB
• Facebook Pixel: 40-80KB
• Hotjar: 30-60KB
• Intercom: 200-500KB
• HubSpot tracking: 100-200KB

Solución: usar Google Tag Manager con trigger lazy (cargar script solo cuando se cumple un evento).

4. Web Workers para tareas pesadas

// En lugar de bloquear el main thread: const result = heavyCalculation(data);</p><p>// En Web Worker: const worker = new Worker('/js/worker.js'); worker.postMessage(data);

Optimizar CLS

1. Reservar espacio para imágenes

<!-- MAL --> <img src="/hero.jpg" alt="Hero"></p><p><!-- BIEN --> <img src="/hero.jpg" alt="Hero" width="1200" height="630">

2. Reservar espacio para anuncios

<div class="ad-slot" style="aspect-ratio: 1/1; min-height: 250px;">   <!-- AdSense / affiliate banner --> </div>

3. CSS aspect-ratio para vídeos e iframes

.video-wrapper {   aspect-ratio: 16 / 9;   width: 100%; }

4. Font loading optimizado

@font-face {   font-family: 'Inter';   src: url('/fonts/inter.woff2') format('woff2');   font-display: swap;  /* muestra texto con fallback mientras carga */   /* O mejor: */   font-display: optional;  /* si no carga rápido, no muestra */ }

5. No insertar contenido dinámicamente above the fold

// MAL: causa CLS setTimeout(() => {   document.getElementById('banner').innerHTML = '<div>...</div>'; }, 1000);</p><p>// BIEN: reserva el espacio <div id="banner" style="min-height: 100px;"></div>

Optimizaciones por tipo de recurso

Imágenes (mayor impacto)

Formato y compresión:

• AVIF: 30% más pequeño que WebP
• WebP: 25% más pequeño que JPEG
• JPEG: legacy, OK si no hay alternativa
• PNG: solo para logos con transparencia (mejor usar SVG)
• GIF: nunca, usar vídeo MP4/WebM

Herramientas:

• Squoosh.app (gratis, online)
• ImageMagick (CLI)
• Plugins CMS: ShortPixel, Imagify, Smush

Responsive images:

<img src="/hero-800.jpg"       srcset="/hero-400.jpg 400w, /hero-800.jpg 800w, /hero-1200.jpg 1200w"      sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"      alt="Hero">

Lazy loading (below the fold):

<img src="/imagen.jpg" alt="..." loading="lazy" decoding="async">

CSS

Crítico inline (above the fold) Resto defer (below the fold)

<head>   <!-- Critical: inline -->   <style>/* 5-10KB máximo */</style>      <!-- Rest: preload + onload -->   <link rel="preload" href="/css/full.css" as="style" onload="this.rel='stylesheet'"> </head>

Minificar (reducir 30-50%):

• CSSNano, clean-css
• Eliminar CSS no usado (PurgeCSS, UnCSS)

Plugins CMS:

• WP Rocket (cache + minify)
• Autoptimize
• Asset Cleanup Pro

JavaScript

Code-splitting (cargar solo lo necesario):

// MAL: bundle 500KB import App from './App'; import Modal from './Modal'; import Chart from './Chart'; import { everything } from './utils';</p><p>// BIEN: solo lo necesario en cada página const Modal = lazy(() => import('./Modal'));

Tree-shaking (eliminar código muerto):

// MAL: importas todo import _ from 'lodash';</p><p>// BIEN: solo lo necesario import debounce from 'lodash/debounce';

Minificar y comprimir:

• Terser (JS)
• esbuild (bundler rápido)
• Webpack con mode: 'production'

Plugins CMS:

• WP Rocket (defer JS)
• Perfmatters (granular control)

Fonts

Self-host (no usar Google Fonts CDN):

<!-- MAL: Google Fonts --> <link href="https://fonts.googleapis.com/css?family=Inter" rel="stylesheet"></p><p><!-- BIEN: self-host con preload --> <link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>

Subset (solo los caracteres que usas):

• Latin, Latin-Ext, Cyrillic, etc. (más subset = más pequeño)

Variable fonts (más pequeño, más flexible):

• 1 archivo vs 5 archivos (regular, bold, italic, etc.)

Third-party scripts

Lazy load:

<script>   // Cargar solo cuando se hace scroll   let loaded = false;   window.addEventListener('scroll', () => {     if (!loaded) {       loaded = true;       const s = document.createElement('script');       s.src = 'https://www.googletagmanager.com/gtag/js?id=...';       document.head.appendChild(s);     }   }, { once: true }); </script>

Self-host Google Analytics (ahorra 20-30KB):

• Usar server-side GTM
• O usar Plausible (más ligero, sin cookies)

Facades para embeds pesados (YouTube, Vimeo):

<!-- MAL: iframe YouTube 1.2MB --> <iframe src="https://youtube.com/embed/..." width="560" height="315"></iframe></p><p><!-- BIEN: facade + lazy load --> <div class="youtube-facade" data-video-id="...">   <img src="/thumbnail.jpg" alt="Ver vídeo">   <button onclick="this.parentElement.innerHTML = '<iframe...></iframe>'">     ▶ Reproducir   </button> </div>

CDN: el multiplicador de velocidad

¿Por qué un CDN?

• Latencia: usuario en Madrid accede a servidor en Madrid (1ms) vs servidor en NY (150ms)
• Cache edge: HTML, CSS, JS, imágenes se sirven desde el edge
• DDoS protection: absorbe ataques
• HTTP/3, Brotli, TLS 1.3: optimizaciones automáticas

CDN recomendados 2026

Gratis:

• Cloudflare (plan Free): ilimitado, 0 €, excelente

Barato (1-50 €/mes):

• BunnyCDN: 0.01 USD/GB, excelente Europa
• Cloudflare Pro: 20 $/mes, features extra

Premium (50+ €/mes):

• Cloudflare Enterprise: a medida
• Fastly: CDN Varnish-based, top tier
• AWS CloudFront: integrado con AWS

Mi recomendación: Cloudflare Free para 95% de webs. Pro si necesitas analytics avanzado o reglas de WAF.

Configuración crítica de Cloudflare

1. DNS proxy activado (nube naranja) en todos los registros 2. SSL modo Full (no Flexible) 3. Polish activado (optimización imágenes) 4. Mirage activado (lazy load imágenes en móvil) 5. Cache rules: - HTML: cache 1h, edge cache 1d - CSS/JS: cache 1 año (inmutable con hash) - Imágenes: cache 1 mes 6. Brotli compression (ya viene por defecto) 7. HTTP/3 (ya viene por defecto) 8. WAF rules: bloquear países no objetivo, bloquear bots malos

Casos reales (antes/después)

Caso 1: Blog con tema Avada → Astro

Antes:

• PageSpeed móvil: 38
• LCP: 6.8s
• JS: 1.2MB
• Theme: Avada + 45 plugins

Después:

• PageSpeed móvil: 96
• LCP: 1.4s
• JS: 80KB
• Stack: Astro 6 + Contentful + Vercel

Cambios aplicados:

• Migrar a Astro (SSG)
• Eliminar 40 plugins innecesarios
• Imágenes WebP + responsive
• CDN global (Vercel + Cloudflare)
• Critical CSS inline
• Lazy load todo below the fold

Resultado: tráfico orgánico +65% en 3 meses.

Caso 2: eCommerce con tema lento

Antes:

• PageSpeed móvil: 52
• LCP: 4.8s
• CLS: 0.21
• Theme: Custom en Shopify con muchas apps

Después:

• PageSpeed móvil: 88
• LCP: 1.9s
• CLS: 0.06

Cambios:

• Eliminar 8 apps no esenciales
• Optimizar tema (custom CSS)
• Imágenes WebP + lazy load
• Preload fuentes
• Critical CSS

Resultado: conversión móvil +18% en 2 meses.

Caso 3: Web WordPress con hosting barato

Antes:

• PageSpeed: 35
• TTFB: 850ms
• Hosting: SiteGround 3 €/mes
• Theme: Avada
• Plugins: 47

Después:

• PageSpeed: 92
• TTFB: 180ms
• Hosting: Cloudways (DO, 14 €/mes)
• Theme: GeneratePress
• Plugins: 12 (esenciales)

Cambios:

• Migrar a hosting premium
• Cambiar tema
• Eliminar plugins innecesarios
• Cache + CDN
• Imágenes optimizadas

Resultado: bounce rate -25%, tiempo en página +40%.

Herramientas de monitorización continua

Setup mínimo (gratis, 30 min)

1. PageSpeed Insights API (gratis): tests automatizados en CI 2. Cloudflare Web Analytics (gratis): RUM privacy-first 3. Plausible (10 $/mes): analytics + Core Web Vitals RUM 4. Sentry (gratis tier): performance monitoring JS

Setup avanzado (de pago, 100-500 €/mes)

1. Datadog RUM o New Relic: APM completo 2. SpeedCurve o Calibre: monitorización continua de CWV 3. DebugBear: tests sintéticos desde múltiples ubicaciones

Plan de implementación: 30-60-90 días

Semana 1-2: diagnóstico

• [ ] PageSpeed Insights (mobile + desktop)
• [ ] WebPageTest desde 3 ubicaciones
• [ ] Lighthouse completo
• [ ] CrUX data (verificar en GSC)
• [ ] Lista priorizada de issues

Semana 3-6: quick wins (P0)

• [ ] Imágenes optimizadas (WebP, AVIF)
• [ ] Critical CSS inline
• [ ] JS defer/async
• [ ] Preload LCP image
• [ ] CDN configurado

Semana 7-10: optimizaciones medias (P1)

• [ ] Code-splitting JS
• [ ] Self-host fonts
• [ ] Lazy load below the fold
• [ ] Eliminar third-party innecesarios
• [ ] Mejorar TTFB (cambio de hosting si hace falta)

Semana 11-12: validación final (P2)

• [ ] Test con WebPageTest desde 5 ubicaciones
• [ ] Monitorización RUM configurada
• [ ] Dashboard de Core Web Vitals
• [ ] Auditoría periódica mensual

Conclusión: la velocidad es la base

Sin velocidad, todo lo demás falla. Una web que tarda 5s en cargar no convierte, no rankea, no retiene. Punto.

Empieza con las optimizaciones P0 (imágenes, CSS, JS básico). En 2-3 semanas puedes pasar de 50 a 80 PageSpeed. Las optimizaciones P1 (code-splitting, fonts, hosting premium) te llevan de 80 a 95+.

Y luego, mantenimiento constante: cada nueva feature debe pasar el test de velocidad. PageSpeed es un trabajo continuo, no un proyecto.

¿Necesitas ayuda para optimizar la velocidad de tu web? Escríbeme a hola@mjora.studio — primera consulta gratuita de 30 min.

Lee el diseño web para PYMEs 2026, la accesibilidad web 2026 o la guía completa de CRO para eCommerce.