Saturación de apps en Shopify: cómo demasiadas apps están matando el rendimiento de tu tienda

El coste que pagas en cada carga

Cada app que instalas en Shopify promete algo: más reseñas, más upsells, más personalización o más ingresos. La pregunta de rendimiento es qué añade esa app al storefront, dónde cargan esos recursos y si el visitante paga ese coste en páginas donde la función no aporta nada.

En una app de storefront, ese coste puede incluir JavaScript, CSS, peticiones de terceros, trabajo sobre el DOM y ejecución en el main thread. No existe una cifra universal honesta de KB por app porque las implementaciones varían mucho. La propia guía de rendimiento de storefront de Shopify mide el impacto antes y después, y sus buenas prácticas de rendimiento para apps recomiendan evitar scripts que bloqueen el parser, diferir recursos no críticos y mantener los bundles pequeños.

Por eso la acumulación de apps es una de las primeras cosas que investigamos cuando una tienda Shopify madura se vuelve más lenta con el tiempo. El deterioro suele ocurrir una instalación a la vez: cada app resuelve un problema real, pero el stack rara vez se vuelve a auditar cuando las funciones se solapan, una campaña termina o la necesidad original desaparece.

Por qué no existe un coste universal por app

Una app puede tener un impacto casi imperceptible o añadir suficiente trabajo como para mover LCP o INP de forma medible. Depende de qué carga, cuándo lo carga, en qué plantillas aparece, cómo interactúa con el theme, el dispositivo y conexión del visitante y qué más compite por el main thread. El número de apps sirve como señal de inventario, no como métrica de rendimiento.

La única forma defendible de asignar un coste a una app es medir la tienda antes y después de un cambio controlado. Para el merchant, el proceso es sencillo: captura una línea base, aísla una app o integración, vuelve a probar las mismas plantillas en condiciones comparables y registra la diferencia.

INP es especialmente útil porque el app bloat no es solo un problema de primera carga. El JavaScript de terceros también puede competir con Añadir al carrito, cambios de variante, menús, búsqueda, drawers y otras interacciones después de que la página ya es visible. En móviles con menos capacidad de CPU, esa competencia puede hacerse más evidente aunque una corrida de Lighthouse en desktop parezca aceptable.

Popups y overlays, reseñas, motores de recomendación, loyalty, analytics y chat son buenos candidatos para revisar temprano porque suelen añadir recursos o lógica de interacción. Es una lista de triaje, no un ranking universal: el impacto real debe salir de tu waterfall, tus trazas de rendimiento y tus datos de campo.

Por qué "casi no la usamos" no es la prueba correcta

El instinto al auditar apps es preguntar cuáles se usan menos. Eso es incompleto. La mejor pregunta es qué integraciones están cargando código en páginas donde aportan poco o ningún valor y cuál es el coste medido de ese comportamiento. Una app de reseñas bien utilizada y limitada a producto puede ser una compensación razonable. La misma función cargando globalmente merece una revisión.

Desinstalar una app tampoco garantiza que desaparezca todo artefacto histórico de integración. Las theme app extensions modernas están diseñadas para no editar directamente el código del theme, lo que hace su retirada más limpia. Pero integraciones antiguas, snippets añadidos manualmente, píxeles, script tags, secciones y CSS pueden sobrevivir a la app que los introdujo. En nuestras auditorías tratamos la lista de apps instaladas y las peticiones reales del storefront como dos inventarios distintos y los reconciliamos.

Cómo auditar de verdad tu stack de apps

Empieza en Shopify Admin e inventaría cada app instalada, app embed, píxel e integración que pueda afectar al storefront. Después cruza ese inventario con PageSpeed Insights y con los paneles Network y Performance de Chrome DevTools. El objetivo no es adivinar por el nombre de la app, sino identificar qué carga realmente en plantillas representativas y cuándo se ejecuta.

Usa las mismas páginas para cada comparación: home, una colección de alto valor, una página de producto representativa y cualquier otra plantilla con tráfico o intención de conversión relevantes. Prueba en condiciones comparables y cambia una sola variable cada vez que sea posible.

Un workflow de 7 pasos para auditar app bloat en Shopify

1. Establece la línea base de LCP e INP. Registra PageSpeed Insights y los Core Web Vitals de campo disponibles para la home, una colección importante y una página de producto representativa antes de tocar el stack.

2. Inventaría todo lo que puede tocar el storefront. Lista apps instaladas, app embeds, píxeles, snippets del theme, scripts de terceros añadidos manualmente, inyecciones de tag manager e integraciones custom. El número de apps por sí solo no basta.

3. Cruza la evidencia del navegador. Relaciona los diagnósticos de PageSpeed Insights con Network y Performance en Chrome DevTools para asignar un propietario a cada petición de terceros o long task relevante.

4. Aísla un cambio cada vez. Deshabilita o elimina una app o integración en un theme no publicado o entorno de staging cuando sea posible, vuelve a probar las mismas páginas y registra la diferencia en vez de confiar en intuición.

5. Busca código legacy o huérfano. Revisa theme.liquid, secciones y snippets relevantes, app embeds, píxeles y assets insertados manualmente para encontrar código sin propietario de negocio. Las theme app extensions modernas son más limpias de retirar; integraciones antiguas o manuales pueden necesitar una limpieza explícita.

6. Mantén, sustituye, limita o elimina. Decide con ambos lados de la ecuación: valor de negocio medido y coste de storefront medido. Si una función solo pertenece a una plantilla, investiga carga condicional en vez de pagar su coste globalmente.

7. Valida después del deploy. Vuelve a ejecutar diagnósticos de laboratorio inmediatamente y después vigila LCP e INP reales mientras los nuevos datos de campo sustituyen a la ventana previa al cambio. La auditoría termina cuando la mejora sobrevive al tráfico de producción.

Comprueba las capacidades nativas de Shopify antes de añadir otra dependencia

Una alternativa más ligera no siempre significa otra app. Shopify Search & Discovery puede cubrir filtros, controles de búsqueda y recomendaciones de producto en themes compatibles, por lo que puede sustituir algunos casos de búsqueda o merchandising de terceros. La prueba correcta es cobertura funcional más impacto medido, no asumir que lo nativo siempre gana.

El mismo principio sirve para otras funciones: antes de instalar una nueva dependencia de storefront, comprueba si Shopify, el theme o una pequeña cantidad de código mantenible ya cubren la necesidad. El objetivo no es tener menos proveedores por sí mismo; es evitar dependencias innecesarias en runtime.

Qué hacer con las apps que no puedes quitar

Algunas apps se ganan su lugar y se quedan. Para esas, la solución no es eliminarlas automáticamente, sino controlarlas. Cuando la implementación lo permite, los recursos no críticos pueden diferirse, cargarse después de interacción o limitarse a las plantillas que realmente los utilizan. La propia guía de Shopify recomienda evitar JavaScript que bloquee el parser y retrasar recursos que no hacen falta para la experiencia inicial.

Si parte de la lógica de negocio puede moverse a una capacidad nativa como Shopify Functions, también puede reducir la dependencia de JavaScript en el storefront para casos elegibles. No sustituye a todas las apps, pero merece comprobarse antes de aceptar una dependencia permanente del lado del cliente.

En un proyecto reciente de rendimiento Shopify partimos de un stack de 14 apps. Eliminamos cuatro después de detectar funcionalidad duplicada o impacto innecesario en el storefront. Combinado con page scoping, deferral y optimizaciones relacionadas del theme y de carga identificadas durante la auditoría, el LCP móvil mejoró más de un segundo y la tienda alcanzó Core Web Vitals aprobados. La mejora vino del conjunto de limpieza y cambios de carga, no de eliminar cuatro apps de forma aislada.

Cómo medir si el arreglo realmente funcionó

No te quedes con una sola corrida de PageSpeed Insights. Los datos de laboratorio sirven para diagnóstico porque ofrecen trazas repetibles y feedback inmediato, pero no son lo mismo que la experiencia de usuarios reales. Utiliza Core Web Vitals de campo para validar que la mejora persiste entre visitantes y dispositivos reales.

Chrome UX Report agrega métricas de campo en una ventana móvil de 28 días y Search Console presenta Core Web Vitals a partir de esos datos. Por eso las mejoras de producción aparecen progresivamente a medida que el tráfico posterior al cambio sustituye observaciones anteriores. Observa la tendencia después del deploy en vez de esperar un veredicto de Search Console el mismo día.

Core Web Vitals importan para la experiencia y forman parte de las señales que utilizan los sistemas de ranking de Google, pero aprobar el informe no garantiza posiciones. Trata el rendimiento como una parte de la calidad global de la página, no como un score SEO aislado que haya que maximizar.

El patrón mayor

El app bloat rara vez viene de una única mala decisión. Suele ser una serie de decisiones razonables tomadas durante uno o dos años, cada una resolviendo un problema real, con muy pocas revisiones cuando la necesidad cambia o la función deja de justificar su coste. Trata el stack de apps como cualquier otro gasto operativo recurrente: audítalo con calendario, no solo cuando algo se rompe.

Si quieres una foto clara de qué integraciones están consumiendo tu presupuesto de rendimiento y dónde están las correcciones de mayor impacto, el trabajo de rendimiento Shopify de Shugert empieza por esta auditoría basada en evidencia antes de cambiar código del theme. Para la metodología completa, nuestra guía de optimización de rendimiento Shopify cubre cómo priorizamos imágenes, Liquid, JavaScript, código de terceros y Core Web Vitals en conjunto.

Preguntas que vale la pena hacer antes de tu próxima instalación

1. ¿Esta app añadirá recursos al storefront y en qué plantillas cargarán?

2. ¿Shopify, el theme o una integración existente ya cubren esta necesidad?

3. ¿Qué métrica de negocio justificará mantener esta dependencia dentro de seis meses?

4. ¿Cómo mediremos su impacto en LCP, INP, red y main thread antes y después de instalarla?

5. ¿Quién es responsable de volver a auditar la integración después de campañas, rediseños y cambios del stack?

Fuentes primarias detrás de este método

Shopify: Storefront performance for apps y general app performance best practices.

Shopify: Theme app extensions y Search & Discovery.

Google: Core Web Vitals y Search y page experience en Google Search.

Chrome: metodología de CrUX y ventana de datos de campo de 28 días.