Caché de páxinas para Odoo: tenda e blog desde RAM ou ficheiro, rápidos para visitantes, motores de busca e IA

10 de novembro de 2026  |  Desenvolvemento propio  |  Odoo, rendemento e motores de busca

Un sitio web de Odoo renderiza cada páxina de novo en cada acceso: consultas á base de datos, plantillas, traducións, prezos. Para un só visitante pasa desapercibido. Pero cando motores de busca e indexadores de IA solicitan centos ou miles de páxinas en moitos idiomas, convértese nunha carga permanente e os clientes reais ven como tamén teñen que esperar. Por iso desenvolvemos o módulo de Odoo 19 website_page_cache e publicámolo en GitHub como código aberto (LGPL-3): as páxinas de tenda e de blog solicitadas de forma anónima serven case como contido estático desde unha caché, ben desde ficheiros, ben desde a memoria de traballo (RAM), e cada cambio – tamén nunha tradución – elimina automaticamente da caché as páxinas afectadas.

Importante para quen queira ser atopado: o módulo non bloquea ningún motor de busca nin ningún rastrexador de IA. Todos os indexadores reciben os mesmos contidos que calquera visitante, só que máis rápido. Este artigo explica como funciona a caché, como é o panel de control (con capturas de pantalla), como recoñecer se as súas páxinas caben na memoria de traballo e canta RAM adicional sería necesaria, que regras de seguranza se aplican e como instalar o módulo.

Resumo

O problema: a carga dos rastrexadores nos sitios web de Odoo

Odoo é un sistema ERP completo e o sitio web é un dos seus moitos módulos. Cada páxina que solicita un visitante ou un robot segue o mesmo camiño: procesar a solicitude, consultar a base de datos, cargar os datos de produtos e prezos, renderizar a plantilla QWeb, inserir as traducións e entregar o resultado. Segundo a páxina, isto leva algúns centos de milisegundos e durante ese tempo ocupa un dos poucos procesos de traballo.

Para os motores de busca e indexadores de IA isto é un tema permanente:

• Moitos idiomas, moitos enderezos: unha páxina dispoñible en 46 idiomas son, para un rastrexador, 46 enderezos distintos.
• Cada enderezo solicítase por separado, a miúdo por moitos remitentes distribuídos ao mesmo tempo. Unha caché de navegador clásica non axuda aquí, porque cada solicitude refírese a un enderezo novo.
• Poucos procesos de traballo: un servizo Odoo funciona normalmente cun puñado de procesos. Se están ocupados con solicitudes de rastrexadores, os visitantes reais agardan na cola.
• Mesmo contido, unha e outra vez de novo: unha entrada de blog cambia poucas veces, pero reconstrúese con moito esforzo en cada acceso.

A saída máis evidente – bloquear os rastrexadores – non é unha opción para unha empresa que quere ser atopada. A visibilidade nos motores de busca e nas respostas de IA ten moito valor. É mellor servir as páxinas tan rápido que a carga case non pese. É exactamente o que fai a caché de páxinas.

Como funciona a caché de páxinas

O módulo engánchase á entrada de solicitudes de Odoo (ir.http). En cada acceso a unha páxina decide, en fraccións de milisegundo, se a páxina pode saír da caché e, de ser así, sérvea sen base de datos, sen plantilla e sen renderizado.

1. Comprobación: só se considera unha solicitude GET anónima sen parámetros de busca nunha ruta permitida (tenda, categorías, produtos, blog). Todo o demais pasa por Odoo como sempre.
2. Clave de caché: componse de sitio web, clase de host, idioma, ruta, tarifa, posición fiscal e estado do consentimento de cookies. Por iso, os visitantes que verían algo diferente nunca comparten unha entrada. O host normalízase: Odoo escribe os enderezos absolutos sempre a partir do dominio do sitio web e non da solicitude; o enderezo da solicitude só decide se a páxina vale como enderezo principal (referencias de idioma) e se debe indexarse. Por iso, todos os nomes de host alleos comparten unha única entrada, coa indicación noindex, en lugar de ocupar cada un a súa propia copia.
3. Acerto: se hai unha entrada actual, entrégase. O token CSRF da páxina establécese de novo en cada solicitude. Os accesos ás entradas de blog seguen contándose.
4. Fallo: se a entrada non existe ou está obsoleta, Odoo renderiza a páxina como de costume. Se o resultado pode almacenarse na caché (estado 200, HTML, sen cookie, sen ID de sesión no texto), gárdase; o seguinte acceso será un acerto.
5. Visible na cabeceira: cada resposta leva a cabeceira X-Page-Cache: HIT ou MISS. Así pódese comprobar con calquera ferramenta o que sucedeu.

