Optimización de Velocidad en Shopify: Lo Que Realmente Mueve los Core Web Vitals

Las tiendas lentas no solo frustran a los compradores. Pierden rankings, suprimen conversiones y, en silencio, acumulan pérdidas de ingresos cada día. La mayoría de los comerciantes lo entienden en abstracto, pero la optimización de velocidad sigue tratándose como una tarea técnica de mantenimiento en lugar de una prioridad comercial. Ese encuadre es lo primero que hay que corregir.

Google ha sido claro: los Core Web Vitals son una señal directa de ranking. Las tiendas que los reprueban compiten con una mano atada a la espalda, sin importar qué tan fuerte sea su catálogo, su inversión publicitaria o su SEO on-page. La matemática no perdona. Los propios datos de Google muestran que por cada retraso en la carga móvil, la tasa de conversión cae aproximadamente un 20%. En una categoría donde los costos de adquisición pagada siguen subiendo y las posiciones orgánicas son cada vez más difíciles de mantener, un sitio lento no es un problema técnico. Es un problema de margen.

Qué miden realmente LCP, INP y CLS en una tienda Shopify

Las tres métricas miden cosas distintas, y cada una tiene una causa raíz diferente en un tema Shopify típico.

Largest Contentful Paint (LCP) mide cuánto tarda en renderizarse el elemento visible más grande de la página. En una página de producto Shopify, casi siempre es la imagen hero del producto. El umbral "bueno" de Google es por debajo de 2.5 segundos. Entre 2.5 y 4 segundos necesita mejora. Por encima de 4 segundos, Google penaliza activamente. La mayoría de los temas Shopify cargan una imagen sin optimizar en la parte superior de la página mientras ejecutan JavaScript de varias apps instaladas al mismo tiempo. Ambas cosas compiten por el hilo principal del navegador, y la imagen suele perder.

Interaction to Next Paint (INP) reemplazó a First Input Delay (FID) como Core Web Vital en marzo de 2024. La distinción importa porque FID solo capturaba el retraso en la primera interacción. INP mide la respuesta en cada interacción durante toda la sesión: pulsar un botón, seleccionar una variante, agregar al carrito, abrir el menú móvil. El umbral bueno de Google es por debajo de 200ms. Las tiendas con cinco o más apps activas suelen superarlo en móvil, porque cada app compite por tiempo de ejecución de JavaScript en el hilo principal.

Cumulative Layout Shift (CLS) mide la estabilidad visual. Cuando el contenido se mueve inesperadamente al cargar, es un evento de CLS. Un cliente a punto de tocar Agregar al carrito no debería ver ese botón saltar 40 píxeles hacia abajo porque un banner promocional terminó de cargar medio segundo después. Más allá de la frustración, los layout shifts causan toques erróneos, sesiones abandonadas y una experiencia medible peor en móvil. El umbral bueno de Google para CLS es 0.1 o menos. Las páginas de colección suelen ser las peores en CLS porque los productos y los filtros se cargan dinámicamente — un tema que profundizamos en Por qué tus páginas de colección Shopify no rankean.

Las tiendas que aprueban los tres umbrales ven, en promedio, un 24% menos de abandonos. Las que reprueban aunque sea uno están dejando tráfico e ingresos sobre la mesa de formas que ningún contenido o link building puede compensar del todo.

Los tres mayores asesinos de velocidad en Shopify

La mayoría de los comerciantes instalan apps y agregan funciones de forma incremental durante años. Cada adición se sintió justificada en aislamiento. El efecto acumulado es una tienda corriendo 12 a 20 scripts de terceros en cada carga, la mayoría bloqueando el render, muchos redundantes.

