--- title: "Suporte Shopify na prática: a loja estava travando 60 segundos por causa de uma fonte" description: "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." published: "2026-06-25" tags: ["shopify", "performance", "ecommerce", "seo"] source: "https://marciotoledo.com/blog/suporte-shopify-loja-lenta-fonte-quebrada" --- # Suporte Shopify na prática: a loja estava travando 60 segundos por causa de uma fonte 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: ```bash 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. > **TIP** > > Sempre separe "servidor lento" de "página lenta" antes de qualquer outra coisa. São problemas diferentes, com culpados diferentes. Um `curl` no HTML resolve essa dúvida em dois segundos e evita horas investigando o lugar errado. ## A causa raiz: uma fonte de um serviço que não existe mais Abri o `` 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. ```bash 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 `` dentro do ``. 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: ```bash 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: ```css 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 `` 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 ``, 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. > **WARNING** > > Otimização de performance que quebra o checkout não é otimização, é prejuízo. Em loja com faturamento rodando, "não mexi porque verifiquei que quebraria" é entrega legítima, e precisa estar no relatório com a mesma clareza do que foi feito. ## 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](/blog/shopify-expert-brasil-parceiro-shopify). O que esse caso mostra bem é a diferença entre suporte de verdade e troca de linha: 1. **Diagnóstico com medição**, não com palpite. Isolei servidor, rede, DNS e cada terceiro antes de acusar qualquer um. 1. **Verificação antes de remover.** Confirmei que a fonte já não carregava pra ninguém antes de apagar a linha. 1. **Prova de resultado.** Medi antes e depois no navegador real, não mostrei estimativa. 1. **Escopo honesto.** Falei o que não fiz, por quê, e quanto custaria fazer. 1. **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 ``.** Serviços fecham. Ninguém avisa. O código continua pedindo o arquivo pra sempre. - **Desconfie de CSS e fontes em ``.** É a categoria que trava a renderização inteira, diferente de script com `async`, que só atrasa. - **Cheque se seus rastreadores rastreiam.** Conta cancelada continua carregando o script e continua custando velocidade. - **Não aplique `defer` em bloco** num tema jQuery antigo sem antes procurar chamadas inline e `document.write`. > **NOTE** > > Esse post trata de um caso de tema legado (herdado do Timber, anterior ao Online Store 2.0). Em temas modernos como o Dawn, a maior parte desses problemas não existe por construção. Mas tem muita loja faturando alto rodando em tema de 2016, e é justamente onde esse tipo de lixo se acumula sem ninguém perceber. ## 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](https://shopify.dev/docs/storefronts/themes/best-practices/performance) - web.dev. [Render blocking resources](https://web.dev/articles/render-blocking-resources) - Adobe. [Business Catalyst end of life](https://helpx.adobe.com/br/business-catalyst/kb/business-catalyst-end-of-life.html) - MDN. [Largest Contentful Paint (LCP)](https://developer.mozilla.org/en-US/docs/Glossary/Largest_contentful_paint) - MDN. [`