Guía pilarRendimiento
Guía de Optimización de Rendimiento Shopify para marcas DTC de $1M+
Todo lo que enviamos para llevar una tienda Shopify o Shopify Plus de un LCP mobile de 3.8s a sub-1.8s — sin romper el cart, el checkout ni las apps del equipo de marketing.
Actualizado Mayo 2026 · 18 min de lectura
Trabajamos típicamente con tiendas Shopify y Shopify Plus que facturan $500k+ al año.
Publicado
El rendimiento Shopify es un problema de ingresos, no de ingeniería
La mayoría de reportes de performance terminan archivados como "nice-to-have de ingeniería". Ese encuadre es por qué tu tienda sigue lenta. En cada tienda Shopify que auditamos en el rango de $1M–$50M, una mejora de 1 segundo en LCP mobile correlaciona con 6–12% de lift en conversión.
La velocidad es la primera impresión que se lleva un visitante de tráfico pago. Si tu hero tarda 4.2 segundos en renderizar, ya quemaste la mitad de un click de Meta antes de que el usuario decida si le interesas. Performance no es "pulido" — es la palanca de CRO más barata que tienes.
Esta guía recorre el playbook completo que usamos en tiendas Shopify Plus: las métricas que importan, cómo diagnosticamos, los fixes que enviamos por orden de palanca, y cómo evitar que la velocidad regrese en cuanto marketing instala una nueva app.
Las métricas que importan: LCP, INP, CLS
Olvida los scores de lab. Google rankea y tus clientes viven las métricas de campo — lo que ven los usuarios reales en Chrome, agregado en CrUX. Las tres que mueven la aguja en Shopify son LCP, INP y CLS.
LCP (Largest Contentful Paint)
Tiempo hasta que renderiza el elemento visible más grande. En storefronts Shopify casi siempre es tu hero o la foto del PDP. Objetivo: bajo 2.5s en mobile P75.
INP (Interaction to Next Paint)
INP reemplazó a FID en marzo 2024 y casi todos los themes Shopify regresaron silenciosamente. Mide cuánto tarda la interacción más lenta en pintar respuesta. JS pesado, tag managers y widgets de reviews mandan INP a 400–800ms. Objetivo: bajo 200ms.
CLS (Cumulative Layout Shift)
Jank visual. Anuncios, fuentes que cargan tarde, imágenes sin dimensiones, banners sticky. Themes Shopify que no reservan espacio para contenido inyectado por apps son los culpables más comunes. Objetivo: bajo 0.1.
Diagnosticar antes de optimizar
Cada proyecto de performance arranca con el mismo diagnóstico de 4 horas. Saltártelo es pasar una semana optimizando el asset equivocado.
- Sacar 28 días de data CrUX de field para home, top 5 colecciones y top 10 PDPs.
- Correr WebPageTest contra un perfil mobile throttled desde la región real del comprador. Default: Moto G Power en Fast 3G.
- Inventariar cada script tag con `window.performance.getEntriesByType('resource')`. Agrupar por vendor.
- Mapear cada request render-blocking en el critical path del LCP. Aquí están las victorias.
- Auditar `theme.liquid`, `cart-drawer.js` y cualquier sección custom que envíe antes del FCP.
El output es una lista priorizada. La mayoría de tiendas tienen 4–7 fixes de alta palanca y una cola larga de wins marginales. Envía los tres primeros primero.
El stack de imágenes — tu mayor palanca de LCP
En el 80% de tiendas que auditamos, el elemento LCP es una imagen 4× más grande de lo necesario, en JPEG, sin `fetchpriority` y sin preload. Arregla el stack de imágenes y resolviste la mayor parte del LCP antes de tocar JavaScript.
Lo no negociable
- Servir WebP o AVIF con `image_url` de Shopify con widths explícitos.
- `width` y `height` en cada <img> — mata CLS en una línea.
- `loading="eager" fetchpriority="high"` solo en el LCP.
- Preload del LCP en `<head>` con `imagesrcset` responsive.
- `loading="lazy"` en todo lo below-the-fold — nunca en el LCP.
Srcset responsive que sí ayuda
Enviar un hero de 2400px a un iPhone de 390px desperdicia 70% del bandwidth. Generamos srcsets en 6 widths (400/600/800/1200/1600/2400) con `sizes` que matchean tus breakpoints reales. Un hero bien tuneado normalmente quita 800–1400ms del LCP mobile.
Por dónde solemos empezar
Diagnóstico Pulse de performance de tu tienda
Un ingeniero senior revisa data de campo de LCP, INP y CLS, audita tu theme y apps, y te manda la lista priorizada de fixes — normalmente en 5 días hábiles.
Ver Pulse →App bloat y third parties del theme
La tienda Shopify Plus promedio tiene 14 apps. La mayoría inyectan JavaScript bloqueante en cada página, incluso donde no se usan. Un widget de reviews corriendo en /collections/* aunque solo se use en PDPs te está costando 200ms de INP por sí solo.
Auditoría
DevTools → Coverage → reload. Ordena por unused bytes. Cada fila arriba de 50KB sin usar es candidata a lazy-load o eliminación. Normalmente encontramos que 30–50% del JS de terceros no se ejecuta nunca.
Fixes para el mismo día
- Mover GA4, Meta Pixel, TikTok al web pixel sandbox de Shopify — ahí ya son async.
- Lazy-load de widgets de reviews vía IntersectionObserver, no en DOMContentLoaded.
- Reemplazar cart drawers pesados (Slide Cart, Rebuy) con Ajax cart nativo de Shopify.
- Auditar cada app que inyecta `<script>` en `theme.liquid` — casi todas pueden moverse a templates específicos.
JavaScript: diferido, scoped, con budget
INP es principalmente un problema de JavaScript. Long tasks bloquean el main thread y tus tap targets se sienten congelados. La cura es disciplina: cada script se gana su lugar en el critical path o se difiere.
Budget de JS
Imponemos 170KB comprimidos de JS first-party en el critical path en cada tienda. Es suficiente para un theme real. Cualquier cosa más necesita justificación.
Patrones que enviamos
- Usar features nativas del browser (dialog, details, scroll-snap) en lugar de equivalentes en JS.
- Diferir scripts no críticos con `type="module"` o `defer`.
- Romper long tasks con `scheduler.yield()` o `setTimeout(..., 0)`.
- Cachear JSON parseado en IndexedDB para carting predictivo en transiciones PLP→PDP.
Checkout server-rendered y palancas de Shopify Plus
Shopify Plus abre puertas de performance que no existen en planes estándar. Si estás en Plus y no las usas, estás dejando velocidad sobre la mesa.
Checkout extensibility
Mover todas las customizaciones de checkout de script tags a checkout extensions. El nuevo checkout server-rendered es 30–40% más rápido que el legacy `checkout.liquid` en la mayoría de tiendas. Además desbloquea Shopify Functions para descuentos, métodos de pago y delivery sin round-trip a terceros.
Hydrogen / Oxygen
Hydrogen es React-on-the-edge para storefronts que superaron Liquid. Lo deployamos cuando una marca necesita personalización del hero, PDPs complejos o compartir un backend con múltiples frontends. Hydrogen no es más rápido por default — es más rápido cuando te comprometes a streaming y partial hydration.
Markets
Usar Shopify Markets para servir storefronts regionales desde el edge más cercano. Solo el routing del CDN quita 200–400ms de LCP internacional.
Cómo enviar y medir performance de manera segura
La performance regresa en cuanto dejas de mirar. La cura es observabilidad, no heroísmo.
Medición continua
- SpeedCurve o Calibre en tus templates más importantes. Alertas en P75 LCP e INP.
- RUM vía `web-vitals`, pipe a tu warehouse de analytics. Segmenta por device, geo y template.
- Alerta de Slack cuando P75 LCP cruce tu budget por 24 horas.
Proceso de release
- Cada app nueva se benchmarkea en un theme duplicado privado antes de ir live.
- Cada deploy de theme pasa por preview URL con WebPageTest comparando contra main.
- Revisión trimestral con marketing — matar apps que no se ganan su budget de JS.
Preguntas frecuentes
¿Cuánto dura un proyecto de performance Shopify?
La mayoría entrega en 2–4 semanas. Semana 1: diagnóstico y benchmark. Semanas 2–3: implementación de los fixes de mayor palanca. Semana 4: testing de regresión y handover.
¿Optimizar performance va a romper mis apps?
No — desplegamos en theme de desarrollo y hacemos QA completo del cart, checkout, search, reviews y cualquier integración antes de tocar el theme live. Los cutovers son en ventanas de bajo tráfico con rollback listo.
¿Qué objetivo de LCP debo tener?
Bajo 2.5s en mobile P75 es el piso que Google premia. Las mejores tiendas Shopify Plus envían sub-1.8s y ven ganancias de conversión compuestas. Si hoy estás arriba de 3.5s, planea bajar a 2.5s antes de perseguir 1.8s.
¿Hay que salir de Liquid por performance?
No, salvo que tengas otras razones para ir headless (multi-storefront, personalización compleja, capa editorial pesada). Un theme Liquid bien construido con JS disciplinado y stack de imágenes tuneado iguala a Hydrogen en la mayoría de KPIs.
¿Cómo evitamos que regrese?
Wire RUM (SpeedCurve o web-vitals → tu warehouse), alertas cuando P75 LCP o INP crucen tu budget, y gate cada app nueva con un benchmark de performance antes de que vaya live.
Lecturas relacionadas en este clúster
Listo para arreglarlo
Cotiza un proyecto de performance en 48 horas
Cuéntanos tu tienda, tu LCP actual y qué has intentado. Te mandamos un plan de alcance fijo con timeline, entregables y precio.
Cotizar proyecto →