Los scripts de apps son por mucho el culpable más común. Cada app que agrega un pixel, un widget de chat, un carrusel de reseñas o un badge de fidelidad inyecta JavaScript en la tienda. Shopify no controla cómo cargan los scripts las apps de terceros. La mayoría carga de forma síncrona por defecto, lo que significa que el navegador detiene el parseo de la página para descargar y ejecutar cada script antes de continuar. Una tienda con ocho apps que cargan un script síncrono cada una está haciendo que el navegador complete ocho operaciones bloqueantes antes de que los clientes puedan ver o interactuar con la página. Las mismas apps también suelen inflar tu superficie de rastreo con URLs parametrizadas — mira Navegación facetada en Shopify: qué bloquear y por qué para mantener eso bajo control a nivel de indexación.

Las imágenes sin optimizar son el segundo asesino. El CDN de Shopify es genuinamente bueno, y la plataforma genera múltiples variantes redimensionadas de las imágenes subidas. El problema es la configuración. Shopify no prioriza automáticamente la imagen LCP para precargarla. No siempre sirve WebP o AVIF por defecto en temas más viejos. Y desde luego no puede corregir a un comerciante que sube un PNG de 4MB para una miniatura que se renderiza a 400 píxeles de ancho. Las imágenes de producto suelen cargar a 1000px cuando solo se muestran a 500px en móvil, desperdiciando ancho de banda y ralentizando el LCP en los dispositivos que más necesitan velocidad.

El código de tema que bloquea el render completa los tres. Los temas acumulan CSS y JavaScript con el tiempo. Cada sección, snippet y bloque de app agregado al tema potencialmente suma al critical rendering path. El CSS y JavaScript no usados se cargan de todas formas. CSS que pertenece a una página secundaria se carga en la home. Las fuentes cargan tarde y causan layout shifts cuando finalmente llegan. La pestaña Coverage en Chrome DevTools mostrará, brutalmente, qué tanto del JavaScript y CSS de un tema nunca se ejecuta en una página. En temas muy personalizados, código no usado superando el 70% de los assets cargados no es raro.

Cómo auditar el rendimiento del tema antes de tocar una sola línea de código

El enfoque correcto empieza con medición, no con conjeturas.

PageSpeed Insights es el punto de partida. Pega la URL de tu home, tu mejor página de producto y tu mejor colección que convierte. Corre cada una en móvil. El puntaje móvil es lo que importa para las señales de ranking de Google. Presta atención a la sección de field data, que representa experiencias reales de usuarios desde el Chrome User Experience Report. El lab data, los puntajes simulados, es útil para depurar. Pero Google usa el field data.

Dentro del reporte de PageSpeed, presta atención a las secciones de Opportunities y Diagnostics. Te dicen específicamente qué recursos bloquean el render, qué imágenes carecen de dimensiones explícitas (una bandera de CLS) y si las imágenes LCP están siendo precargadas. Toma capturas y documenta los puntajes baseline antes de hacer cambios. Mientras auditas, verifica que tus etiquetas canónicas apunten a donde crees — Shopify hace mucho automáticamente, pero los huecos que deja están documentados en Etiquetas canónicas en Shopify: qué hace la plataforma automáticamente y dónde falla.

La pestaña Coverage en Chrome DevTools va más profundo. Abre DevTools, navega al panel Coverage (disponible vía el Command Menu con Ctrl+Shift+P en Windows, Cmd+Shift+P en Mac), inicia la grabación, recarga la página, luego detén. El panel muestra cada archivo de JavaScript y CSS cargado, y qué porcentaje de cada uno fue realmente usado durante la carga. Las barras rojas indican código no usado. Un theme.js donde el 80% del código no se usa en la home es una señal fuerte para investigar qué secciones e integraciones de apps están cargando assets que no necesitan.

Corre esta auditoría en al menos tres páginas: home, una página de detalle de tu producto con mayor revenue y una página de colección. Los cuellos de botella suelen ser consistentes, pero no siempre. Si prefieres que nosotros corramos el baseline completo y te entreguemos una lista priorizada, eso es exactamente lo que cubre nuestra auditoría Shopify gratuita.

Diferir scripts de apps en Shopify Liquid

No todos los scripts necesitan correr antes de que la página sea visible. La mayoría de scripts de apps no necesitan correr hasta después de que la página haya cargado. Shopify Liquid te da el control para imponerlo.