Canto máis rápido?

No noso sistema de probas (copia dos nosos sitios web, algúns centos de páxinas), o tempo medio de renderizado dunha páxina foi de preto de 490 milisegundos e a entrega desde a caché de preto de 23 milisegundos: aproximadamente vinte veces máis rápido. Canto máis complexa é unha páxina, maior é o beneficio. Con ambos os valores, o panel de control calcula tamén o tempo de servidor aforrado, estimado.

Ficheiro ou RAM: escoller o lugar de almacenamento

A caché ten dous lugares de almacenamento. Ambos son visibles en común para todos os procesos de traballo de Odoo, polo que cada páxina existe só unha vez, non unha vez por proceso.

Para a maioría das instalacións, Automático é a opción correcta: obtén velocidade de RAM cando hai espazo e, se non, recorre aos ficheiros sen intervención.

Cabe o sitio web na memoria de traballo? E canta RAM falta?

Que sexa posible unha caché en RAM depende de tres cousas: do número de páxinas, do seu tamaño medio e da memoria dispoñible. O panel de control calcúlao por vostede:

• Número de páxinas: por sitio web conta os produtos publicados, as páxinas de lista da tenda, as categorías, as entradas de blog e as listas de blog, e multiplica pola cantidade de idiomas.
• Tamaño das páxinas: en canto hai páxinas na caché, mídese a media real; ata entón aplícase un valor supoñido.
• Espazo para a caché: o menor valor entre o orzamento de RAM configurado, o tamaño do tmpfs e a metade da memoria de traballo dispoñible. O servidor nunca debe quedar sen memoria por causa da caché.
• Veredicto: «cabe con reserva», «xusto», «demasiado grande» ou «caché en RAM non dispoñible». «Cabe» aplícase cando a necesidade é como máximo o 80 por cento do espazo dispoñible.

Novo: canta RAM adicional sería necesaria?

Se a caché non cabe, hai que saber que hai que cambiar. Por iso o panel de control indica baixo o veredicto unha liña concreta: «RAM adicional para unha caché en RAM: aproximadamente … máis de memoria de traballo neste servidor» – ou «ningunha» se o espazo xa abonda. Se en lugar do servidor só un axuste é demasiado pequeno, debaixo indícase cal: o orzamento de RAM do módulo ou o tamaño do tmpfs (/dev/shm).

O cálculo que hai detrás é sinxelo e comprensible:

1. Necesidade = páxinas × tamaño medio das páxinas.
2. Con reserva = necesidade dividida entre 0,8. Este valor debe caber no orzamento de RAM e no tmpfs para que o veredicto sexa «cabe».
3. Memoria libre: como a caché só pode usar como máximo a metade da memoria de traballo dispoñible, o servidor necesita como mínimo o dobre do valor do paso 2 como memoria libre. Se falta algo, a diferenza é a RAM adicional necesaria.

O exemplo da imaxe (12.000 páxinas de 25 KB cada unha) é unha axuda de cálculo, non unha medición das nosas páxinas. Para sitios web pequenos abondan poucas decenas de megabytes; os datos de exemplo das capturas de pantalla saíron con preto de 13 MB.

Importante para situalo: a estimación non conta versións adicionais por tarifa ou por país. Quen use moitas delas debe prever algo de reserva. E ademais: un orzamento de RAM demasiado pequeno é o motivo máis frecuente polo que a automática segue nos ficheiros – non a falta de memoria de traballo. Neste caso, o panel de control mostra precisamente esa liña.

Os cambios e as traducións limpan a caché

Unha caché só é útil se nunca entrega páxinas obsoletas. Un simple límite de tempo («descartar cada doce horas») sería demasiado tosco: un prezo cambiado ou unha errata corrixida terían que agardar ata doce horas. Por iso o módulo traballa segundo o contido.

1. Disparadores da base de datos: en todas as táboas que poden influír nunha páxina (produtos, variantes, imaxes, existencias, atributos, categorías, prezos, impostos, tarifas, entradas de blog e etiquetas, datos de socios e de empresas, vistas, activos, menús, idiomas, axustes do sitio web) hai disparadores de PostgreSQL. Rexistran cada cambio nun diario de cambios.
2. Dependencias e estado da base de datos: cada páxina almacenada na caché lembra que rexistros mostra e o estado da base de datos co que foi xerada.
3. Comparación: se hai unha entrada no diario que naceu despois deste estado e afecta a un deses rexistros, a páxina está obsoleta.
4. Volver almacenar: no seguinte acceso, a páxina obsoleta descártase, renderízase de novo e gárdase outra vez.

