O cache HTTP e o TTL (Time To Live) são dois conceitos fundamentais do desempenho web. O cache permite armazenar temporariamente recursos (imagens, CSS, JavaScript) próximos ao utilizador, evitando que sejam descarregados novamente em cada visita. O TTL define quanto tempo um recurso pode permanecer nesse cache antes de ser considerado desatualizado. Bem configurados, estes mecanismos reduzem consideravelmente os tempos de carregamento, aliviam o servidor de origem e melhoram os Core Web Vitals, com impacto direto no SEO.
O que é o cache HTTP?
O cache HTTP é um mecanismo que permite a diferentes componentes da cadeia de entrega de uma página web conservar uma cópia local dos recursos descarregados. Quando um browser carrega uma página pela primeira vez, descarrega cada recurso a partir do servidor. Se esses recursos forem acompanhados de cabeçalhos HTTP que indicam que podem ser armazenados em cache, o browser (e/ou a CDN) guarda uma cópia. Nas visitas seguintes, o recurso é servido a partir desse cache local em vez de ser descarregado novamente do servidor, o que é significativamente mais rápido.
Existem vários níveis de cache na cadeia de entrega de um recurso web. O cache do browser armazena os recursos diretamente no dispositivo do utilizador, no disco rígido ou na memória. O cache CDN (também chamado de edge cache) armazena os recursos nos servidores da rede de distribuição geograficamente próximos dos utilizadores. O cache de servidor (reverse proxy cache, como Varnish ou Nginx) armazena os recursos ao nível do alojamento, antes mesmo de chegarem à rede.
Cache do browser
Armazenado no dispositivo do utilizador. Elimina qualquer descarregamento em visitas repetidas. TTL controlado pelos cabeçalhos HTTP.
Cache CDN
Armazenado em edge nodes geograficamente próximos. Reduz a latência para todos os utilizadores, não apenas para os visitantes recorrentes.
Cache de servidor
Armazenado ao nível do alojamento (Varnish, Nginx, Redis). Reduz a carga do servidor aplicacional e a geração dinâmica de conteúdo.
Os cabeçalhos Cache-Control: como definir o comportamento do cache
O cabeçalho HTTP Cache-Control é o principal mecanismo pelo qual um servidor comunica as suas instruções de armazenamento em cache. É enviado com cada resposta HTTP e pode conter várias diretivas combinadas. Estas são as mais importantes:
- max-age=N: o recurso pode ser armazenado em cache durante N segundos. Exemplo: max-age=31536000 = 1 ano. A diretiva mais utilizada para recursos estáticos.
- s-maxage=N: como max-age, mas aplica-se apenas a caches partilhados (CDN, reverse proxies), não ao cache do browser. Permite políticas diferentes para CDN e browser.
- no-cache: o recurso pode ser armazenado em cache, mas o cache deve sempre verificar com o servidor se ainda é válido antes de o servir (via ETag ou Last-Modified).
- no-store: o recurso nunca deve ser armazenado em cache, em lado nenhum. Usar apenas para conteúdo muito sensível (dados pessoais, transações).
- public: o recurso pode ser armazenado em cache por qualquer cache, incluindo caches CDN partilhados.
- private: o recurso só pode ser armazenado em cache pelo browser do utilizador, não por caches intermédios.
- immutable: indica que o recurso nunca mudará durante o seu tempo de vida (max-age). O browser não enviará um pedido de validação mesmo após a expiração.
Para imagens estáticas de uma loja de comércio eletrónico, a diretiva ótima é geralmente: Cache-Control: public, max-age=31536000, immutable. Esta combinação indica que a imagem pode ser armazenada em cache publicamente durante um ano e que não irá mudar. Se a imagem mudar (nova foto do produto), o URL deve mudar para contornar o cache: uma técnica conhecida como "cache busting" por versionamento de URL.
TTL (Time To Live): quanto tempo manter um recurso em cache?
O TTL (Time To Live) é a duração durante a qual um recurso em cache é considerado fresco (fresh) e pode ser servido diretamente sem verificar com o servidor de origem. É expresso em segundos no cabeçalho max-age. Passado esse período, o recurso é considerado desatualizado (stale): pode ainda ser servido em certos casos, mas o cache deve idealmente revalidá-lo.
A escolha do TTL é um equilíbrio entre dois objetivos contraditórios: maximizar a utilização do cache (TTL longo = menos pedidos ao servidor) e garantir que os utilizadores recebam conteúdo atualizado (TTL curto = as alterações propagam-se rapidamente). Para recursos que raramente mudam, como imagens de produto, um TTL longo (1 ano) é ótimo. Para recursos que mudam frequentemente, como preços ou stocks, é necessário um TTL curto ou nulo.
- 1 ano (31 536 000 segundos): imagens de produto, CSS/JS versionados, fontes web — recursos estáveis com versionamento de URL
- 1 mês (2 592 000 segundos): imagens de marca ou de categoria atualizadas ocasionalmente
- 1 hora a 1 dia: conteúdo semidinâmico, páginas de categoria, listagens de produtos
- 0 ou no-store: páginas de carrinho, páginas de pagamento, dados de utilizador autenticado — nunca armazenar em cache
Invalidação do cache: como gerir as alterações de conteúdo
O armazenamento em cache a longo prazo levanta uma questão óbvia: o que acontece quando o conteúdo muda? Se uma imagem estiver em cache durante 1 ano mas for alterada após 2 meses, os visitantes continuarão a ver a versão antiga durante 10 meses. É aqui que entram as estratégias de invalidação de cache.
A estratégia mais fiável é o versionamento de URL (URL versioning ou cache busting). O princípio: o URL do recurso inclui um identificador único que muda sempre que o recurso muda. Por exemplo, /images/produto-sapato-v2.webp em vez de /images/produto-sapato.webp. Ou através de um parâmetro: /images/produto.jpg?v=1705234567. Quando a imagem muda, o URL muda, e o cache trata esse novo URL como um recurso completamente novo, sem problemas de conteúdo desatualizado.
Outra estratégia é a API de purge CDN: as CDN modernas expõem uma API que permite invalidar imediatamente URLs específicos ou grupos de URLs no seu cache. Quando um comerciante altera uma imagem no painel de administração, uma chamada API à CDN invalida o cache para essa imagem. As visitas seguintes obtêm a nova versão diretamente do servidor de origem, que é depois armazenada novamente em cache.
Cache CDN vs cache do browser: complementaridade e diferenças
O cache CDN e o cache do browser são complementares e servem objetivos diferentes. O cache CDN beneficia todos os visitantes, novos e recorrentes: uma imagem em cache no nó CDN de Lisboa é servida rapidamente a qualquer visitante em Portugal, independentemente de já ter visitado a sua loja. O cache do browser beneficia apenas os visitantes recorrentes, no seu próprio dispositivo: se um utilizador já descarregou a imagem numa visita anterior, o seu browser serve-a a partir do disco local sem qualquer pedido de rede.
Na prática, os dois níveis de cache complementam-se: o cache CDN reduz a latência no primeiro carregamento de uma página (novo visitante ou cache do browser expirado), enquanto o cache do browser elimina completamente a rede nas visitas repetidas no mesmo dispositivo. Um recurso com max-age=31536000 só necessitará de um pedido de rede uma vez por ano e por dispositivo, um ganho de desempenho muito significativo para os visitantes fiéis.
ETag e Last-Modified: a validação condicional do cache
Mesmo com um TTL expirado, o browser não é obrigado a descarregar novamente um recurso do zero. Pode enviar um pedido condicional para verificar se o recurso mudou: se não mudou, o servidor responde com o código HTTP 304 (Not Modified) sem corpo de resposta, poupando largura de banda e confirmando a atualidade do recurso em cache.
O ETag (Entity Tag) é um identificador único gerado pelo servidor para uma versão específica de um recurso, tipicamente um hash do conteúdo do ficheiro. Quando o browser faz um pedido condicional, envia o ETag da sua versão em cache no cabeçalho If-None-Match. Se o servidor tiver o mesmo ETag (o recurso não mudou), responde com 304; caso contrário, envia a nova versão com um novo ETag.
O cabeçalho Last-Modified funciona de forma semelhante: o servidor indica a data da última modificação do recurso, e o browser envia-o em If-Modified-Since nos pedidos condicionais. Estes mecanismos de validação permitem manter o cache atualizado sem desperdiçar largura de banda quando o conteúdo não mudou.
Como o Lexiik gere o cache e a invalidação automaticamente
O Lexiik implementa uma estratégia de cache ótima para imagens de lojas PrestaShop, resolvendo automaticamente o problema de invalidação que normalmente torna o armazenamento a longo prazo arriscado. Cada imagem carregada no Cloudflare R2 recebe os cabeçalhos Cache-Control: public, max-age=31536000, immutable, o que significa um ano de cache em todos os edge nodes do Cloudflare e nos browsers dos visitantes.
O problema da invalidação é gerido automaticamente pelo Lexiik através de dois mecanismos. Em primeiro lugar, o versionamento de URL: as imagens servidas pelo Lexiik CDN utilizam identificadores nos seus URLs que mudam automaticamente quando a imagem é alterada no painel de administração do PrestaShop. Em segundo lugar, as chamadas automáticas à API de purge do Cloudflare: quando uma imagem muda, o Lexiik envia um pedido de purge ao Cloudflare para invalidar imediatamente o cache CDN dessa imagem específica, sem afetar as outras. Os visitantes recebem a nova imagem na sua próxima visita, sem ver nunca uma versão desatualizada.
Zero imagens desatualizadas, zero configuração manual
Por que um cache de longo prazo melhora o SEO
Um TTL de um ano nas imagens de produto melhora o SEO através de vários mecanismos diretos e indiretos. Diretamente, as imagens carregadas a partir do cache (CDN ou browser) aparecem em dezenas ou centenas de milissegundos, contra vários segundos para um descarregamento de rede completo. Isto melhora o LCP, a métrica Core Web Vital mais ligada às imagens, e pode levar uma página de uma pontuação «Fraca» para «Boa» segundo os limiares do Google.
Indiretamente, um cache eficaz reduz o número de pedidos HTTP enviados ao seu servidor de origem. Menos carga no servidor = melhor TTFB (Time To First Byte) para o conteúdo HTML dinâmico gerado pelo seu PrestaShop. O Google recomenda um TTFB inferior a 200 ms; um servidor sobrecarregado com pedidos de imagens pode ter um TTFB degradado que afeta todas as métricas de desempenho.
Por fim, para os visitantes recorrentes, que são frequentemente os mais propensos a converter, um cache do browser bem configurado cria uma experiência de navegação quase instantânea. As páginas de produto parecem carregar instantaneamente, com as imagens já em memória. Isto fluidifica o funil de compra e reduz os abandonos, com um impacto positivo nas métricas comportamentais que o Google pode ter em conta.
- LCP melhorado: imagens carregadas do cache local ou CDN em milissegundos
- TTFB melhorado: menos pedidos ao servidor de origem = menos carga no servidor = HTML entregue mais rapidamente
- Melhor pontuação PageSpeed: o Google Lighthouse penaliza a ausência de uma política de cache a longo prazo
- Poupança de largura de banda: menos dados transferidos = custos mais baixos e melhor desempenho em dispositivos móveis
- Melhor experiência para visitantes recorrentes: navegação quase instantânea para clientes habituais