Las Core Web Vitals ya no son un capricho de Google: pesan en posicionamiento y, sobre todo, en conversión. La buena noticia es que el 90% de las tiendas Shopify pueden aprobarlas sin tocar Hydrogen ni montar un headless. La mala es que casi nadie lo hace bien a la primera.
Lighthouse te da un número bonito en laboratorio.
Google posiciona con datos de campo (CrUX). Hay tiendas con 95 en Lighthouse y CWV en rojo en Search Console, y al revés.
Los umbrales que cuentan son: LCP < 2,5s, INP < 200ms, CLS Experiencia > Core Web Vitals. Eso es lo que mueve el SEO.
En el 90% de auditorías que hago, el LCP es una imagen hero mal servida.
Patrones que veo cada semana:
Una imagen de 2400px en un contenedor de 600px. Un PNG de 1,8 MB que podría ser WebP de 180 KB. Una imagen hero con loading="lazy" (regalo a Google un LCP de 4 segundos).
Lo que funciona en Shopify: usar el filtro image_url con width específico, formato webp, fetchpriority="high" en la primera imagen y preload en el head si la sección es above the fold.
Cada app Shopify inyecta scripts, CSS y a veces fuentes.
He visto tiendas con 23 apps activas y un TBT (Total Blocking Time) de 2,1 segundos solo de third-party.
El ejercicio que hago en auditorías: entrar a /admin/apps y preguntar app por app: "¿esto factura algo? ¿lo usa alguien?". Resultado típico: 4-6 apps se pueden desinstalar sin que pase nada.
Una app de pop-ups que no convierte cuesta ~400 ms de INP. Una app de reviews mal implementada, otros 200 ms. Súmalo y entiendes por qué fallas INP.
Dawn (el theme gratuito de Shopify) aprueba CWV de fábrica.
El problema empieza cuando un freelancer pega 40 secciones custom con jQuery, sliders pesados y carruseles infinitos.
Los temas premium tipo Impulse, Prestige o Empire son rápidos si los usas como vienen. Si los personalizas a saco, igual de lentos que cualquier otro.
Mi regla: si un cliente tiene un theme con más de 18 meses sin actualizar y muchos custom, suele compensar más migrar a Dawn personalizado que arreglar el actual.
El stack típico que veo: GTM, GA4, Meta Pixel, TikTok Pixel, Klaviyo, Hotjar, alguna review app.
Cada uno suma su parte.
GTM es el más fácil de optimizar: mete todo lo no crítico con trigger "window loaded" o "timer 3s". GA4 y los pixels suelen tener consent mode bien configurado; si no, se cargan dos veces (sin consentimiento y con consentimiento) y duplicas el bloqueo.
Hotjar es el campeón de fastidiar INP. Si lo necesitas, actívalo solo en el 5% del tráfico, no en el 100%.
Cliente de moda en Alicante, theme Impulse, ~80k visitas/mes.
CWV en rojo desde hacía 9 meses, perdiendo posiciones en keywords competidas.
Qué hicimos en 6 horas de trabajo:
1. Hero image de PNG 1,4 MB a WebP 140 KB con preload.
2. Quitamos 3 apps (pop-up, wishlist no usada, una de reviews duplicada).
3. Movimos GTM a carga diferida 2s.
4. Fuentes locales en lugar de Google Fonts CDN.
5. Lazy-load correcto en todas las imágenes menos la hero.
Resultado a las 4 semanas (cuando CrUX recoge los datos): LCP de 4,8s a 1,9s. INP de 380 ms a 140 ms. CLS ya estaba bien. Subida de 18% en tráfico orgánico en 3 meses. Coste total: 480€.
INP sustituyó a FID en marzo 2024 y es mucho más exigente.
Mide la latencia de cualquier interacción: clicks, taps, teclado.
En Shopify, los puntos calientes son: añadir al carrito (sobre todo si tienes un cart drawer custom), abrir el menú móvil, filtros de colección y el buscador predictivo.
Qué mirar primero: si tienes un theme con drawer cart hecho con jQuery legacy, suele ser el culpable. Migrar a un drawer nativo de Dawn o uno bien hecho con Alpine.js baja el INP entre 100 y 250 ms.
Cumulative Layout Shift se arregla en una tarde.
Los sospechosos habituales:
Banners de cookies que aparecen tarde y empujan contenido. Imágenes sin width/height. Anuncios o widgets de reviews que cargan async sin reserva de espacio. Fuentes web sin font-display: optional que provocan FOIT/FOUT.
Reserva espacio con aspect-ratio en CSS y el 90% del CLS desaparece.
Headless con Hydrogen, Remix o Next.js puede darte CWV de revista.
Pero el coste de mantenimiento se multiplica por 4-6.
Mi regla práctica: headless solo si facturas más de 2M€/año, tienes equipo técnico interno (no agencia externa), y tu performance ya está optimizada en Shopify estándar y aún así no te basta.
Si facturas 200k-500k y un freelancer te vende headless para mejorar CWV, sal corriendo. Se arregla con 6 horas de optimización.
Core Web Vitals no es magia ni requiere headless. Es trabajo metódico de fontanería: imágenes bien servidas, apps justas, scripts diferidos y un theme cuidado. El 90% de las tiendas Shopify aprueban con 6-12 horas de optimización bien dirigida.
Si tu tienda lleva meses en rojo en Search Console, no es un problema de plataforma. Es un problema de mantenimiento. Y se arregla.
Llevo cinco años haciendo auditorías de performance en Shopify y todavía no he visto una tienda que necesite headless para aprobar CWV. Ni una. Cuando alguien me lo plantea, primero le pido la lista de apps activas.
Una optimización razonable va de 400€ a 1.500€ según el estado de partida. Tiendas con 20+ apps y theme antiguo, en la parte alta. Tiendas con Dawn limpio, suele bastar con 4-6 horas.
Los datos de CrUX se actualizan con ventana de 28 días. Tras una optimización, espera 4 semanas para ver el cambio reflejado en Search Console.
Sirve como diagnóstico técnico (te dice qué arreglar). No como KPI. El KPI es CrUX/Search Console, que mide a tus usuarios reales.
Es un factor menor pero real. En keywords muy competidas, sí mueve la aguja. En keywords long-tail con poca competencia, casi no se nota. La conversión sí mejora siempre.
Si Core Web Vitals te están penalizando tráfico real, hay margen. Descárgate la auditoría en 7 puntos o pásate por contacto.
Migraciones, CRO, integraciones y proyectos avanzados para negocios que necesitan una base más sólida.