As traducións tamén están cubertas

Odoo 19 almacena os textos traducidos no mesmo rexistro que o texto orixinal (como campo JSON). Para a base de datos, unha tradución cambiada é, polo tanto, un cambio de fila totalmente normal – e o disparador vaina. Isto vale igualmente para a edición pola interface, para as importacións, para as interfaces e para os scripts que escriben directamente na base de datos. Unha tradución automática a 46 idiomas invalida así exactamente as páxinas cuxo texto cambiou, e non máis.

• De forma selectiva en lugar de global: un produto cambiado invalida as súas páxinas, as listas nas que aparece e a categoría correspondente. O resto permanece na caché.
• Os cambios globais (plantillas, activos, idiomas, menús, impostos, moedas) invalidan todo á vez, porque poden afectar a calquera páxina.
• Os contadores quedan fóra: o contador de accesos das entradas de blog cambia en cada visita; deliberadamente non provoca ningunha invalidación, porque doutro modo a caché non serviría de nada nas entradas populares.
• Rede de seguranza: ademais existe unha idade máxima por páxina (por defecto 12 horas).
• A caché non causa erros de escritura: un erro dentro dun disparador rexístrase como advertencia e non fai fallar o gardado propiamente dito.

Panel de control e estatísticas

Todo o que necesita para a operación está nun só lugar: en Odoo, en Sitio web → Informes → Caché de páxinas. A sección Resumo é o panel de control (cos axustes); a sección Evolución mostra as cifras por día e por sitio web.

Captura de pantalla dun sistema de probas con copias dos nosos sitios web; os nomes dos sitios web foron substituídos por marcadores de posición.

Axustes

Estado e estatísticas

O estado mostra o lugar de almacenamento activo co seu límite, o número e o tamaño das páxinas almacenadas e o seguimento de cambios: cantos cambios se rexistraron nas últimas 24 horas e cantas táboas se vixían. Se falta unha vixilancia, o panel de control avisa con claridade, porque entón non se pode confiar na caché. Os botóns da parte superior permiten executar o mantemento de inmediato, baleirar a caché ou comprobar os disparadores e, se é necesario, volver crealos.

As estatísticas (hoxe, 7 días, 30 días) conteñen:

• Desde a caché e Renderizado: acertos e fallos e, a partir deles, a taxa de acertos
• Eliminado (cambiado/caducado): cantas páxinas se descartaron por cambio ou caducidade
• Tempo de renderizado e tempo de caché: a media por páxina en comparación
• Tempo de servidor aforrado, estimado e volume de datos desde a caché

As cifras recóllenas cada proceso de traballo por separado e escríbense unha vez por minuto; as filas de máis de 90 días elimínaas o traballo de mantemento.

Evolución como gráfico, pivote e lista

En Evolución están dispoñibles os valores diarios por sitio web – como gráfico, como táboa dinámica ou como lista. Así ve se a taxa de acertos volve subir despois dun reinicio ou dun gran cambio, e que sitio web recibe máis tráfico desde a caché.

Seguranza: o que nunca sae da caché

Unha caché de páxinas nunca debe levar a que alguén vexa os contidos doutra persoa. Por iso o módulo segue o principio: na dúbida, non almacenar na caché.

• Só visitantes anónimos: quen ten a sesión iniciada, ten un carro da compra ou trae outro estado de sesión recibe sempre a páxina renderizada normalmente.
• Só GET sen parámetros de busca: as buscas, os filtros, as ordenacións, os formularios, o carro da compra e a caixa non se tocan.
• Só estado 200 e HTML: as páxinas de erro, as redireccións e os ficheiros non se almacenan.
• Sen ID de sesión na caché: unha páxina que contén un ID de sesión ou establece unha cookie non se almacena (e rexístrase como advertencia).
• Token CSRF por solicitude: o token da páxina almacenada na caché é un marcador de posición e insírese de novo en cada entrega.
• Clave fina: sitio web, idioma, tarifa, posición fiscal e consentimento de cookies forman parte da clave de caché; quen ve algo diferente recibe outra entrada.
• Varias bases de datos: cada base de datos ten as súas propias entradas, o seu propio diario e as súas propias estatísticas.
• Ningunha fuga de datos: a caché está localmente no servidor (ficheiro ou RAM). Non se transmiten datos a terceiros.

Motores de busca e indexadores de IA: non se bloquea nada

Algúns operadores reaccionan á carga dos rastrexadores con bloqueos. Iso protexe o servidor, pero custa visibilidade. O módulo escolle o camiño contrario:

