Todo aplicativo instalado na sua loja cobra duas mensalidades. Uma vem no cartão. A outra vem em milissegundos, todo mês, de todos os visitantes.
A primeira você vê na fatura. A segunda quase ninguém mede — e é frequentemente a mais cara.
Nos dois artigos anteriores eu contei um caso específico: um app de avaliações que custava 1.900 milissegundos e a solução própria que construí no lugar. Este artigo generaliza aquilo em um método que você aplica a qualquer app, para descobrir sozinho quanto cada um está cobrando de você.
A resposta curta
O método tem quatro passos: listar o que cada app carrega, descobrir quem pediu cada recurso, bloquear e medir de novo, decidir com o número na mão.
A ferramenta é o DevTools do próprio navegador, sem instalar nada. O passo que muda tudo é o terceiro: bloquear a requisição e comparar. É a única forma de isolar o custo de um app sem desinstalar e reinstalar.
E o aviso mais importante: sobrescrever o app com CSS não reduz custo nenhum. O arquivo já foi baixado. Você só escondeu o sintoma.
Por que app custa mais do que parece
Quando você instala um app, ele raramente adiciona um único arquivo. O padrão é:
- Um ou mais scripts, de um domínio externo
- Uma folha de estilo, também externa
- Às vezes uma fonte própria
- Uma ou mais chamadas de API em tempo real
- Ocasionalmente, uma segunda biblioteca que o app usa internamente
Cada domínio novo obriga o navegador a fazer o ciclo completo: consulta DNS, conexão TCP, negociação TLS. Em rede móvel brasileira, cada ciclo desses custa de 200 a 500 milissegundos antes de transferir qualquer coisa útil.
Três apps de três fornecedores diferentes são três ciclos completos. E eles competem por banda exatamente com a imagem principal da sua página — aquela que provavelmente é o seu elemento de LCP.
Há um segundo custo, menos visível: tempo de processamento. Script baixado ainda precisa ser interpretado e executado, e no celular médio brasileiro isso é bem mais lento do que no seu computador.
Passo 1 — Liste o que cada app carrega
Abra o DevTools com F12 e vá em Network. Antes de recarregar:
- Marque Disable cache
- Em Throttling, escolha Slow 4G
- Recarregue com
Ctrl + Shift + R
O throttling não é detalhe. Sem ele você mede a sua internet, não a do seu cliente.
Com a página carregada, ordene por Domain. Tudo que não for o domínio da sua loja é terceiro.
Anote em uma tabela simples:
| Domínio | Arquivos | Peso total | Tempo total |
|---|---|---|---|
exemplo-app.com |
3 | 84 KB | 620 ms |
outro-servico.io |
2 | 41 KB | 380 ms |
O tempo total é o que importa mais que o peso. Um arquivo de 12 KB vindo de domínio novo pode custar mais que um de 90 KB vindo de domínio já conectado.
Passo 2 — Descubra quem pediu cada recurso
Este é o passo que separa correção rápida de investigação frustrante.
Ainda em Network:
- Clique com o botão direito no cabeçalho das colunas
- Ative a coluna Initiator
- Percorra a lista
O Initiator mostra qual arquivo disparou cada requisição. E é aqui que aparecem as surpresas:
Um app carregando outro domínio. O script do app pede uma biblioteca externa que você nem sabia que existia.
Um app carregando fonte. Foi exatamente o que aconteceu comigo, e está detalhado em Google Fonts está destruindo o LCP da sua loja. O app injetava Google Fonts sem nenhuma opção de desativar.
Um app que você desinstalou. Acontece com frequência: o app sai do painel, mas o trecho de código continua no tema. Se o initiator aponta para o seu próprio tema e você não reconhece aquilo, provavelmente é resíduo.
Essa terceira categoria costuma render vitória rápida e gratuita.
Passo 3 — Bloqueie e meça de novo
Agora o passo que dá o número.
O DevTools permite bloquear uma requisição sem tocar no seu código:
- Clique com o botão direito na linha do recurso
- Escolha Block request domain para bloquear tudo daquele domínio
- Recarregue com as mesmas condições: Slow 4G, cache desativado
Anote o LCP antes e depois. A diferença é o custo real daquele app.
Repita para cada domínio de terceiro, um de cada vez. Bloquear vários juntos mistura os efeitos e você não sabe qual deles pesa.
Duas armadilhas dessa medição:
Meça três vezes e use a mediana. Uma única medição varia muito por condição de rede.
Verifique se a página quebrou. Se bloquear o app derrubou a renderização da página inteira, o número não é comparável — você mediu outra coisa.
Onde ver o LCP: na aba Lighthouse, ou na aba Performance com a marcação de LCP no gráfico, ou no painel de Web Vitals do próprio Chrome.
Passo 4 — Decida com a tabela na mão
Com os números levantados, cada app cai em uma de três decisões:
Manter
O app custa pouco, é usado de verdade e faz algo que você não reconstruiria com facilidade.
Gateway de pagamento, plataforma de e-mail, ferramenta de suporte que a equipe usa diariamente. Custo justificado.
Substituir por código próprio
O app custa caro, mas você só usa uma fração do que ele faz.
Foi o meu caso com as avaliações. O app entregava foto de cliente, moderação em fila, e-mail automático e resposta do lojista. Eu usava exibição de estrelas e nada mais. Substituí por um sistema próprio em JSON estático, que custa 14 KB e uma requisição.
O critério: se você usa menos de um terço dos recursos e o custo é alto, provavelmente compensa.
Remover
O app custa caro e você não usa.
Essa categoria é maior do que a maioria dos lojistas imagina. Popup instalado numa campanha de ano passado, ferramenta de review que nunca configurou, app de frete que foi substituído mas nunca desinstalado.
Antes de considerar a auditoria terminada, olhe também o inverso: apps desinstalados que deixaram código no tema.
A tentativa que não funciona
Existe uma correção que parece resolver e não resolve: sobrescrever o app com o seu próprio CSS.
O raciocínio é tentador. O app carrega uma fonte que você não quer? Escreva uma regra forçando outra família. O app tem um estilo feio? Sobrescreva.
O problema é que isso muda o que aparece, não o que é baixado. O navegador já fez a requisição, já pagou o ciclo de conexão, já gastou a banda. Você só escondeu o resultado.
Eu tentei todas as saídas antes de trocar o app:
| Tentativa | Resultado |
|---|---|
| Procurar opção no painel do app | Não existia |
| Sobrescrever a fonte por CSS | Arquivo continuava sendo baixado |
| Bloquear a requisição por JavaScript | Frágil, quebrava a renderização |
| Pedir mudança ao fornecedor | Sem previsão |
A conclusão foi que o problema não era o recurso. Era o app.
Um orçamento de milissegundos
Uma prática que ajuda a decidir sem discussão: definir um teto de custo para terceiros.
Funciona como orçamento financeiro. Você estabelece, por exemplo, que todos os scripts de terceiros somados não podem passar de 400 milissegundos em Slow 4G. Quando um app novo entra, ele precisa caber no orçamento — ou algum outro precisa sair.
Isso transforma uma discussão subjetiva ("será que esse app é pesado?") em uma conta objetiva. E evita o acúmulo silencioso, que é como quase toda loja fica lenta: nunca por uma decisão ruim, sempre por vinte decisões pequenas sem ninguém somando.
Revise o orçamento a cada três meses. Apps mudam sozinhos, e um que era leve pode ter engordado numa atualização.
Perguntas frequentes
Quantos apps são demais para uma loja?
A pergunta certa não é quantos, é quanto eles custam somados. Duas lojas com cinco apps cada podem ter situações completamente diferentes. Meça o custo total de terceiros em Slow 4G e compare com o seu orçamento de milissegundos. O número de apps é irrelevante; o tempo que eles somam é tudo.
Desinstalar o app remove o código da loja?
Nem sempre. Muitos apps injetam trecho de código diretamente no tema, e a desinstalação não limpa isso. É por isso que vale conferir a coluna Initiator procurando requisições disparadas pelo seu próprio tema para domínios que você não reconhece.
Sobrescrever o CSS do app resolve o problema de performance?
Não. Sobrescrever CSS muda o que é exibido, não o que é baixado. O arquivo já foi requisitado, a conexão já foi aberta e a banda já foi consumida. Você só escondeu o efeito visual, mantendo o custo integral de rede.
Como sei se vale substituir um app por código próprio?
Dois critérios combinados: você usa menos de um terço dos recursos que ele oferece, e o custo medido é alto. Se você usa quase tudo, reconstruir sai caro em tempo. Se o custo é baixo, não compensa o esforço mesmo usando pouco.
Preciso fazer essa auditoria com que frequência?
A cada três meses, e obrigatoriamente toda vez que instalar um app novo. Apps se atualizam sozinhos e podem ganhar peso sem aviso. Uma auditoria que era válida em janeiro pode não valer mais em maio.
O throttling em Slow 4G não é pessimista demais?
É realista para uma parte relevante do público brasileiro, principalmente fora de grandes centros. E mesmo para quem tem boa conexão, medir na condição ruim revela problemas que a conexão boa esconde. Otimizar para o pior caso melhora a experiência de todo mundo.
Resumindo
App não custa só a mensalidade. Custa milissegundos cobrados de todos os visitantes, todos os dias, e essa segunda cobrança quase nunca aparece na sua conta.
O método para descobrir é acessível e não exige ferramenta paga: liste o que cada app carrega, descubra quem pediu cada recurso pela coluna Initiator, bloqueie o domínio e compare o LCP, e decida com o número na mão.
Na maioria das auditorias aparece pelo menos um app que ninguém usa e um resíduo de app desinstalado. Só isso já costuma pagar a hora gasta na medição.
Continue lendo em Performance: