Shopify acelera lojas Liquid: páginas começam a carregar até 29% mais depressa

A velocidade de uma loja online não depende apenas da quantidade de código, imagens ou aplicações instaladas. Também depende da forma como o servidor entrega a página ao navegador. Em setembro de 2026, a Shopify anunciou uma alteração importante na infraestrutura das lojas baseadas em Liquid: o HTML pode agora começar a ser enviado para o navegador antes de todo o template terminar de ser processado.

Segundo dados divulgados pela própria Shopify, esta alteração permitiu reduzir o Time to First Byte (TTFB) em cerca de 29% no percentil 75 para a loja mediana, enquanto no percentil 90 a melhoria foi de aproximadamente 21%. Também foram registadas melhorias entre 2% e 6% no First Contentful Paint (FCP) e no Largest Contentful Paint (LCP).

Para comerciantes Shopify, há ainda uma vantagem particularmente relevante: a melhoria foi introduzida ao nível da plataforma e, nas páginas elegíveis, não exige qualquer alteração para começar a beneficiar do novo mecanismo. No entanto, a estrutura do tema continua a ter um papel determinante na velocidade que o utilizador efetivamente sente.

O que mudou no carregamento das lojas Shopify?

Tradicionalmente, quando uma página Liquid era solicitada, a Shopify processava o documento e o navegador aguardava pela resposta antes de poder começar a interpretar elementos importantes da página. Isto significava que recursos necessários para apresentar o conteúdo, como folhas de estilo ou fontes, podiam começar a ser descarregados apenas depois de uma parte significativa do processamento estar concluída.

Com a nova abordagem, a Shopify processa o conteúdo do layout existente até {{ content_for_header }} e envia essa primeira parte para o navegador assim que possível. O restante HTML é enviado posteriormente no mesmo fluxo, assim que o template termina de ser processado.

Na prática, servidor e navegador passam a trabalhar mais em paralelo. Enquanto a Shopify continua a processar o template, o navegador já pode interpretar a primeira parte do documento, estabelecer ligações e começar a descarregar determinados recursos.

É importante perceber que isto não significa que o HTML final seja diferente. Quando as diferentes partes são reunidas, o documento continua a ser o mesmo. O que muda é o momento em que o navegador começa a receber e a processar informação útil.

Porque é que esta alteração pode melhorar a experiência do utilizador?

Num e-commerce, cada intervalo de espera pode influenciar a perceção de qualidade da experiência. Quando o navegador recebe mais cedo referências para CSS, fontes e outros recursos necessários à primeira apresentação da página, pode começar a trabalhar antes de o servidor terminar todo o processamento.

É precisamente por isso que a melhoria do TTFB deve ser analisada em conjunto com métricas visuais. O FCP indica quando o utilizador começa a ver conteúdo, enquanto o LCP está associado ao momento em que um dos principais elementos visíveis da página é apresentado.

A Shopify registou melhorias mais moderadas nestas duas métricas, entre 2% e 6%, mas são precisamente estas diferenças que podem ter impacto direto na perceção do visitante. Uma resposta mais rápida do servidor é importante, mas aquilo que realmente interessa ao comprador é quando consegue ver e utilizar a página.

Nem todas as páginas Shopify são elegíveis

A implementação não abrange ainda todas as páginas ou configurações de temas. De acordo com a documentação da Shopify, uma página é elegível quando utiliza um template JSON e quando {{ content_for_header }} está presente como uma expressão simples dentro do elemento head.

Existem, por isso, algumas limitações. Entre as situações que ainda não beneficiam deste mecanismo encontram-se:

• Páginas processadas através de templates .liquid em vez de templates JSON.

• Implementações onde {{ content_for_header }} utiliza filtros ou está dentro de condições ou blocos de captura.

• Casos em que {{ content_for_header }} é colocado num snippet ou atribuído previamente a uma variável.

• Pré-visualizações de temas, a barra de pré-visualização e o editor de temas.

Isto significa também que quem pretenda analisar o impacto da alteração deverá fazê-lo sobre o tema efetivamente publicado, e não apenas através do ambiente de edição.

A estrutura do tema continua a fazer diferença

Um dos aspetos mais interessantes desta alteração é que duas lojas elegíveis podem obter resultados visuais diferentes, mesmo que ambas beneficiem de uma redução semelhante no TTFB.

A razão está na posição dos recursos críticos relativamente a {{ content_for_header }}. O navegador apenas pode começar a descarregar aquilo que já recebeu. Se uma folha de estilo fundamental estiver definida depois dessa expressão, essa referência chegará apenas na segunda parte da resposta.

Se, pelo contrário, os recursos essenciais para a primeira apresentação estiverem corretamente posicionados antes de {{ content_for_header }}, o navegador poderá iniciar o respetivo carregamento enquanto o servidor ainda está a processar o resto da página.

Os dados apresentados pela Shopify mostram esta diferença através dos temas Dawn e Horizon. Durante a implementação, ambos obtiveram melhorias semelhantes no TTFB, mas o Horizon conseguiu transformar essa vantagem numa melhoria superior do FCP e do LCP, porque uma maior quantidade de recursos necessários à apresentação inicial já podia ser processada pelo navegador.

Deve simplesmente mover tudo para cima de content_for_header?

Não. A otimização deve ser realizada com conhecimento das dependências existentes no tema. Mover recursos indiscriminadamente pode criar efeitos secundários.

Por exemplo, scripts executados antes de determinadas variáveis da Shopify estarem disponíveis podem gerar erros. Alterar a posição de uma folha de estilo também pode modificar a forma como determinadas regras CSS competem entre si.

