Este es un caso real, con métricas medidas en Google PageSpeed Insights y cada cambio registrado en Git. La tienda es un e-commerce Shopify mexicano de categoría restringida (verificación de edad obligatoria); mantenemos su nombre en privado, pero todos los datos técnicos de este artículo son verificables en nuestro historial de trabajo. No hay estimaciones ni números redondeados para marketing.
El punto de partida: 77 en móvil con un theme premium
La primera medición (27 de junio de 2026, PageSpeed Insights móvil) mostró un rendimiento de 77/100. No era un desastre — era el caso más común en Shopify: una tienda con theme premium bien construido, degradada por capas de decisiones acumuladas que nadie había auditado en conjunto.
| Categoría (móvil) | Antes | Después | Cambio |
|---|---|---|---|
| Rendimiento | 77 | 91 | +14 |
| Prácticas recomendadas | 92 | 100 | +8 |
| SEO | 100 | 100 | = |
| Cumulative Layout Shift | — | 0 | Perfecto |
| Total Blocking Time | — | 20 ms | Verde |
| Largest Contentful Paint | — | 3.3 s | En mejora |
Transparencia total: el LCP de 3.3s quedó en zona naranja — mejoró, pero aún no alcanza el umbral verde de Google (<2.5s). Lo publicamos igual porque un caso de estudio honesto vale más que uno perfecto, y porque la causa restante está identificada para una siguiente fase.
Los 5 problemas que encontramos en la auditoría
1. Una app de terceros cargando en cada primera visita
La tienda usaba una app externa de verificación de edad que descargaba su script y la imagen del modal desde CloudFront en cada primera visita — peso y latencia de terceros en el momento más crítico de la carga. El hallazgo clave de la auditoría: el theme premium ya traía verificación de edad nativa. La app era 100% redundante.
2. La imagen principal (LCP) descubierta tarde por el navegador
La imagen del slideshow móvil — el elemento más grande de la pantalla — tenía ~600 ms de retraso de carga. Tenía fetchpriority="high", pero estaba enterrada cientos de líneas dentro del HTML: el navegador no la descubría hasta muy tarde en el parseo. La prioridad alta no sirve de nada si el navegador aún no sabe que la imagen existe.
3. CSS bloqueante en la ruta crítica
El CSS principal bloqueaba el renderizado ~180 ms (~15.8 KB transferidos, con ~12 KB de CSS sin usar). Además, un peso adicional de la fuente serif (~15 KB) se descargaba dentro de la ruta crítica del LCP sin necesidad.
4. Layout shifts por dimensiones faltantes
Las tarjetas de colección tenían tres variantes de <img> sin width/height declarados, y la imagen lazy de la colección destacada tampoco tenía dimensiones. Cada imagen que carga sin dimensiones reservadas empuja el contenido y genera CLS.
5. Detalles que suman: botón de WhatsApp con PNG externo
El botón flotante de WhatsApp cargaba un PNG desde un dominio externo (un request adicional) y no tenía aria-label ni rel="noopener" — rendimiento, accesibilidad y seguridad en un mismo elemento.
La intervención: 9 cambios quirúrgicos, 7 archivos, 0 apps instaladas
Todo el trabajo se hizo en 4 noches efectivas (28 de junio al 2 de julio), con un commit por cambio y baseline completo del theme en Git antes de tocar nada. Metodología: reconocimiento de solo lectura → plan → un cambio quirúrgico por commit.
| Intervención | Técnica |
|---|---|
| Age-gate nativo del theme activado; app de terceros eliminada | Eliminación de third-party del critical path |
| Preload responsive de la imagen LCP móvil (imagesrcset + media query + fetchpriority) | Ataca los ~600 ms de load delay |
| Preload del CSS principal y de las fuentes woff2 (400/700) | Critical rendering path |
| width/height explícitos en tarjetas de colección y colección destacada | CLS a 0 |
| fetchpriority="high" en imágenes eager de tarjeta de producto | Priorización de recursos |
| Botón WhatsApp: PNG externo → SVG inline + aria-label + noopener | −1 request, accesibilidad, seguridad |
| Alt del logo corregido con fallback al nombre de la tienda | Accesibilidad / SEO |
Esta optimización no instaló ninguna app de velocidad, ningún plugin de caché, ninguna herramienta de compresión. Al contrario: eliminó una app. La mayoría de los problemas de rendimiento en Shopify no se resuelven agregando — se resuelven entendiendo qué está cargando tu tienda y por qué.
Lo que NO hicimos (y por qué importa)
Un caso de estudio honesto también dice lo que no se hizo. En este proyecto no hubo conversión manual de imágenes (el CDN de Shopify ya negocia formatos automáticamente), no hubo critical CSS inline, no hubo autohospedaje de fuentes ni configuración de caché. Cada tienda necesita intervenciones distintas — por eso desconfiamos de los paquetes de optimización idénticos para todos. El diagnóstico define el trabajo, no al revés.
Qué significa esto para tu tienda
Si tu tienda Shopify está entre 60 y 85 de rendimiento móvil, es casi seguro que su problema no es el theme ni el hosting — es la acumulación: apps redundantes, recursos sin priorizar, imágenes sin dimensiones. Son problemas invisibles a simple vista pero medibles y corregibles con precisión, sin rediseños ni migraciones.
Corre tu tienda en pagespeed.web.dev ahora mismo (pestaña Móvil, que es donde compra tu cliente). Si estás debajo de 85, hay puntos sobre la mesa. Y si quieres saber exactamente cuáles son en tu caso, te hacemos el diagnóstico — nuestro propio sitio corre en 100/100 y puedes verificarlo en vivo.
