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:

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 )

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) `html `

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 `html `

3. Critical CSS inline `html `

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 `html

`

2. Code-splitting `javascript // En lugar de cargar todo: import App from './App';

// 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 `javascript // En lugar de bloquear el main thread: const result = heavyCalculation(data);

// En Web Worker: const worker = new Worker('/js/worker.js'); worker.postMessage(data); `

Optimizar CLS

1. Reservar espacio para imágenes `html

`

2. Reservar espacio para anuncios `html

`

3. CSS aspect-ratio para vídeos e iframes `css .video-wrapper { aspect-ratio: 16 / 9; width: 100%; } `

4. Font loading optimizado `css @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 `javascript // MAL: causa CLS setTimeout(() => { document.getElementById('banner').innerHTML = '

'; }, 1000);

// BIEN: reserva el espacio

`

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: `html `

Lazy loading (below the fold): `html `

CSS

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

`html `

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): `javascript // MAL: bundle 500KB import App from './App'; import Modal from './Modal'; import Chart from './Chart'; import { everything } from './utils';

// BIEN: solo lo necesario en cada página const Modal = lazy(() => import('./Modal')); `

Tree-shaking (eliminar código muerto): `javascript // MAL: importas todo import _ from 'lodash';

// 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): `html

`

Subset (solo los caracteres que usas):

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

Herramientas: fonttools, glyphhanger

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

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

Third-party scripts

Lazy load: `html `

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): `html

`

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.