Os seus clientes veem a versão antiga da loja: cache do navegador e versionamento

Corrigiu uma falha do design no telemóvel, confirmou que se vê bem e deu o assunto por encerrado. No dia seguinte, um cliente envia-lhe uma captura de ecrã com a página desalinhada, tal como estava antes. Não consegue reproduzi-lo. Não é que o cliente esteja enganado: o navegador dele continua a usar a folha de estilos antiga que guardou da última vez que visitou a loja.

É um dos problemas mais desconcertantes de manter uma loja, porque a quem faz a alteração nunca acontece. Vamos ver porque ocorre e como evitá-lo.

Porque é que o navegador guarda os ficheiros

Para que as páginas carreguem depressa, o navegador guarda uma cópia dos ficheiros que não mudam com frequência: folhas de estilos, scripts, imagens e tipos de letra. Da próxima vez que precisa deles, usa a sua cópia em vez de os pedir ao servidor. Durante quanto tempo os guarda é decidido pelos cabeçalhos de cache que o servidor envia com cada ficheiro.

Para uma loja, que esses ficheiros fiquem guardados muito tempo é bom: menos pedidos, páginas mais rápidas, menos carga no servidor. O problema surge quando muda um deles e o seu endereço continua a ser o mesmo. O navegador não tem forma de saber que há uma versão nova e continua a usar a que tem até expirar.

Os sintomas

• Design desalinhado ou incompleto só para alguns clientes.
• Um botão que não faz nada porque o HTML é novo mas o JavaScript é o antigo (ou ao contrário).
• Erros de JavaScript na consola que no seu navegador não aparecem.
• Queixas que desaparecem sozinhas ao fim de alguns dias, quando as cópias expiram.
• O clássico «a mim funciona» do programador, que recarrega com a cache esvaziada.

Não é só o navegador

Entre o seu servidor e o cliente pode haver várias camadas que guardam cópias:

• A cache do PrestaShop de ficheiros combinados. Se tiver ativada a opção de combinar, comprimir e colocar em cache o CSS e o JS, a loja serve ficheiros gerados a partir dos seus. Se mudar um ficheiro de origem e a versão combinada não for regenerada, ninguém vê a alteração, nem mesmo o próprio.
• A cache de templates do Smarty, se tiver mudado um template.
• Uma cache de página, num módulo ou no servidor, que guarda o HTML com os endereços antigos.
• Uma CDN ou um proxy à frente da loja, com a sua própria cópia dos ficheiros.
• O navegador de cada cliente.

As quatro primeiras são controladas por si: esvaziá-las faz parte de qualquer alteração de design. A última não: não pode pedir a cada cliente que esvazie a sua cache.

A solução: que o endereço mude quando muda o ficheiro

A técnica padrão chama-se versionamento (ou cache busting). Consiste em fazer com que o endereço do ficheiro inclua algo que muda sempre que o seu conteúdo muda. Por exemplo, acrescentando um parâmetro: custom.css?v=20 passa a custom.css?v=21. Para o navegador é um endereço novo, por isso descarrega-o; e enquanto não mudar, pode continuar a guardá-lo durante todo o tempo que quiser.

Há várias formas de calcular essa marca:

• Pela data de modificação do ficheiro. Automático: sempre que guarda o ficheiro, muda. Só se descarrega de novo o que mudou.
• Pela impressão digital do conteúdo. Igualmente automático e mais preciso, mas é preciso calculá-la.
• Um número de versão global que sobe em cada publicação. Descarrega-se tudo de novo, mesmo que só tenha mudado um ficheiro.

Quando o PrestaShop combina e comprime os ficheiros, já gera nomes novos para o ficheiro combinado ao regenerá-lo. Mas nem todas as lojas usam essa opção (às vezes dá problemas com a ordem de carregamento de certos módulos) e não cobre os ficheiros carregados soltos.

Cuidado com as datas nas publicações

O versionamento por data de modificação tem uma armadilha: se carregar os ficheiros com uma ferramenta que conserva a data original (alguns programas de FTP, algumas formas de publicar ou de restaurar cópias), o ficheiro muda mas a sua data não, e a marca de versão continua a ser a mesma. Nesses casos precisa de poder forçar uma versão nova à mão depois de publicar.

E se encurtar o tempo de cache?

É a tentação quando o problema se repete: configurar o servidor para que o navegador guarde o CSS e o JS só alguns minutos, ou para que pergunte sempre se há versão nova. Funciona, mas paga-o em cada visita: mais pedidos, mais espera no telemóvel e mais carga no servidor, também para os ficheiros que não mudam durante meses. Com o versionamento pode fazer exatamente o contrário: deixar tempos de cache longos, que é o que favorece a velocidade, porque quando um ficheiro muda o seu endereço também muda.

O que convém, isso sim, é que o HTML das páginas não fique guardado muito tempo no navegador nem em camadas intermédias, porque é ele que leva os endereços com a versão. Se o HTML antigo continuar em cache, continuará a pedir os ficheiros antigos mesmo que estejam versionados.

O que fazer depois de cada alteração de design

1. Esvazie a cache do PrestaShop (templates e ficheiros combinados) em Parâmetros avançados → Desempenho.
2. Se tiver cache de página ou CDN, purgue-as.
3. Confirme que os endereços dos CSS e JS que mudou têm uma marca de versão nova (no código-fonte da página).
4. Teste num navegador com que já tivesse visitado a loja antes da alteração, sem esvaziar a sua cache: é assim que um cliente real a vê.
5. Teste no telemóvel, que costuma ter cópias mais antigas.

Como resolver no PrestaShop

O Rekire Cache Buster acrescenta uma marca de versão (?v=) a cada ficheiro CSS e JS local do front-office, para que o navegador descarregue o novo assim que muda. Tem dois modos: automático, com a versão tirada da data de modificação de cada ficheiro, ou manual, com um token único que muda o próprio utilizador. Pode ativá-lo para CSS, para JS ou para ambos, e o botão Forçar recarregamento agora obriga todos os visitantes a descarregar de novo o CSS e o JS após uma publicação, que é o que precisa se a sua forma de carregar ficheiros conservar as datas. Não mexe nos ficheiros servidos a partir de outro domínio ou CDN, nem nos que já têm a sua própria versão, e não combina nem comprime nada, por isso não altera a ordem de carregamento. Compatível com PrestaShop 1.7, 8 e 9.