La intervención más simple es agregar atributos defer o async a los tags de script en el código del tema. Un script defer se descarga en paralelo con el parseo de HTML y se ejecuta después de que termina el parseo. Un script async se descarga en paralelo pero se ejecuta tan pronto como se descarga, lo que puede interrumpir el render si llega temprano. Para la mayoría de scripts de apps de terceros, defer es el default correcto.

<script src="{{ 'app-widget.js' | asset_url }}" defer></script>

Para scripts que no son necesarios hasta que el usuario interactúe, lazy loading vía Intersection Observer es más agresivo y más efectivo. El tag de script solo se inyecta en el DOM cuando un elemento objetivo entra al viewport:

<script>
  const observer = new IntersectionObserver((entries) => {
    if (entries[0].isIntersecting) {
      const script = document.createElement('script');
      script.src = "{{ 'heavy-widget.js' | asset_url }}";
      document.body.appendChild(script);
      observer.disconnect();
    }
  });
  observer.observe(document.getElementById('widget-container'));
</script>

Para widgets de chat, apps de reseñas y overlays de fidelidad que están debajo del fold en la mayoría de dispositivos, el lazy loading puede eliminar su impacto en LCP por completo. El widget sigue cargando, el cliente lo sigue viendo, pero el navegador ya renderizó el contenido crítico antes de que el script se ejecute.

Una advertencia: algunas apps prohíben explícitamente modificar su comportamiento de carga de scripts en sus términos de servicio, y algunas se rompen si se difieren. Prueba primero en un entorno de desarrollo y verifica la funcionalidad core de la app después de cada cambio.

Optimización de imágenes: qué maneja Shopify vs. qué debes configurar tú

El CDN de Shopify maneja redimensionado automático, caché y, en la mayoría de temas construidos después de 2021, conversión a WebP. Son ventajas reales que plataformas como WooCommerce no igualan de fábrica. Pero no son suficientes por sí solas.

De qué eres responsable:

Usa srcset para servir imágenes de tamaño apropiado. Dawn y la mayoría de temas Shopify modernos incluyen markup de imagen responsiva usando el filtro image_url de Shopify con parámetros de tamaño. Si usas un tema más viejo o muy personalizado, verifica si tus imágenes de producto están sirviendo múltiples tamaños o siempre cargando en resolución completa.

<img
  src="{{ product.featured_image | image_url: width: 800 }}"
  srcset="{{ product.featured_image | image_url: width: 400 }} 400w,
          {{ product.featured_image | image_url: width: 800 }} 800w,
          {{ product.featured_image | image_url: width: 1200 }} 1200w"
  sizes="(max-width: 768px) 100vw, 50vw"
  alt="{{ product.featured_image.alt }}"
  width="800"
  height="600"
  loading="lazy">

Agrega atributos width y height explícitos a cada imagen. Es la corrección más impactante para CLS en tiendas Shopify. Cuando el navegador conoce las dimensiones antes de cargar el archivo, reserva el espacio correcto. Sin dimensiones explícitas, las imágenes causan layout shifts al cargar.

Precarga la imagen LCP. La imagen hero de una página de producto casi siempre es el elemento LCP. Agrega un preload hint en el <head> para decirle al navegador que empiece a buscarla inmediatamente, antes de encontrarla en el body:

{% if template == 'product' %}
  <link rel="preload" as="image" href="{{ product.featured_image | image_url: width: 800 }}">
{% endif %}

Audita los tamaños de tus imágenes subidas. La compresión automática de Shopify tiene límites. Sube una foto de producto de 5MB en raw y Shopify la comprimirá, pero no al punto de descartar resolución genuinamente innecesaria. Pasa tus imágenes por una herramienta como Squoosh o ImageOptim antes de subirlas. Apunta a menos de 200KB para la mayoría de imágenes de producto, menos de 100KB para miniaturas.

Cómo se ve una mejora real de CWV

