Cache de páginas para Odoo: loja e blogue a partir de RAM ou ficheiro – rápido para visitantes, motores de pesquisa e IA

10 de novembro de 2026  |  Desenvolvimento próprio  |  Odoo, desempenho e motores de pesquisa

Um site Odoo volta a gerar cada página em cada pedido: consultas à base de dados, modelos, traduções, preços. Para um único visitante isso passa despercebido. Mas quando motores de pesquisa e indexadores de IA pedem centenas ou milhares de páginas em muitos idiomas, surge uma carga permanente, e os clientes reais também ficam à espera. Desenvolvemos para isso o módulo Odoo 19 website_page_cache e publicámo-lo no GitHub como open source (LGPL-3): as páginas de loja e de blogue pedidas de forma anónima são entregues quase como conteúdo estático a partir de uma cache, ou a partir de ficheiros ou da memória principal (RAM), e cada alteração – também numa tradução – remove automaticamente da cache as páginas afetadas.

Importante para quem quer ser encontrado: o módulo não bloqueia nenhum motor de pesquisa nem nenhum rastreador de IA. Todos os indexadores recebem os mesmos conteúdos que qualquer visitante, apenas mais depressa. Este artigo explica como funciona a cache, qual o aspeto do painel (com capturas de ecrã), como reconhecer se as suas páginas cabem na memória principal e quanta RAM adicional seria necessária, que regras de segurança se aplicam e como instalar o módulo.

Resumo

O problema: a carga dos rastreadores nos sites Odoo

O Odoo é um sistema ERP completo, o site é um de muitos módulos. Cada página que um visitante ou um robô pede percorre o mesmo caminho: processar o pedido, consultar a base de dados, carregar os dados de produtos e preços, renderizar o modelo QWeb, inserir as traduções e entregar o resultado. Consoante a página, isto demora algumas centenas de milissegundos e ocupa durante esse tempo um dos poucos processos de trabalho.

Para motores de pesquisa e indexadores de IA isto é um tema permanente:

• Muitos idiomas, muitos endereços: uma página disponível em 46 idiomas são, para um rastreador, 46 endereços diferentes.
• Cada endereço é pedido individualmente, muitas vezes por muitos emissores distribuídos em simultâneo. Uma cache de navegador clássica não ajuda, porque cada pedido diz respeito a um novo endereço.
• Poucos processos de trabalho: um serviço Odoo funciona normalmente com um punhado de processos. Se estiverem ocupados com pedidos de rastreadores, os visitantes reais esperam na fila.
• Mesmo conteúdo, sempre de novo: um artigo de blogue raramente muda, mas é reconstruído com muito esforço a cada pedido.

A saída mais óbvia – bloquear os rastreadores – não é uma opção para uma empresa que quer ser encontrada. A visibilidade nos motores de pesquisa e nas respostas de IA tem valor. É melhor entregar as páginas tão depressa que a carga quase não pese. É exatamente isso que a cache de páginas faz.

Como funciona a cache de páginas

O módulo liga-se à entrada de pedidos do Odoo (ir.http). A cada pedido de página decide, numa fração de milissegundo, se a página pode vir da cache e, nesse caso, entrega-a sem base de dados, sem modelo e sem renderização.

1. Verificação: só entra em consideração um pedido GET anónimo sem parâmetros de pesquisa num caminho permitido (loja, categorias, produtos, blogue). Tudo o resto passa pelo Odoo como de costume.
2. Chave de cache: é composta por site, classe de anfitrião, idioma, caminho, lista de preços, posição fiscal e estado do consentimento de cookies. Por isso, visitantes que veriam algo diferente nunca partilham uma entrada. O anfitrião é normalizado: o Odoo escreve os endereços absolutos sempre a partir do domínio do site, não do pedido; o endereço do pedido apenas decide se a página conta como endereço principal (ligações de idioma) e se deve ser indexada. Todos os nomes de anfitrião estranhos partilham, por isso, uma única entrada, juntamente com a indicação noindex, em vez de ocuparem cada um uma cópia própria.
3. Acerto: se existir uma entrada atual, é entregue. O token CSRF na página é redefinido a cada pedido. As visualizações de artigos de blogue continuam a ser contadas.
4. Falha: se a entrada faltar ou estiver desatualizada, o Odoo renderiza a página como habitual. Se o resultado puder ficar em cache (estado 200, HTML, sem cookie, sem ID de sessão no texto), é guardado; o pedido seguinte é um acerto.
5. Visível no cabeçalho: cada resposta traz o cabeçalho X-Page-Cache: HIT ou MISS. Assim, é possível verificar com qualquer ferramenta o que aconteceu.