• Os mesmos contidos para todos: motores de busca, indexadores de IA e visitantes reciben a mesma páxina. Non hai unha «versión para rastrexadores» propia nin detección polo identificador do navegador.
• As respostas máis rápidas axudan á indexación: unha páxina que responde en 20 en lugar de 500 milisegundos carga menos o orzamento de rastrexo, e os rastrexadores poden recoller máis páxinas no mesmo tempo.
• Contidos actuais: como os cambios invalidan as páxinas de inmediato, os rastrexadores nunca ven unha versión obsoleta – importante se coida contidos para a busca e as respostas de IA.
• Os datos estruturados consérvanse: JSON-LD, as indicacións meta e as referencias hreflang forman parte da páxina almacenada; a caché non toca os sitemaps nin os ficheiros.

Se ademais quere limitar a carga, esa é unha decisión á parte que pode tomar de forma consciente – o módulo non lla impón.

Minimizar o HTML e servilo comprimido

A caché non só aforra tempo de cálculo, senón tamén volume de datos. O módulo minimiza o HTML antes de almacenalo e sérveo comprimido se o navegador ou o rastrexador o permite:

• Minimizar (parámetro website_page_cache.minify): elimínanse os comentarios HTML e agrúpanse os espazos en branco. Elimínanse por completo só onde o navegador os ignora de todos os xeitos, por exemplo entre elementos de bloque. As distancias entre elementos en liña consérvanse, pre, textarea e os scripts permanecen sen cambios, os datos estruturados (JSON-LD) reescríbense de forma compacta. Segundo a páxina, as páxinas son entre un 10 e un 30 % máis pequenas. Na proba con sete páxinas reais, o texto, o número de elementos, a posición de todos os elementos e a captura de pantalla foron idénticos ao orixinal. A primeira entrega (MISS) está minimizada exactamente igual que todas as seguintes (HIT).
• Comprimir (parámetro website_page_cache.compress): as páxinas da caché saen por gzip (Content-Encoding: gzip, Vary: Accept-Encoding). Os grandes paquetes de activos (CSS e JavaScript, de ata algúns MB) Odoo mesmo sérvoos sen comprimir; o módulo comprímeos unha vez, garda a copia no disco e despois sérvea directamente. Así, de 2,1 MB de CSS saíron 0,27 MB e de 4,8 MB de JavaScript, 1,1 MB. As copias antigas límpaas o traballo de mantemento.
• Despois dun reinicio da máquina: a caché en RAM conservase nos reinicios de Odoo, pero non no reinicio do servidor. Por iso o traballo de mantemento espéllaa paso a paso no disco (parámetro website_page_cache.persist) e restáurea ao arrancar. Se unha entrada restaurada segue sendo válida, compróbao o mesmo mecanismo de sempre: idade e diario de cambios. A minimización non se volve calcular.

Instalación e axustes

1. Obter o módulo: descargar o código fonte de GitHub e colocalo nunha ruta de addons da súa instalación de Odoo 19: github.com/Alex0176/odoo-website-page-cache
2. Instalar: odoo-bin -d <Datenbank> -i website_page_cache --stop-after-init. Con isto créanse o diario de cambios, os disparadores e o traballo de mantemento (cada 10 minutos).
3. Reiniciar o servizo para que todos os procesos de traballo carguen o módulo.
4. Abrir o panel de control: Sitio web → Informes → Caché de páxinas. Comprobar se o seguimento de cambios está completo e escoller o lugar de almacenamento (predeterminado: automático).
5. Verificar: solicitar dúas veces unha páxina de tenda ou de blog e mirar a cabeceira X-Page-Cache: a primeira vez MISS, despois HIT.

Os axustes están como parámetros do sistema (website_page_cache.enabled, .backend, .ttl_hours, .max_mb_file, .max_mb_ram) e normalmente xestiónanse no panel de control. O módulo está traducido ao alemán. Desinstalar elimina de novo por completo os disparadores, o diario e todas as páxinas almacenadas na caché.

Consello para a caché en RAM: o orzamento de RAM do panel de control e o tamaño do tmpfs (/dev/shm, opción de montaxe size=) deben axustarse á necesidade. Ambos os dous indícaos a comprobación «Cabe na memoria de traballo?» con valores concretos.

Límites que debe coñecer