Las tiendas que ven las ganancias más significativas no son las que ajustan uno o dos settings. Son las que abordan la velocidad como un proyecto con un alcance definido, mediciones baseline e implementación por fases.

En el trabajo que Shugert ha hecho en tiendas con LCP entre 4 y 6 segundos, las intervenciones que consistentemente mueven más la aguja son: remover o diferir scripts de apps no usadas, agregar dimensiones explícitas en plantillas de producto y colección, precargar la imagen LCP en páginas de producto y auditar CSS y JavaScript que carga en cada página sin importar si se necesita.

Una tienda que empieza con LCP de 5.2 segundos en móvil puede realísticamente llegar a 2.4 segundos con una auditoría de scripts y un pase de optimización de imágenes bien ejecutados. No es un resultado teórico. Las mejoras en INP suelen ser más dramáticas en términos porcentuales porque el baseline suele ser muy malo; bajar de 600ms a 180ms en una página de producto es alcanzable cuando los scripts de apps se difieren y el hilo principal deja de estar bloqueado por seis cargas síncronas de terceros.

Las correcciones de CLS, aunque menos glamorosas, suelen tener el impacto comercial más directo. Un CLS de 0.3 o más en una página de producto móvil significa que los clientes se equivocan al tocar y abandonan. Bajarlo de 0.1 mediante dimensiones explícitas y slots reservados elimina fricción que ninguna optimización de copy puede compensar.

Cuándo arreglar el tema vs. cuándo reemplazarlo

Esta pregunta surge en casi cada auditoría de rendimiento. La respuesta depende de dos factores: qué tan lejos está el tema actual del rendimiento baseline y qué tanto del problema es el tema en sí versus configuraciones encima.

Un tema que puntúa 30 en PageSpeed móvil por 18 apps instaladas no es un problema de tema. Remueve las apps no usadas, difiere las esenciales, y el tema puede rendir bien. Un tema custom construido en 2019, que carga 400KB de plugins jQuery y ha acumulado cuatro años de adiciones de tres agencias distintas es otra situación. El peso de las decisiones acumuladas está horneado en la arquitectura. Parchearlo es posible, pero siempre estás corriendo detrás.

El propio tema Dawn de Shopify consistentemente logra buenos puntajes de Core Web Vitals porque fue diseñado con el rendimiento como restricción de primera clase. Si la arquitectura del tema es el cuello de botella principal y el negocio tiene runway para una migración propia, mudarse a un tema moderno y orientado a rendimiento superará a cualquier parche sobre un código que envejece. Para tiendas del lado más grande de esa decisión, Migración a Shopify Plus cubre cómo cronometrar el salto de plataforma junto con la reconstrucción del tema.

El umbral honesto: si una auditoría a fondo muestra que el tema en sí contribuye más del 60% de la deuda de rendimiento, y el negocio no puede recuperarla solo con optimización de scripts e imágenes, vale la pena planificar el reemplazo del tema.

Hacerlo bien

La optimización de velocidad no es una tarea de una vez. Se agregan apps. Se modifican temas. Una landing de campaña sube apurada con imágenes sin optimizar. Las tiendas que sostienen buenos puntajes de Core Web Vitals son las que tratan el rendimiento como una disciplina continua, no un sprint seguido de abandono.

Si los puntajes de PageSpeed de tu tienda están en rojo en móvil y no estás seguro por dónde empezar, los servicios de rendimiento Shopify de Shugert cubren el stack completo: auditoría baseline, análisis de scripts de apps, optimización de imágenes, revisión de código del tema y monitoreo continuo. Lo hacemos como Shopify Select Partner desde 2015, y el patrón es consistente: las tiendas que se comprometen con una limpieza de rendimiento propia ven moverse rankings y conversión en semanas, no meses.

---

Samuel Noriega es Fundador y CEO de Shugert, Shopify Select Partner desde 2015 con oficinas en Barcelona, Ciudad de México y Nueva York. Ha liderado más de 30 migraciones y proyectos de rendimiento Shopify desde 2016. linkedin.com/in/samuelnoriega