A abordagem correta passa por identificar quais são realmente os recursos críticos para a primeira apresentação da página, analisar as respetivas dependências e só depois alterar a ordem de carregamento.

É um bom exemplo de como a performance de uma loja Shopify resulta da combinação entre melhorias realizadas pela plataforma e decisões tomadas durante o desenvolvimento do tema. Para projetos com requisitos mais exigentes, uma implementação de Shopify Plus e e-commerce avançado deve considerar estas questões desde a arquitetura inicial.

Streaming não elimina a necessidade de otimizar Liquid

Há outra distinção importante: o novo mecanismo altera quando o HTML começa a chegar ao navegador, mas não elimina o trabalho que o servidor precisa de realizar.

Um template com processamento Liquid excessivo continua a exigir tempo de processamento. Loops complexos, chamadas de renderização desnecessárias e estruturas pouco eficientes não desaparecem apenas porque a primeira parte do documento é enviada mais cedo.

Por isso, as boas práticas de Liquid continuam a ser relevantes. O objetivo deve ser trabalhar em duas frentes: permitir que o navegador comece a trabalhar o mais cedo possível e reduzir o tempo necessário para produzir a resposta completa.

Da mesma forma, se o conteúdo visível no topo da página depender de uma API externa chamada através de JavaScript, poderá ser vantajoso iniciar esse pedido antes de o DOM estar completamente pronto. Desta forma, diferentes tarefas podem decorrer em paralelo em vez de criarem uma sequência de períodos de espera.

TTFB passa a exigir uma interpretação mais cuidadosa

A introdução de streaming cria também um desafio interessante na medição da performance. Durante muito tempo, o TTFB foi utilizado como indicador aproximado do tempo necessário para o servidor começar a responder. No entanto, tecnologias como Early Hints e agora as respostas HTML progressivas tornam essa interpretação menos linear.

Com streaming, o primeiro byte pode chegar muito cedo, embora o servidor continue a processar o restante documento. Assim, um TTFB inferior não significa necessariamente que todo o processamento do servidor tenha ficado 29% mais rápido.

Para analisar o processamento Liquid, a Shopify recomenda ferramentas como o Theme Inspector for Chrome. Outra aproximação consiste em observar o intervalo entre finalResponseHeadersStart e responseEnd, embora esta medição também seja influenciada pela rede e pelo dispositivo.

Esta mudança reforça uma regra importante na análise de performance: nenhuma métrica deve ser interpretada isoladamente. TTFB, FCP, LCP e tempo total de processamento respondem a perguntas diferentes.

O que deve analisar numa loja Shopify?

A melhoria automática da infraestrutura é uma excelente base, mas não substitui uma análise técnica da loja. Para perceber se um projeto está realmente a aproveitar as capacidades atuais da plataforma, vale a pena verificar:

1. Se as páginas principais utilizam templates JSON elegíveis para streaming.

2. Onde está colocado {{ content_for_header }} no layout.

3. Que folhas de estilo, fontes e outros recursos críticos são definidos antes e depois dessa expressão.

4. Se existem scripts cuja execução depende de objetos ou variáveis disponibilizados posteriormente.

5. Quanto tempo o processamento Liquid continua a consumir.

6. Se o conteúdo acima da dobra depende de pedidos externos que começam demasiado tarde.

7. Como evoluem FCP e LCP em condições reais de utilização, e não apenas num teste isolado.

Uma análise de SEO técnico pode igualmente ajudar a identificar problemas de performance, arquitetura e implementação que condicionam a experiência de utilização e a capacidade de uma loja competir nos resultados orgânicos.

Performance continua a ser uma responsabilidade partilhada

Esta atualização demonstra uma das vantagens de trabalhar sobre uma plataforma de e-commerce com capacidade para introduzir melhorias de infraestrutura em grande escala. Uma alteração realizada pela Shopify pode produzir ganhos em milhares de lojas sem exigir que cada comerciante altere individualmente o seu código.

Mas também demonstra os limites dessa vantagem. A plataforma pode entregar o primeiro fragmento de HTML mais cedo, mas não pode transformar automaticamente um tema mal estruturado num tema de elevada performance.

A organização dos recursos, a qualidade do Liquid, as aplicações instaladas, o JavaScript utilizado, as integrações externas, as imagens e a arquitetura do tema continuam a influenciar a experiência final.

Para lojas com volumes elevados de tráfego ou operações de e-commerce mais complexas, pequenas melhorias podem acumular-se e tornar-se relevantes. É por isso que a performance deve ser tratada como um processo contínuo de medição, desenvolvimento e otimização, e não como uma intervenção realizada apenas no lançamento.

Uma loja mais rápida começa antes do primeiro byte

A nova arquitetura de streaming da Shopify permite que o navegador comece a trabalhar enquanto o servidor ainda está a processar partes da página. É uma alteração aparentemente invisível para comerciantes e consumidores, mas tecnicamente relevante para reduzir períodos em que o navegador estaria simplesmente à espera.

O passo seguinte é garantir que o tema sabe aproveitar essa vantagem. Colocar recursos críticos na posição adequada, reduzir processamento Liquid desnecessário e medir as métricas que correspondem à experiência real são agora ainda mais importantes.

Para empresas que utilizam Shopify como um canal estratégico de vendas, uma estratégia digital sólida deve considerar performance, tecnologia, experiência de utilização, SEO e conversão como partes do mesmo sistema. Afinal, uma infraestrutura mais rápida cria uma oportunidade - cabe ao tema e à implementação transformá-la numa experiência efetivamente mais rápida para quem compra.