Quão mais rápido?

No nosso sistema de teste (cópia dos nossos sites, algumas centenas de páginas) o tempo médio de renderização de uma página foi de cerca de 490 milissegundos e a entrega a partir da cache de cerca de 23 milissegundos: aproximadamente vinte vezes mais rápido. Quanto mais complexa for uma página, maior o ganho. O painel calcula ainda, a partir dos dois valores, o tempo de servidor poupado estimado.

Ficheiro ou RAM: escolher o local de armazenamento

A cache conhece dois locais de armazenamento. Ambos são visíveis em comum para todos os processos de trabalho do Odoo, pelo que cada página existe apenas uma vez, e não uma vez por processo.

Para a maioria das instalações, Automático é a escolha certa: obtém a velocidade da RAM quando há espaço e, caso contrário, recua para ficheiros sem intervenção.

O site cabe na memória principal? E quanta RAM falta?

A possibilidade de uma cache em RAM depende de três fatores: do número de páginas, do seu tamanho médio e da memória disponível. O painel faz o cálculo por si:

• Número de páginas: por site conta os produtos publicados, as páginas de lista da loja, as categorias, os artigos de blogue e as listas de blogue e multiplica pelo número de idiomas.
• Tamanho das páginas: assim que haja páginas na cache, é medida a média real; até lá aplica-se um valor presumido.
• Espaço para a cache: o menor valor entre o orçamento de RAM definido, o tamanho do tmpfs e a metade da memória principal disponível. O servidor nunca deve ficar sem memória por causa da cache.
• Veredicto: «cabe com reserva», «justo», «demasiado grande» ou «cache em RAM indisponível». «Cabe» aplica-se quando a necessidade é, no máximo, 80 por cento do espaço disponível.

Novidade: quanta RAM adicional seria necessária?

Se a cache não couber, quer-se saber o que é preciso alterar. Por isso, o painel indica abaixo do veredicto uma linha concreta: «RAM adicional para uma cache em RAM: cerca de … mais de memória principal neste servidor» – ou «nenhuma» se o espaço já chegar. Se, em vez do servidor, for apenas uma definição a ficar pequena, é indicado abaixo qual: o orçamento de RAM do módulo ou o tamanho do tmpfs (/dev/shm).

O cálculo subjacente é simples e fácil de acompanhar:

1. Necessidade = páginas × tamanho médio das páginas.
2. Com reserva = necessidade dividida por 0,8. Este valor tem de caber no orçamento de RAM e no tmpfs para que o veredicto seja «cabe».
3. Memória livre: como a cache só pode usar, no máximo, metade da memória principal disponível, o servidor precisa de, pelo menos, o dobro do valor do passo 2 como memória livremente disponível. Se faltar algo, a diferença é a RAM adicional necessária.

O exemplo da imagem (12 000 páginas de 25 KB cada) é uma ajuda de cálculo, não uma medição das nossas páginas. Em sites pequenos bastam poucas dezenas de megabytes; os dados de exemplo das capturas de ecrã contentaram-se com cerca de 13 MB.

Importante para o enquadramento: a estimativa não conta versões adicionais por lista de preços ou por país. Quem usar muitas delas planeia alguma reserva. E ainda: um orçamento de RAM demasiado pequeno é o motivo mais frequente por que o automatismo fica nos ficheiros – não a falta de memória principal. Nesse caso, o painel mostra exatamente esta linha.

Alterações e traduções limpam a cache

Uma cache só é utilizável se nunca entregar páginas desatualizadas. Um simples limite de tempo («descartar a cada doze horas») seria demasiado grosseiro: um preço alterado ou uma gralha corrigida teria de esperar até doze horas. O módulo trabalha, por isso, com base no conteúdo.

1. Gatilhos da base de dados: em todas as tabelas que podem influenciar uma página (produtos, variantes, imagens, stock, atributos, categorias, preços, impostos, listas de preços, artigos de blogue e etiquetas, dados de parceiros e da empresa, vistas, ativos, menus, idiomas, definições do site) existem gatilhos PostgreSQL. Registam cada alteração num diário de alterações.
2. Dependências e estado da base de dados: cada página em cache memoriza que registos mostra e o estado da base de dados com que foi gerada.
3. Comparação: se existir uma entrada de diário posterior a esse estado que afete um desses registos, a página está desatualizada.
4. Voltar a pôr em cache: no pedido seguinte, a página desatualizada é descartada, renderizada de novo e guardada outra vez.