• Pequeno atraso despois dos cambios: o índice do diario de cambios actualízase cada dous segundos. Ata entón, unha páxina cambiada aínda pode entregarse na versión antiga.
• Os textos que dependen das existencias actualízanse mediante os cambios de existencias e a idade máxima.
• Estimación do espazo necesario: non se inclúen as versións adicionais por tarifa ou país; prever algo de reserva.
• Non substitúe todo: a caché alivia as solicitudes que pode atender. Os usuarios con sesión iniciada, as buscas e os formularios seguen pasando por Odoo.
• O primeiro acceso segue sendo lento: despois dun reinicio do servidor (RAM) ou dun cambio global, cada páxina renderízase unha vez normalmente antes de estar na caché.

Preguntas frecuentes

Que é a caché de páxinas para Odoo?

Un módulo de código aberto (website_page_cache, Odoo 19, LGPL-3) que serve as páxinas públicas de tenda e de blog aos visitantes anónimos desde unha caché en lugar de renderizalas de novo en cada acceso. A caché está, á escolla, en ficheiros ou na memoria de traballo.

Bloquea o módulo os motores de busca ou os rastrexadores de IA?

Non. Os motores de busca e os indexadores de IA reciben as mesmas páxinas que calquera outro visitante, só que máis rápido. Non hai bloqueo, nin limitación, nin versión propia para rastrexadores.

As páxinas e as traducións cambiadas volven almacenarse automaticamente na caché?

Si. Os disparadores de PostgreSQL notifican a un diario cada cambio nas táboas relevantes; as páxinas afectadas descártanse e no seguinte acceso renderízanse de novo e gárdanse. As traducións están cubertas porque Odoo 19 as almacena no mesmo rexistro.

Debo escoller ficheiro ou RAM?

Normalmente Automático: o módulo usa a RAM mentres todas as páxinas caiban e, se non, recorre aos ficheiros. Os ficheiros son axeitados se a caché debe sobrevivir aos reinicios ou se a RAM é escasa; a RAM é a variante máis rápida.

Como sei se o meu sitio web cabe na memoria de traballo?

No panel de control, en Sitio web → Informes → Caché de páxinas. A sección «Cabe na memoria de traballo?» conta as páxinas por sitio web e idioma, mide o tamaño das páxinas e compara a necesidade co orzamento de RAM, o tamaño do tmpfs e a memoria dispoñible.

Canta RAM adicional se necesita para unha caché en RAM?

O panel de control indícao nunha liña propia. Calcúlase así: necesidade = páxinas × tamaño das páxinas; coa reserva de seguranza, dividido entre 0,8. Como a caché só pode usar como máximo a metade da memoria dispoñible, o dobre dese valor é a memoria libre necesaria; a diferenza é a RAM adicional. Se só o orzamento de RAM ou o tmpfs é demasiado pequeno, o panel de control indica o axuste co seu valor obxectivo.

Pode a caché mostrar a alguén contidos alleos?

Non. Só se almacena na caché para solicitudes GET anónimas sen parámetros de busca. Os usuarios con sesión iniciada, os carros da compra, os formularios e as buscas nunca saen da caché; o idioma, a tarifa, a posición fiscal e o consentimento de cookies forman parte da clave.

Como desactivo a caché en caso de emerxencia?

No panel de control, desactive o interruptor «Activo» ou estableza o parámetro do sistema website_page_cache.enabled en 0. Isto vale en todos os procesos de traballo como máximo ao cabo de 30 segundos. Unha desinstalación elimina ademais os disparadores, o diario e as páxinas almacenadas na caché.

Como recoñezo se unha páxina saíu da caché?

Pola cabeceira de resposta X-Page-Cache: HIT significa desde a caché, MISS significa renderizada de novo e almacenada.

Fai o módulo o HTML máis pequeno e cómprimeo?

Si. As páxinas almacenadas na caché minimízanse de forma conservadora (elimínanse os comentarios e o espazo en branco superfluo; o contido e a presentación seguen sendo os mesmos) e, nos acertos de caché, sérvense por gzip; os paquetes de activos comprímense unha vez e sérvense desde o disco. Ambas as cousas poden desactivarse mediante os parámetros website_page_cache.minify e website_page_cache.compress.

Asistencia de Biricon IT Services

O seu sitio web de Odoo responde con lentitude baixo a carga dos rastrexadores, ou quere que a tenda e o blog sexan máis rápidos e visibles? Axudámoslle na análise da carga, na configuración da caché de páxinas, no dimensionamento da memoria de traballo e dos procesos de traballo e na optimización multilingüe para motores de busca do seu sitio web de Odoo. O código fonte do módulo atópao en GitHub.

Poñerse en contacto agora

Data: 10 de novembro de 2026. Os valores medidos proceden dun sistema de probas con datos de exemplo e non son unha garantía para outras instalacións.