25/06/2026
Suporte Shopify na prática: a loja estava travando 60 segundos por causa de uma fonte
Uma loja de moda australiana no Shopify carregando em mais de 60 segundos. O culpado era um arquivo de fonte de um serviço que fechou em 2021. Como diagnostiquei, o que medi antes e depois, e o que mais encontrei no caminho.
A CEO de uma marca australiana de moda me chamou com uma descrição bem vaga: "o site está lento, e os clientes não estão conseguindo efetuar compra". Loja Shopify, tema legado, faturamento real rodando em cima.
Abri o site no navegador pra medir. Não carregou. Passou de 60 segundos e o teste estourou por timeout, sem nem chegar no domContentLoaded. Não era "lento": era um site que simplesmente não terminava de abrir.
A causa era mais estranha do que parecia. E a parte útil dessa história não é o conserto (foi uma linha) e sim o caminho até achar a linha.
Primeiro: culpar o serviço é quase sempre errado
O reflexo comum quando uma loja está lenta é acusar a hospedagem / plataforma. Em Shopify isso quase nunca se sustenta, mas eu precisava provar em vez de supor.
Medi o HTML direto:
curl -s -o /dev/null -w "HTTP:%{http_code} ttfb:%{time_starttransfer}s\n" https://loja.com
# HTTP:200 ttfb:0.44s
440 milissegundos até o primeiro byte. O servidor da Shopify estava saudável. Então o travamento de 60 segundos estava acontecendo depois que o HTML chegava, ou seja: em algum recurso externo que a página pedia.
A causa raiz: uma fonte de um serviço que não existe mais
Abri o <head> do tema e listei todos os domínios de terceiros. Testei um por um. Quase todos respondiam em menos de 200ms. Um destoava:
https://cloud.typography.com/.../.../css/fonts.css
Esse arquivo respondia 302 (redirecionamento) apontando pra outro endereço:
https://...worldsecuresystems.com/...font/...css
E aí a ficha caiu. worldsecuresystems.com era o domínio do Adobe Business Catalyst, uma plataforma que a Adobe desligou em 2021. O domínio não está fora do ar temporariamente: ele foi apagado do DNS. Nem o DNS público do Google resolve.
curl -m 60 "https://...worldsecuresystems.com/...font/...css" # exit 6: Could not resolve host
O detalhe que transforma isso num travamento total: a tag era <link rel="stylesheet"> dentro do <head>. CSS nessa posição é render-blocking por especificação. O navegador se recusa a desenhar qualquer pixel enquanto não terminar de baixar aquele arquivo.
Ou seja: a loja ficava de portas fechadas esperando uma entrega de um fornecedor que faliu cinco anos atrás.
O que os números diziam
| O que testei | Resultado |
|---|---|
| Servidor Shopify (HTML) | 200, TTFB 0,44s |
| CDN da Shopify (controle de rede) | 0,08s |
| Domínio da fonte no DNS do Google | Não resolve |
O fonts.css em produção | 902ms para receber 0 bytes |
| Navegador abrindo o site | Timeout em 60s |
Naquele "902ms para 0 bytes" a página gastava quase um segundo esperando um arquivo vazio, e isso já com o DNS negativo em cache. Pra um visitante novo, o custo era o travamento inteiro.
A correção e o medo legítimo de removê-la
A correção óbvia era apagar a linha. Mas apagar uma fonte de um site de moda é o tipo de coisa que quebra a identidade visual da marca inteira, então não dá pra sair deletando.
Antes de mexer, procurei onde aquelas fontes eram usadas de fato:
grep -rniE "gotham|whitney|mercury|sentinel" assets/
Achei três lugares usando a família Gotham. E todos os três já tinham fonte reserva declarada:
font-family: "Gotham SSm A", "Gotham SSm B", gotham, Arial, sans-serif;
Essa descoberta muda tudo. Como o serviço está morto, o site já vinha renderizando com a fonte reserva. Removendo o link, a aparência não muda em nada: só para de esperar por algo que nunca chega.
Esse é o tipo de verificação que separa suporte profissional de "achei uma linha suspeita e apaguei". A remoção levou dez segundos. A confiança pra fazer a remoção levou o trabalho todo.
O antes e depois, medido
Não gosto de entregar performance por promessa. Montei as duas versões da página (com e sem a linha), servi as duas localmente na mesma máquina e mesma rede, e medi no navegador real:
| Métrica | Antes | Depois |
|---|---|---|
| First Paint | 336ms | 72ms |
| First Contentful Paint | 352ms | 88ms |
| DOMContentLoaded | 460ms | 93ms |
4x mais rápido pro conteúdo aparecer. E esses números são conservadores, porque o teste rodou com o navegador já sabendo que o domínio estava morto. Pra quem chega pela primeira vez, a diferença era entre ver a loja e desistir dela.
Numa loja de moda de luxo, isso não é métrica de vaidade. É carrinho abandonado antes da primeira foto carregar.
O que mais apareceu na auditoria
Quando você abre o <head> de um tema legado pra investigar uma coisa, sempre acha outras. Aproveitei a viagem:
Tags de hreflang quebradas. Cinco tags de idioma faziam uma substituição de texto trocando um domínio por ele mesmo (um "replace" de .com.au por .com.au), e ainda apontavam pro domínio antigo, que responde com redirecionamento de 1,5s. Isso é problema de SEO, não de velocidade, mas estava errado desde sempre.
Dois rastreadores fantasmas. O tema carregava CrazyEgg e Convert Experiments em toda página. Testei os dois:
- CrazyEgg devolvia HTTP 200 com arquivo vazio (a conta existe, mas sem plano ativo)
- Convert Experiments devolvia literalmente
{"error":true,"code":"wrongConfig-dataError"}, exatamente a mesma resposta que um ID inventado por mim
Confirmei no navegador que nenhum dos dois criava suas variáveis globais nem enviava um único dado. Ou seja: nenhum mapa de calor estava sendo gravado e nenhum teste A/B estava rodando há sabe-se lá quanto tempo. A cliente possivelmente ainda pagava por ferramentas que não funcionavam. Esse achado sozinho pode valer mais que o conserto.
O que eu decidi NÃO fazer
Essa parte é a que mais me orgulha do trabalho, e a que ninguém vê.
O tema tinha oito scripts bloqueantes no <head>, jQuery incluso. O manual mandaria colocar defer em todos e sair comemorando ganho de Lighthouse.
Fui verificar antes. Encontrei 22 arquivos do tema chamando $(...) inline, executados durante a leitura do HTML, e um document.write num snippet de cross-sell. Ambas as coisas são incompatíveis com defer: os scripts inline rodariam antes do jQuery existir e o site quebraria em produção.
Então apliquei defer só onde era comprovadamente seguro (a galeria de imagens, usada depois da renderização) e documentei o resto como refatoração separada, com escopo e risco explicados.
Por que isso é suporte Shopify e não "mexer no código"
Trabalho com Shopify desde 2016 como Shopify Partner, atendendo lojas na Austrália, Estados Unidos, Europa e Brasil. Se você quiser o contexto de como isso funciona, escrevi sobre no post de especialista Shopify no Brasil.
O que esse caso mostra bem é a diferença entre suporte de verdade e troca de linha:
- Diagnóstico com medição, não com palpite. Isolei servidor, rede, DNS e cada terceiro antes de acusar qualquer um.
- Verificação antes de remover. Confirmei que a fonte já não carregava pra ninguém antes de apagar a linha.
- Prova de resultado. Medi antes e depois no navegador real, não mostrei estimativa.
- Escopo honesto. Falei o que não fiz, por quê, e quanto custaria fazer.
- Achados extras que viram dinheiro. As duas ferramentas mortas eram possivelmente cobrança recorrente por nada.
Tema legado de Shopify é assim: acumula dez anos de integrações, apps desinstalados pela metade, serviços que fecharam e ninguém removeu. O trabalho não é reescrever tudo. É achar o que está sangrando e parar o sangramento sem quebrar o resto.
Resumo
Se a sua loja Shopify está lenta:
- Meça o servidor primeiro. TTFB alto é problema de hospedagem. TTFB baixo com página lenta é problema de recurso externo, e a Shopify raramente é culpada.
- Audite os domínios de terceiros do
<head>. Serviços fecham. Ninguém avisa. O código continua pedindo o arquivo pra sempre. - Desconfie de CSS e fontes em
<head>. É a categoria que trava a renderização inteira, diferente de script comasync, que só atrasa. - Cheque se seus rastreadores rastreiam. Conta cancelada continua carregando o script e continua custando velocidade.
- Não aplique
deferem bloco num tema jQuery antigo sem antes procurar chamadas inline edocument.write.
Precisa de suporte Shopify?
Atendo lojas Shopify na Austrália, Estados Unidos, Europa e Brasil: suporte contínuo, auditoria de performance, customização de tema, migração e implementação do zero.
Se a sua loja está lenta, com comportamento estranho, ou você só quer uma segunda opinião técnica sobre o que tem dentro do seu tema, me chama.
Referências
- Shopify.dev. Theme performance best practices
- web.dev. Render blocking resources
- Adobe. Business Catalyst end of life
- MDN. Largest Contentful Paint (LCP)
- MDN.
<script>: the defer and async attributes