As traduções também estão cobertas

O Odoo 19 guarda os textos traduzidos no mesmo registo que o texto original (como campo JSON). Uma tradução alterada é, por isso, para a base de dados, uma alteração de linha completamente normal – e o gatilho vê-a. Isto vale igualmente para a edição através da interface, para importações, para interfaces e para scripts que escrevem diretamente na base de dados. Uma tradução automática para 46 idiomas invalida, pois, exatamente as páginas cujo texto mudou, e não mais.

• Seletivo em vez de generalizado: um produto alterado invalida as suas páginas, as listas em que aparece e a categoria correspondente. O resto permanece na cache.
• As alterações globais (modelos, ativos, idiomas, menus, impostos, moedas) invalidam tudo de uma vez, porque podem afetar todas as páginas.
• Os contadores ficam de fora: o contador de visualizações dos artigos de blogue muda a cada visita; deliberadamente não desencadeia invalidação, caso contrário a cache seria ineficaz nos artigos populares.
• Rede de segurança: existe ainda uma idade máxima por página (por omissão, 12 horas).
• Nenhum erro de escrita causado pela cache: um erro dentro de um gatilho é registado como aviso e não faz falhar a gravação propriamente dita.

Painel e estatísticas

Tudo o que precisa para a operação está num único local: no Odoo, em Site → Relatórios → Cache de páginas. A secção Visão geral é o painel (com as definições), a secção Histórico mostra os números por dia e por site.

Captura de ecrã de um sistema de teste com cópias dos nossos sites; os nomes dos sites foram substituídos por marcadores de posição.

Definições

Estado e estatísticas

O estado mostra o local de armazenamento ativo com o respetivo limite, o número e o tamanho das páginas em cache e o acompanhamento de alterações: quantas alterações foram registadas nas últimas 24 horas e quantas tabelas são monitorizadas. Se faltar uma monitorização, o painel avisa claramente, porque então não se pode confiar na cache. Os botões no topo permitem executar a manutenção de imediato, esvaziar a cache ou verificar os gatilhos e, se necessário, recriá-los.

As estatísticas (hoje, 7 dias, 30 dias) incluem:

• Da cache e Renderizado: acertos e falhas e, daí, a taxa de acertos
• Removido (alterado/expirado): quantas páginas foram descartadas por alteração ou expiração
• Tempo de renderização e tempo de cache: a média por página em comparação
• Tempo de servidor poupado estimado e volume de dados vindo da cache

Cada processo de trabalho recolhe os números por si e escreve-os uma vez por minuto; as linhas com mais de 90 dias são removidas pela tarefa de manutenção.

Histórico como gráfico, tabela dinâmica e lista

Em Histórico estão disponíveis os valores diários por site – como gráfico, como tabela dinâmica ou como lista. Assim vê se a taxa de acertos volta a subir após um reinício ou após uma grande alteração, e que site recebe mais tráfego da cache.

Segurança: o que nunca vem da cache

Uma cache de páginas nunca pode levar a que alguém veja os conteúdos de outra pessoa. O módulo segue, por isso, o princípio: em caso de dúvida, não pôr em cache.

• Apenas visitantes anónimos: quem tiver sessão iniciada, tiver um carrinho ou trouxer qualquer outro estado de sessão recebe sempre a página renderizada normalmente.
• Apenas GET sem parâmetros de pesquisa: pesquisas, filtros, ordenações, formulários, carrinho e caixa ficam intocados.
• Apenas estado 200 e HTML: páginas de erro, redirecionamentos e ficheiros não são guardados.
• Nenhum ID de sessão na cache: uma página que contenha um ID de sessão ou defina um cookie não é guardada (e é registada como aviso).
• Token CSRF por pedido: o token na página em cache é um marcador de posição e é inserido de novo a cada entrega.
• Chave fina: site, idioma, lista de preços, posição fiscal e consentimento de cookies fazem parte da chave de cache; quem vê algo diferente recebe outra entrada.
• Várias bases de dados: cada base de dados tem entradas próprias, um diário próprio e estatísticas próprias.
• Nenhuma fuga de dados: a cache fica localmente no servidor (ficheiro ou RAM). Não são transmitidos dados a terceiros.

Motores de pesquisa e indexadores de IA: nada é bloqueado

