O problema estrutural dos apps no Shopify
O modelo de apps do Shopify é elegante na teoria: instale, configure, use. Na prática, cada app instalado injeta JavaScript na sua loja via App Blocks, Script Tags ou App Embeds. Esse código roda nos navegadores dos seus clientes — e compete com o conteúdo da loja pelo mesmo recurso escasso: a thread principal do JavaScript.
Uma loja com 15 apps ativos pode ter até 30-60 scripts externos sendo carregados em cada pageview. Mesmo que cada script individualmente seja "leve", o efeito acumulado pode adicionar 2-4 segundos ao LCP e tornar o INP consistentemente ruim.
Dado real de auditoria: loja com 22 apps ativos — 18 deles carregando scripts em todas as páginas, incluindo o checkout. Reduzir para 11 apps relevantes reduziu o tamanho total de JS de 4.2MB para 1.1MB e o LCP de 5.8s para 2.1s.
Como medir o impacto de cada app
Antes de remover qualquer app, meça. A intuição sobre "qual app é pesado" é frequentemente errada — um app de chat visível pode pesar menos que um pixel de analytics invisível.
Método 1 — DevTools Network com filtro de domínio
Abra o Chrome DevTools → aba Network → carregue a página com cache desativado (Ctrl+Shift+R). No filtro, procure por requests de domínios third-party (não cdn.shopify.com). Cada domínio externo é provavelmente um app. Note o tamanho e o tempo de cada request.
Método 2 — Comparação A/B com app desativado
O método mais preciso para medir o impacto real de um app específico:
- Meça o LCP e INP da loja com o app ativo (PageSpeed Insights ou WebPageTest)
- Desative temporariamente o app (sem desinstalar) no admin do Shopify
- Meça novamente nas mesmas condições
- A diferença é o custo de performance do app
Atenção ao cache: sempre desabilite o cache do browser e use o modo anônimo para medir. Resultados com cache ativo não refletem a experiência de novos visitantes — que são a maioria.
Método 3 — Shopify Speed Score + Lighthouse
O Shopify Speed Score (visível no admin → Online Store → Themes → Speed Score) usa dados reais do CrUX e do Lighthouse. Monitore esse número antes e depois de cada instalação ou remoção de app para ter um histórico de impacto.
Apps por categoria: impacto típico na performance
| Categoria de app | Impacto típico no LCP | Scripts injetados | Decisão |
|---|---|---|---|
| Chat ao vivo (Tidio, Intercom, Zendesk) | +400ms a +1.2s | 200-600KB JS | Avaliar |
| Pop-up / exit intent | +200ms a +600ms | 80-200KB JS | Avaliar |
| Reviews (Loox, Judge.me, Yotpo) | +100ms a +400ms | 60-300KB JS | Geralmente manter |
| Upsell/Cross-sell sem Checkout Extensions | +300ms a +800ms | 150-400KB JS | Avaliar |
| Subscription (ReCharge, Bold) | +200ms a +500ms | 100-250KB JS | Manter se usa |
| Pixels de rastreamento (FB, TikTok, GA4) | +150ms a +400ms | 50-200KB JS por pixel | Via GTM + defer |
| Tradutor automático | +200ms a +600ms | 100-300KB JS | Remover se não usa |
| Slider/Banner builder | +300ms a +900ms | 150-500KB JS | Substituir por nativo |
| Wishlist | +100ms a +300ms | 50-150KB JS | Avaliar ROI |
| Currency converter | +100ms a +400ms | 50-200KB JS | Avaliar se Markets resolve |
Apps que não devem carregar em todas as páginas
Um dos problemas mais comuns: apps que só são usados em páginas específicas, mas carregam scripts em todas as páginas da loja. O app de reviews, por exemplo, só faz sentido na PDP (página de produto) — mas frequentemente carrega na homepage, listagem de categorias e até no checkout.
Como controlar onde um app carrega
Verifique se o app usa App Blocks (Online Store 2.0) ou Script Tags. App Blocks são inseridos apenas nas páginas/templates onde você os adiciona no editor de temas — são o método correto. Script Tags injetam o script em todas as páginas automaticamente.
Se um app usa Script Tags e você quer limitar onde ele carrega, você pode desativar o script em páginas específicas via JavaScript:
// Inserir antes do script do app — carrega o app apenas em páginas de produto
{% if template.name == 'product' %}
// O bloco do app carrega aqui
{% endif %}
// Ou via JavaScript no theme.liquid — bloquear em homepage
if (window.location.pathname !== '/') {
// Carregar script do app aqui
var script = document.createElement('script');
script.src = 'https://app-cdn.com/widget.js';
script.defer = true;
document.head.appendChild(script);
}
Gerenciando pixels via Google Tag Manager
Pixels de rastreamento (Facebook/Meta, TikTok, Pinterest, Google Ads) são necessários mas pesados. A melhor prática é centralizá-los no Google Tag Manager com uma regra de "load after user interaction" para que não bloqueiem o LCP.
// Configuração no GTM — disparar pixels apenas após primeira interação do usuário
// Trigger: "DOM Ready" para o pixel básico
// Trigger: "All Pages - Delay 3000ms" para pixels de rastreamento avançado
// Ou via tag HTML customizada no GTM com defer nativo:
window.addEventListener('load', function() {
setTimeout(function() {
// Código do pixel aqui — executado 1s após load
}, 1000);
});
Trade-off importante: atrasar o disparo de pixels de conversão pode impactar a atribuição de vendas nas campanhas. Sempre valide com o time de mídia antes de alterar o timing de pixels de conversão — o ganho de performance precisa ser maior que o custo de atribuição perdida.
Framework de decisão: manter ou remover
Para cada app ativo na sua loja, responda estas três perguntas:
- Qual é o custo de performance? — meça o impacto no LCP com o método A/B
- Qual é o ROI demonstrável? — o app gera receita ou reduz custo mensurável?
- Existe alternativa nativa? — Shopify Markets (multi-moeda), Checkout Extensions (upsell), Metafields (dados estruturados)
Se o custo de performance for alto e o ROI não for claramente mensurável, remova. Se o ROI for claro mas o impacto for alto, invista em carregamento condicional ou substituição por alternativa nativa.
Sua loja Shopify está lenta por excesso de apps?
Fazemos auditoria completa de apps com medição de impacto individual no LCP e INP, e entregamos um relatório com o que manter, otimizar ou remover.