La mayoría de guías de Core Web Vitals te dan 12 cosas que arreglar. Es abrumador. No harás las 12. Harás cero.
Esto es lo que funciona de verdad. Arregla tres cosas. Obtén el 80% del resultado. Sigue con tu vida.
Qué aprenderás
Esta guía muestra cómo priorizar arreglos de Core Web Vitals sin perder el tiempo. Aprenderás qué métricas importan más según tu tipo de sitio. Aprenderás los tres arreglos que mueven la aguja. Aprenderás a medir resultados en unos 15 minutos.
No es teoría. Es lo que funciona para pymes y agencias sin ingeniero de rendimiento a tiempo completo.
101: Por qué importan de verdad los Core Web Vitals
Los Core Web Vitals miden qué tan rápido carga tu sitio y qué tan estable se siente. Google los usa como factor de ranking. Más importante aún: los sitios lentos pierden clientes.
Hay tres métricas:
Largest Contentful Paint (LCP) mide la velocidad de carga. Sigue cuánto tarda en aparecer el contenido principal. Lo ideal es menos de 2,5 segundos. La mayoría de sitios de pymes rondan 3,5 a 4,5 segundos.
Interaction to Next Paint (INP) mide la capacidad de respuesta. Sigue qué tan rápido reacciona el sitio al clic o toque. Lo ideal es menos de 200 milisegundos. Los sitios con mucho JavaScript suelen rondar 400 a 600 ms.
Cumulative Layout Shift (CLS) mide la estabilidad visual. Sigue cuánto salta la página al cargar. Lo ideal es menos de 0,1. Sitios con anuncios o imágenes lazy suelen superar 0,3.
La mayoría de sitios falla al menos una. El sitio medio de pyme falla dos.
Investigación de HubSpot 2024: el 75% de usuarios no pasa de la primera página de resultados. Los Core Web Vitals son el desempate cuando la calidad del contenido es igual. Si tu competidor tiene el mismo contenido pero carga más rápido, rankea más arriba.
El problema con los consejos actuales
Busca optimización de Core Web Vitals y encontrarás guías completas. Listan 12 a 15 tácticas. Cubren cada caso límite.
Son correctas. También inútiles.
El dueño de una taquería no tiene tiempo para 15 optimizaciones de rendimiento. Una agencia con 30 clientes no puede auditar cada archivo JS a mano.
Las guías completas pierden el punto. Necesitas saber qué arreglar primero. Qué mueve de verdad tus números.
Las herramientas SEO tradicionales lo empeoran. Te dan volcados de datos. 100 problemas sin prioridad. Jerga sin contexto. Pasas horas adivinando qué importa.
Lighthouse te da una puntuación de rendimiento. No te dice si arreglar imágenes o JavaScript primero. PageSpeed Insights muestra qué es lento. No te dice qué arreglo te pasa de suspender a aprobar.
201: Los tres arreglos que funcionan de verdad
Arreglo 1: Optimiza tu elemento Largest Contentful Paint
El LCP casi siempre es tu mayor problema. También es lo más fácil de arreglar.
Suele ser la imagen hero o el titular principal. La mayoría carga lento porque la imagen es enorme y sin comprimir.
Auditoría de sitio lo detectó en nuestro propio sitio: imagen hero de 2,4 MB mostrada a solo 1200 px de ancho. La foto era de 4000 px. Esos píxeles extra solo nos frenaban.
Qué hacer:
Convierte la imagen hero a WebP. Los WebP son ~30% más pequeños que JPEG a la misma calidad. Herramientas gratuitas: Squoosh o CloudConvert. Los navegadores modernos soportan WebP (Safari desde 2020, Edge desde 2018).
HTML de ejemplo:
<picture>
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Your hero image" width="1200" height="800">
</picture>El navegador carga WebP si puede; si no, usa JPEG.
Redimensiona la imagen al tamaño real de visualización. Si el hero se muestra a 1200 px de ancho, no subas una de 4000 px. Usa 1200 px en escritorio y 800 px en móvil. Sirve tamaños distintos según el ancho de pantalla.
Código:
<img
src="hero-1200.webp"
srcset="hero-800.webp 800w, hero-1200.webp 1200w"
sizes="(max-width: 768px) 800px, 1200px"
alt="Your hero image"
width="1200"
height="800"
>Añade width y height en la etiqueta img. Indica al navegador cuánto espacio reservar y evita layout shift al cargar. Los navegadores modernos calculan la relación de aspecto automáticamente.
Usa una CDN. Sirve imágenes desde servidores cercanos a los visitantes. CloudFlare y BunnyCDN tienen planes gratuitos. Una CDN suele recortar 40–60% el tiempo de carga de imágenes.
Añade fetchpriority=“high” a la imagen LCP. Indica al navegador priorizar esta imagen. Es una sugerencia; los navegadores la respetan cuando pueden.
<img
src="hero.webp"
alt="Your hero image"
width="1200"
height="800"
fetchpriority="high"
>Solo este arreglo puede bajar el LCP de 4 s a 2 s. Es la diferencia entre aprobar y suspender.
Errores frecuentes en LCP:
No hagas lazy load del elemento LCP. El lazy load dice al navegador que espere; el LCP debe cargar al instante.
No pongas el LCP bajo el pliegue. El LCP mide el contenido visible más grande; si el hero es pequeño y el contenido principal está abajo, optimiza lo que se ve primero.
No comprimas demasiado. WebP al 80% de calidad está bien; al 40% se ve fatal. Busca equilibrio.
Arreglo 2: Diferir JavaScript no crítico
El JavaScript bloquea el render. El navegador descarga, parsea y ejecuta cada script antes de mostrar la página. La mayor parte no hace nada en la carga inicial.
Un sitio medio de pyme carga 8–12 archivos JS al inicio. La mayoría alimenta funciones bajo el pliegue; no tienen por qué ir primero.
Qué hacer:
Añade defer a las etiquetas script. El navegador descarga en segundo plano y ejecuta después de cargar la página.
<!-- Before: blocks rendering -->
<script src="analytics.js"></script>
<!-- After: loads in background -->
<script src="analytics.js" defer></script>El atributo defer mantiene el orden de ejecución: si el script B depende de A, siguen en orden; solo que no bloquean el render.
Mueve analytics y tracking al final de la página. Google Analytics no tiene que cargar antes del contenido. Tampoco Facebook Pixel ni el chat en vivo.
Colócalos justo antes de </body>. Cargan después de todo lo demás.
Elimina JavaScript no usado. Muchos sitios WordPress cargan jQuery para funciones que no usan. Temas con librerías de animación para un solo botón.
Revisa qué scripts se ejecutan al cargar: Chrome DevTools → pestaña Coverage → recarga. Chrome muestra cuánto de cada archivo se ejecuta de verdad.
Si un archivo está 80% sin usar, probablemente no lo necesitas. Elimínalo o divídelo.
Usa async para scripts independientes. async descarga en paralelo y ejecuta al terminar. Útil para analytics u otros independientes.
<script src="analytics.js" async></script>
<script src="chat-widget.js" async></script>No uses async si un script depende de otro: si B necesita A primero, usa defer.
Este arreglo suele mejorar el INP 100–200 ms y también ayuda al LCP porque el navegador puede centrarse en el contenido.
Errores frecuentes con JavaScript:
No difieras JS crítico para la navegación si sin él el menú se rompe.
No pongas async a todo: cambia el orden de ejecución y puede romper dependencias.
No quites JS sin probar: un archivo cada vez, verifica y sigue.
Arreglo 3: Dimensiones explícitas en imágenes y elementos
El layout shift ocurre cuando los elementos cargan sin tamaño definido. El navegador adivina el espacio, falla y la página salta.
Es lo más molesto de Core Web Vitals: el contenido se mueve al leer, haces clic y pinchas mal.
Qué hacer:
Añade width y height a cada imagen. Los navegadores modernos calculan relación de aspecto y reservan espacio.
<!-- Before: no dimensions, causes layout shift -->
<img src="product.jpg" alt="Product photo">
<!-- After: browser reserves correct space -->
<img src="product.jpg" alt="Product photo" width="600" height="400">No hace falta coincidir exactamente con el tamaño en pantalla: el navegador escala; basta la relación de aspecto correcta.
Reserva dimensiones de anuncios e incrustaciones antes de que carguen. Google Ads: píxeles exactos en CSS. YouTube: espacio 16:9 antes del embed.
.ad-container {
width: 300px;
height: 250px;
background: #f0f0f0;
}Carga fuentes web con font-display: swap. Muestra fuentes del sistema al instante y cambia cuando carga la tuya; evita texto invisible y reflow.
@font-face {
font-family: 'YourFont';
src: url('your-font.woff2') format('woff2');
font-display: swap;
}El texto aparece de inmediato con fuente sustituta; al cargar la tuya, hace swap. Mejor que esperar la fuente para mostrar nada.
Evita inyectar contenido encima del existente. Con lazy load de imágenes o anuncios, colócalos bajo el pliegue para no empujar el contenido.
Usa loading="lazy" en imágenes bajo el pliegue para diferir hasta que el usuario se acerque al hacer scroll.
<img src="below-fold.jpg" alt="Image below fold" loading="lazy" width="800" height="600">Este arreglo puede bajar el CLS de 0,3 a menos de 0,1: de suspenso a casi perfecto.
Errores frecuentes de layout shift:
No inyectes banners promocionales arriba después de cargar: reserva espacio en el HTML inicial si hace falta.
No uses animaciones CSS que cambien el tamaño de elementos: usa transform (no afecta al layout).
No cargues fuentes sin fallback: define una pila de fuentes sustitutas en CSS.
Cómo saber qué arreglar en tu sitio
Los tres arreglos valen para la mayoría, pero tu sitio puede ser distinto.
E-commerce: suele fallar LCP por fotos de producto (3–5 MB cada una). Comprimirlas puede partir el LCP por la mitad.
SaaS: suele fallar INP por dashboards con mucho JS. Diferir scripts no críticos ayuda.
Medios: suelen fallar CLS por anuncios y lazy load entre párrafos.
Necesitas saber qué métrica es tu eslabón más débil y qué arreglo mueve tus números.
301: Por qué fallan las herramientas tradicionales
PageSpeed Insights da puntuaciones; Lighthouse da oportunidades. Ninguna dice qué arreglar primero.
Ves 20 problemas con «ahorro potencial». El que ahorra 2 s parece más importante que el de 0,5 s.
Esa matemática engaña: los 2 s pueden exigir reescribir toda la arquitectura JS (40 h); los 0,5 s pueden ser una imagen (5 min).
Las herramientas clásicas no ponderan el esfuerzo ni te dicen qué te pasa de suspenso a aprobar. Solo vuelcan datos.
Auditoría de sitio ejecuta una auditoría técnica en ~15 minutos. Planes desde 50 $/trabajo. Revisa las tres métricas de Core Web Vitals, identifica qué elementos te frenan y ordena los arreglos por impacto.
Obtienes informe completo con proyecciones antes/después, archivos y líneas concretas, y JSON para automatizar en muchos sitios.
Muchas auditorías cuestan 500 $ y tres días. Site Audit cuesta 50 $ y corre mientras te haces un café.
Cómo funciona Site Audit de verdad
Site Audit combina varias herramientas en un informe priorizado: PageSpeed Insights (lab), Chrome UX Report (usuarios reales), Pa11y (accesibilidad), compatibilidad en Chrome, Firefox, Safari y Edge.
Luego usa IA para sintetizar un plan de acción priorizado.
No recibes 100 problemas sin contexto: recibes ~5 acciones con esfuerzo e impacto estimados. Cada una incluye problema, impacto en el negocio, arreglo y resultado esperado.
Alcances: 30 o 100 páginas. El de 30 páginas encaja en sitios pequeños: auditorías core, 5 acciones priorizadas y pruebas de navegador.
El de 100 añade análisis competitivo (hasta 2 competidores), huecos de keywords, schema y benchmarks. También análisis de brechas de contenido con ideas de qué escribir.
Cifras reales en sitios reales
En surmado.com Site Audit encontró 4 problemas reales: faltaba schema LocalBusiness (15–30% de mejora típica en búsqueda local; al añadirlo, +18% tráfico local en 30 días); faltaban 3 cabeceras de seguridad (puntuación de 2 a 5); cuellos de botella de fuentes (speed index de 3,2 s a 2,1 s con font-display swap).
Lighthouse no lo vio todo: prueba un navegador en condiciones ideales. Site Audit prueba cuatro con métricas reales y, en Pro, navegadores in-app de redes sociales.
El 30–50% del tráfico puede venir de redes; si el sitio falla en el navegador de Instagram, pierdes ese tráfico.
Comparación de herramientas que sí necesitas
PageSpeed Insights: gratis, puntajes de lab; no prioriza ni compara con competidores ni prueba redes sociales.
Lighthouse: gratis en DevTools; exige expertise (waterfall, render-blocking).
Semrush Site Audit: ~1.400 $/año; rastrea todo y te da 100+ problemas sin orden claro.
Screaming Frog: ~199 $/año; enlaces rotos y metadatos, no rendimiento ni impacto de negocio.
Site Audit: desde 50 $/trabajo, plan de acción en ~15 min, 5–10 tareas concretas, análisis competitivo en Pro, métricas de campo y pruebas de navegadores sociales en Pro.
Es la capa de estrategia: el resto da datos; Site Audit dice qué hacer con ellos.
Cuándo falla optimizar solo Core Web Vitals
Si tu sitio está en la página 5, los Core Web Vitals no te salvan: primero contenido y enlaces.
Si tus competidores también van mal, mejorar te ayuda; si todos van perfectos, igualar solo nivelas el campo.
Son un desempate cuando la calidad del contenido es similar y compites por posiciones 1–5 en la página 1. Google usa cientos de señales.
No pierdas 40 h optimizando vitals si el contenido es fino o no hay backlinks: arregla lo básico primero.
API y automatización para agencias
Site Audit incluye API y webhooks: lanzas auditorías por código, recibes JSON estructurado, dashboards o informes automáticos. REST, POST con URL, ejecución asíncrona, webhook al terminar.
JSON con métricas, acciones priorizadas y comparativas. Modo clean-label en Portfolio: tu marca en los informes.
Muchas agencias cobran 500–1.000 $ por auditorías; Scout entrega calidad similar en ~15 min.
Consejos por framework
WordPress: plugins de caché (WP Rocket, W3 Total Cache) suelen manejar imágenes, defer y CDN en ~10 min.
Shopify: lazy loading nativo en productos; difiere apps que añaden JS (mucha tienda carga 8–12 scripts de terceros).
Next.js: componente Image, imports dinámicos para JS solo cliente.
React: React.lazy, Intersection Observer para bajo el pliegue.
Estáticos: prerender en build (Eleventy, Hugo), CDN para archivos estáticos.
Cómo medir resultados
PageSpeed Insights antes/después; tres mediciones y promedia (la red fluctúa). Mira móvil (Google rankea por móvil).
Datos de campo: espera ~28 días (Chrome UX Report ventana móvil). Pro/Portfolio incluyen monitorización semanal; trabajos extra ~25 $.
Preguntas frecuentes
¿Cuánto tarda? Los tres arreglos suelen ser 1–3 h en total (imágenes ~30 min, defer ~30 min, dimensiones 1–2 h según cantidad).
¿Necesito desarrollador? Para lo básico no. JS con temas custom puede requerir ayuda.
¿Romperá mi sitio? Prueba en staging, un cambio cada vez.
¿Cuánto subirá el tráfico? Si ya estás 4–7 en página 1, mejorar vitals puede llevarte a 2–4 (+20–40% típico). En página 2–3, los vitals solos no te llevan a página 1.
¿Todas las páginas? Empieza por home, top 10 landings y top 10 producto/servicio (~80% del tráfico).
¿Page builders? Elementor/Divi añaden peso; aún puedes optimizar imágenes y dimensiones. El defer es más difícil con scripts inline.
Qué hacer esta semana
Elige el arreglo que peor métrica tengas:
LCP > 2,5 s: optimiza el hero (WebP, tamaño real, CDN) ~30 min, suele recortar LCP 40–50%.
INP > 200 ms: defer en scripts, analytics abajo, quita JS no usado ~30–60 min, +100–200 ms típico en INP.
CLS > 0,1: dimensiones en HTML, font-display swap, nada de inyección arriba ~1–2 h.
Ejecuta Auditoría de sitio para ver qué métrica atacar primero. Planes desde 50 $/trabajo. Arregla lo tres primeros puntos y vuelve a medir en una semana.
Optimizar Core Web Vitals no es complicado: no hace falta una gran agencia ni un ingeniero a tiempo completo. Hacen falta los tres arreglos correctos.