Alguns operadores reagem à carga dos rastreadores com bloqueios. Isso protege o servidor, mas custa visibilidade. O módulo escolhe o caminho inverso:

• Os mesmos conteúdos para todos: motores de pesquisa, indexadores de IA e visitantes recebem a mesma página. Não existe uma «versão para rastreadores» nem deteção por identificador do navegador.
• Respostas mais rápidas ajudam a indexação: uma página que responde em 20 em vez de 500 milissegundos pesa menos no orçamento de rastreio, e os rastreadores podem captar mais páginas no mesmo tempo.
• Conteúdos atuais: como as alterações invalidam logo as páginas, os rastreadores nunca veem uma versão desatualizada – importante se mantém conteúdos para a pesquisa e as respostas de IA.
• Os dados estruturados mantêm-se: JSON-LD, metadados e referências hreflang fazem parte da página em cache; mapas do site e ficheiros não são tocados pela cache.

Se quiser, além disso, limitar a carga, essa é uma decisão separada que pode tomar conscientemente – o módulo não a impõe.

Minimizar o HTML e entregá-lo comprimido

A cache não poupa apenas tempo de cálculo, mas também volume de dados. O módulo minimiza o HTML antes de o guardar e entrega-o comprimido quando o navegador ou o rastreador o permite:

• Minimização (parâmetro website_page_cache.minify): os comentários HTML desaparecem, os espaços em branco são agrupados. Só são totalmente removidos onde o navegador os ignora de qualquer modo, por exemplo entre elementos de bloco. Os espaços entre elementos em linha mantêm-se, pre, textarea e scripts permanecem inalterados, os dados estruturados (JSON-LD) são reescritos de forma compacta. Consoante a página, ficam 10 a 30 % mais pequenas. No teste com sete páginas reais, o texto, o número de elementos, a posição de todos os elementos e a captura de ecrã foram idênticos aos do original. A primeira entrega (MISS) é minimizada tal como todas as seguintes (HIT).
• Compressão (parâmetro website_page_cache.compress): as páginas da cache saem por gzip (Content-Encoding: gzip, Vary: Accept-Encoding). Os grandes pacotes de ativos (CSS e JavaScript, até alguns MB) são entregues sem compressão pelo próprio Odoo; o módulo comprime-os uma vez, guarda a cópia no disco e depois entrega-a diretamente. Assim, 2,1 MB de CSS passaram a 0,27 MB e 4,8 MB de JavaScript a 1,1 MB. As cópias antigas são limpas pela tarefa de manutenção.
• Após um reinício do computador: a cache em RAM mantém-se nos reinícios do Odoo, mas não no reinício do servidor. Por isso, a tarefa de manutenção espelha-a gradualmente no disco (parâmetro website_page_cache.persist) e restaura-a no arranque. Se uma entrada restaurada ainda é válida é verificado pelo mesmo mecanismo de sempre: idade e diário de alterações. A minimização não é recalculada.

Instalação e definições

1. Obter o módulo: transferir o código-fonte do GitHub e colocá-lo num caminho de addons da sua instalação Odoo 19: github.com/Alex0176/odoo-website-page-cache
2. Instalar: odoo-bin -d <Datenbank> -i website_page_cache --stop-after-init. Isto cria o diário de alterações, os gatilhos e a tarefa de manutenção (a cada 10 minutos).
3. Reiniciar o serviço, para que todos os processos de trabalho carreguem o módulo.
4. Abrir o painel: Site → Relatórios → Cache de páginas. Verificar se o acompanhamento de alterações está completo e escolher o local de armazenamento (predefinição: automático).
5. Verificar: pedir duas vezes uma página da loja ou do blogue e ver o cabeçalho X-Page-Cache: da primeira vez MISS, depois HIT.

As definições existem como parâmetros do sistema (website_page_cache.enabled, .backend, .ttl_hours, .max_mb_file, .max_mb_ram) e são normalmente geridas no painel. O módulo está traduzido para alemão. Desinstalar remove novamente por completo os gatilhos, o diário e todas as páginas em cache.

Dica para a cache em RAM: o orçamento de RAM no painel e o tamanho do tmpfs (/dev/shm, opção de montagem size=) têm de corresponder à necessidade. A verificação «Cabe na memória principal?» indica-lhe ambos com valores concretos.

Limites que deve conhecer

• Pequeno atraso após alterações: o índice do diário de alterações é atualizado a cada dois segundos. Até lá, uma página alterada ainda pode ser entregue na versão antiga.
• Textos dependentes do stock são atualizados através das alterações de stock e da idade máxima.
• Estimativa do espaço necessário: versões adicionais por lista de preços ou por país não estão incluídas; planeie alguma reserva.
• Não substitui tudo: a cache alivia os pedidos que pode servir. Utilizadores com sessão iniciada, pesquisas e formulários continuam a passar pelo Odoo.
• O primeiro pedido continua lento: após um reinício do servidor (RAM) ou uma alteração global, cada página é renderizada normalmente uma vez antes de estar na cache.

Perguntas frequentes

O que é a cache de páginas para Odoo?

Um módulo open source (website_page_cache, Odoo 19, LGPL-3) que entrega as páginas públicas de loja e de blogue a visitantes anónimos a partir de uma cache, em vez de as renderizar de novo a cada pedido. A cache fica, à escolha, em ficheiros ou na memória principal.

O módulo bloqueia motores de pesquisa ou rastreadores de IA?

Não. Motores de pesquisa e indexadores de IA recebem as mesmas páginas que qualquer outro visitante, apenas mais depressa. Não há bloqueio, nem limitação, nem versão própria para rastreadores.

As páginas alteradas e as traduções voltam a ficar automaticamente em cache?

Sim. Os gatilhos PostgreSQL comunicam a um diário cada alteração das tabelas relevantes; as páginas afetadas são descartadas e, no pedido seguinte, renderizadas de novo e guardadas. As traduções estão cobertas porque o Odoo 19 as guarda no mesmo registo.

Devo escolher ficheiro ou RAM?

Em regra Automático: o módulo usa a RAM enquanto todas as páginas couberem e, caso contrário, recorre a ficheiros. Os ficheiros são indicados se a cache deve sobreviver a reinícios ou se a RAM for escassa; a RAM é a variante mais rápida.

Como sei se o meu site cabe na memória principal?

No painel, em Site → Relatórios → Cache de páginas. A secção «Cabe na memória principal?» conta as páginas por site e idioma, mede o tamanho das páginas e compara a necessidade com o orçamento de RAM, o tamanho do tmpfs e a memória disponível.

Quanta RAM adicional é necessária para uma cache em RAM?

O painel indica-o numa linha própria. O cálculo: necessidade = páginas × tamanho das páginas; com reserva de segurança, dividido por 0,8. Como a cache só pode usar, no máximo, metade da memória disponível, o dobro disso é a memória que tem de estar livre; a diferença é a RAM adicional. Se apenas o orçamento de RAM ou o tmpfs for demasiado pequeno, o painel indica a definição com o valor-alvo.

A cache pode mostrar a alguém conteúdos alheios?

Não. Só ficam em cache pedidos GET anónimos sem parâmetros de pesquisa. Utilizadores com sessão iniciada, carrinhos, formulários e pesquisas nunca vêm da cache; idioma, lista de preços, posição fiscal e consentimento de cookies fazem parte da chave.

Como desligo a cache numa emergência?

No painel, desligue o interruptor «Ativo» ou defina o parâmetro do sistema website_page_cache.enabled como 0. Isto aplica-se em todos os processos de trabalho no máximo após 30 segundos. Uma desinstalação remove ainda os gatilhos, o diário e as páginas em cache.

Como reconheço se uma página veio da cache?

Pelo cabeçalho de resposta X-Page-Cache: HIT significa vinda da cache, MISS significa renderizada de novo e guardada.

O módulo torna o HTML mais pequeno e comprime-o?

Sim. As páginas em cache são minimizadas de forma conservadora (comentários e espaços em branco supérfluos desaparecem, o conteúdo e a apresentação mantêm-se iguais) e, nos acertos de cache, entregues por gzip; os pacotes de ativos são comprimidos uma vez e servidos a partir do disco. Ambas as funções podem ser desligadas através dos parâmetros website_page_cache.minify e website_page_cache.compress.

Apoio da Biricon IT Services

O seu site Odoo reage de forma lenta sob a carga de rastreadores, ou quer tornar a sua loja e o seu blogue mais rápidos e mais visíveis? Apoiamos na análise da carga, na configuração da cache de páginas, no dimensionamento da memória principal e dos processos de trabalho e na otimização multilingue para motores de pesquisa do seu site Odoo. O código-fonte do módulo encontra-se no GitHub.

Contacte-nos agora

Data: 10 de novembro de 2026. Os valores medidos provêm de um sistema de teste com dados de exemplo e não constituem uma garantia para outras instalações.