Caché de páginas para Odoo: tienda y blog desde RAM o archivo – rápido para visitantes, motores de búsqueda e IA

10 de noviembre de 2026  |  Desarrollo propio  |  Odoo, rendimiento y motores de búsqueda

Un sitio web de Odoo vuelve a generar cada página en cada petición: consultas a la base de datos, plantillas, traducciones, precios. Para un solo visitante pasa inadvertido. Pero cuando los motores de búsqueda y los indexadores de IA solicitan cientos o miles de páginas en muchos idiomas, se convierte en una carga permanente, y los clientes reales tienen que esperar también. Para ello hemos desarrollado el módulo website_page_cache para Odoo 19 y lo hemos publicado en GitHub como Open Source (LGPL-3): las páginas de tienda y de blog solicitadas de forma anónima se sirven casi como contenido estático desde una caché, ya sea desde archivos o desde la memoria principal (RAM), y cada cambio – también en una traducción – elimina automáticamente de la caché las páginas afectadas.

Importante para todos los que quieren ser encontrados: el módulo no bloquea ningún motor de búsqueda ni ningún rastreador de IA. Todos los indexadores reciben los mismos contenidos que cualquier visitante, solo que más rápido. Este artículo explica cómo funciona la caché, qué aspecto tiene el panel de control (con capturas de pantalla), cómo saber si sus páginas caben en la memoria principal y cuánta RAM adicional haría falta, qué reglas de seguridad se aplican y cómo instalar el módulo.

Resumen

El problema: la carga de los rastreadores en los sitios Odoo

Odoo es un sistema ERP completo; el sitio web es uno de sus muchos módulos. Cada página que solicita un visitante o un robot recorre el mismo camino: procesar la petición, consultar la base de datos, cargar los datos de productos y precios, renderizar la plantilla QWeb, insertar las traducciones y entregar el resultado. Según la página, esto tarda algunos cientos de milisegundos y ocupa durante ese tiempo uno de los pocos procesos de trabajo.

Para los motores de búsqueda y los indexadores de IA esto es un problema permanente:

• Muchos idiomas, muchas direcciones: una página disponible en 46 idiomas son 46 direcciones distintas para un rastreador.
• Cada dirección se solicita por separado, a menudo por muchos remitentes distribuidos a la vez. Una caché de navegador clásica no ayuda, porque cada petición se refiere a una dirección nueva.
• Pocos procesos de trabajo: un servicio Odoo suele funcionar con un puñado de procesos. Si están ocupados con peticiones de rastreadores, los visitantes reales esperan en la cola.
• Mismo contenido, siempre de nuevo: un artículo de blog cambia rara vez, pero se recompone con mucho esfuerzo en cada petición.

La salida más obvia – bloquear a los rastreadores – no es una opción para una empresa que quiere ser encontrada. La visibilidad en los motores de búsqueda y en las respuestas de IA es valiosa. Es mejor servir las páginas tan rápido que la carga apenas pese. Eso es justo lo que hace la caché de páginas.

Cómo funciona la caché de páginas

El módulo se engancha a la entrada de peticiones de Odoo (ir.http). En cada petición de página decide, en una fracción de milisegundo, si la página puede salir de la caché y, en ese caso, la entrega sin base de datos, sin plantilla y sin renderizado.

1. Comprobación: solo se considera una petición GET anónima sin parámetros de búsqueda en una ruta permitida (tienda, categorías, productos, blog). Todo lo demás pasa por Odoo como siempre.
2. Clave de caché: consta de sitio web, clase de host, idioma, ruta, lista de precios, posición fiscal y estado del consentimiento de cookies. Por eso los visitantes que verían algo distinto nunca comparten una entrada. El host se normaliza: Odoo escribe las direcciones absolutas siempre con el dominio del sitio web, no con el de la petición; la dirección de la petición solo decide si la página cuenta como dirección principal (enlaces de idioma) y si debe indexarse. Por eso todos los nombres de host ajenos comparten una única entrada, junto con la indicación noindex, en lugar de ocupar cada uno una copia propia.
3. Acierto: si hay una entrada actual, se entrega. El token CSRF de la página se vuelve a establecer en cada petición. Las visitas a artículos de blog se siguen contando.
4. Fallo: si falta la entrada o está obsoleta, Odoo renderiza la página como de costumbre. Si el resultado puede almacenarse en caché (estado 200, HTML, sin cookie, sin ID de sesión en el texto), se guarda; la siguiente petición es un acierto.
5. Visible en la cabecera: cada respuesta lleva la cabecera X-Page-Cache: HIT o MISS. Así se puede comprobar con cualquier herramienta qué ha ocurrido.

¿Cuánto más rápido?

En nuestro sistema de pruebas (copia de nuestros sitios web, unos cientos de páginas) el tiempo medio de renderizado de una página fue de unos 490 milisegundos y la entrega desde la caché, de unos 23 milisegundos: aproximadamente veinte veces más rápido. Cuanto más compleja es una página, mayor es la ganancia. Además, el panel calcula a partir de ambos valores el tiempo de servidor ahorrado estimado.

Archivo o RAM: elegir la ubicación de almacenamiento

La caché conoce dos ubicaciones de almacenamiento. Ambas son visibles en común para todos los procesos de trabajo de Odoo, de modo que cada página existe una sola vez, no una vez por proceso.

Para la mayoría de las instalaciones, Automático es la elección correcta: obtiene la velocidad de la RAM cuando hay espacio y, si no, vuelve a los archivos sin intervención.

¿Cabe el sitio web en la memoria principal? ¿Y cuánta RAM falta?

Que una caché en RAM sea posible depende de tres cosas: del número de páginas, de su tamaño medio y de la memoria disponible. El panel lo calcula por usted:

• Número de páginas: por cada sitio web cuenta productos publicados, páginas de listado de la tienda, categorías, artículos de blog y listados de blog, y lo multiplica por el número de idiomas.
• Tamaño de página: en cuanto hay páginas en la caché, se mide el promedio real; hasta entonces se aplica un valor supuesto.
• Espacio para la caché: el menor valor entre el presupuesto de RAM configurado, el tamaño del tmpfs y la mitad de la memoria principal disponible. El servidor nunca debe quedarse sin memoria por culpa de la caché.
• Veredicto: «cabe con reserva», «justo», «demasiado grande» o «caché en RAM no disponible». «Cabe» se aplica cuando la necesidad es como máximo el 80 por ciento del espacio disponible.

Novedad: ¿cuánta RAM adicional haría falta?

Si la caché no cabe, se quiere saber qué hay que cambiar. Por eso el panel indica bajo el veredicto una línea concreta: «RAM adicional para una caché en RAM: aproximadamente … más de memoria principal en este servidor» – o «ninguna» si el espacio ya basta. Si en lugar del servidor es solo un ajuste el que se queda corto, debajo se indica cuál: el presupuesto de RAM del módulo o el tamaño del tmpfs (/dev/shm).

El cálculo que hay detrás es sencillo y fácil de seguir:

1. Necesidad = páginas × tamaño medio de página.
2. Con reserva = necesidad dividida entre 0,8. Este valor debe caber en el presupuesto de RAM y en el tmpfs para que el veredicto sea «cabe».
3. Memoria libre: como la caché solo puede usar como máximo la mitad de la memoria principal disponible, el servidor necesita como mínimo el doble del valor del paso 2 como memoria libremente disponible. Si falta algo, la diferencia es la RAM adicional necesaria.

El ejemplo de la imagen (12.000 páginas de 25 KB cada una) es una ayuda de cálculo, no una medición de nuestras páginas. En sitios web pequeños bastan unas pocas decenas de megabytes; los datos de ejemplo de las capturas de pantalla se conformaron con unos 13 MB.

Importante para situarlo bien: la estimación no cuenta versiones adicionales por lista de precios o por país. Quien use muchas de ellas debe prever algo de reserva. Y además: un presupuesto de RAM demasiado pequeño es el motivo más frecuente por el que el automatismo se queda en archivos – no la falta de memoria principal. En ese caso el panel muestra exactamente esa línea.

Los cambios y las traducciones limpian la caché

Una caché solo es útil si nunca entrega páginas obsoletas. Un simple límite de tiempo («descartar cada doce horas») sería demasiado burdo: un precio modificado o una errata corregida tendría que esperar hasta doce horas. Por eso el módulo trabaja según el contenido.

1. Disparadores de base de datos: en todas las tablas que pueden influir en una página (productos, variantes, imágenes, existencias, atributos, categorías, precios, impuestos, listas de precios, artículos de blog y etiquetas, datos de socios y de la empresa, vistas, activos, menús, idiomas, ajustes del sitio web) hay disparadores de PostgreSQL. Registran cada cambio en un registro de cambios.
2. Dependencias y estado de la base de datos: cada página almacenada en caché recuerda qué registros muestra y el estado de la base de datos con el que se generó.
3. Comparación: si existe una entrada de registro posterior a ese estado que afecta a alguno de esos registros, la página está obsoleta.
4. Volver a almacenar: en la siguiente petición, la página obsoleta se descarta, se renderiza de nuevo y se vuelve a guardar.

Las traducciones también están cubiertas

Odoo 19 guarda los textos traducidos en el mismo registro que el texto original (como campo JSON). Por tanto, una traducción modificada es para la base de datos un cambio de fila totalmente normal – y el disparador lo ve. Esto vale igualmente para la edición a través de la interfaz, para las importaciones, para las interfaces y para los scripts que escriben directamente en la base de datos. Una traducción automática a 46 idiomas invalida, pues, exactamente las páginas cuyo texto ha cambiado, y no más.

• Selectivo en lugar de general: un producto modificado invalida sus páginas, los listados en los que aparece y la categoría correspondiente. El resto permanece en la caché.
• Los cambios globales (plantillas, activos, idiomas, menús, impuestos, monedas) invalidan todo de una vez, porque pueden afectar a cada página.
• Los contadores quedan fuera: el contador de visitas de los artículos de blog cambia en cada visita; deliberadamente no provoca invalidación, pues de lo contrario la caché sería inútil para los artículos populares.
• Red de seguridad: además hay una antigüedad máxima por página (por defecto, 12 horas).
• Ningún error de escritura por culpa de la caché: un error dentro de un disparador se registra como advertencia y no hace fallar el guardado propiamente dicho.

Panel de control y estadísticas

Todo lo que necesita para el funcionamiento está en un solo lugar: en Odoo, en Sitio web → Informes → Caché de páginas. La sección Resumen es el panel de control (con los ajustes), la sección Historial muestra las cifras por día y sitio web.

Captura de pantalla de un sistema de pruebas con copias de nuestros sitios web; los nombres de los sitios web se han sustituido por marcadores de posición.

Ajustes

Estado y estadísticas

El estado muestra la ubicación de almacenamiento activa con su límite, el número y el tamaño de las páginas almacenadas en caché y el seguimiento de cambios: cuántos cambios se han registrado en las últimas 24 horas y cuántas tablas se vigilan. Si falta una vigilancia, el panel avisa de forma clara, porque entonces no se puede confiar en la caché. Los botones de la parte superior permiten ejecutar el mantenimiento de inmediato, vaciar la caché o comprobar los disparadores y, si es necesario, volver a crearlos.

Las estadísticas (hoy, 7 días, 30 días) incluyen:

• Desde la caché y Renderizado: aciertos y fallos, y de ahí la tasa de aciertos
• Eliminado (modificado/caducado): cuántas páginas se descartaron por cambio o caducidad
• Tiempo de renderizado y tiempo de caché: el promedio por página en comparación
• Tiempo de servidor ahorrado estimado y volumen de datos desde la caché

Cada proceso de trabajo recoge las cifras por su cuenta y las escribe una vez por minuto; las filas con más de 90 días las elimina la tarea de mantenimiento.

Historial como gráfico, tabla dinámica y lista

En Historial están disponibles los valores diarios por sitio web – como gráfico, como tabla dinámica o como lista. Así puede ver si la tasa de aciertos vuelve a subir tras un reinicio o tras un gran cambio, y qué sitio web recibe más tráfico desde la caché.

Seguridad: lo que nunca sale de la caché

Una caché de páginas nunca debe hacer que alguien vea los contenidos de otro. Por eso el módulo sigue el principio: en caso de duda, no almacenar en caché.

• Solo visitantes anónimos: quien haya iniciado sesión, tenga un carrito o aporte cualquier otro estado de sesión recibe siempre la página renderizada con normalidad.
• Solo GET sin parámetros de búsqueda: las búsquedas, filtros, ordenaciones, formularios, el carrito y el pago no se tocan.
• Solo estado 200 y HTML: las páginas de error, las redirecciones y los archivos no se guardan.
• Ningún ID de sesión en la caché: una página que contiene un ID de sesión o establece una cookie no se guarda (y se registra como advertencia).
• Token CSRF por petición: el token de la página almacenada en caché es un marcador de posición y se vuelve a insertar en cada entrega.
• Clave fina: sitio web, idioma, lista de precios, posición fiscal y consentimiento de cookies forman parte de la clave de caché; quien ve algo distinto recibe otra entrada.
• Varias bases de datos: cada base de datos tiene sus propias entradas, su propio registro y sus propias estadísticas.
• Ninguna fuga de datos: la caché está en local en el servidor (archivo o RAM). No se transmite ningún dato a terceros.

Motores de búsqueda e indexadores de IA: no se bloquea nada

Algunos operadores reaccionan a la carga de los rastreadores con bloqueos. Eso protege el servidor, pero cuesta visibilidad. El módulo elige el camino contrario:

• Mismos contenidos para todos: motores de búsqueda, indexadores de IA y visitantes reciben la misma página. No existe una «versión para rastreadores» ni detección por identificador del navegador.
• Las respuestas más rápidas ayudan a la indexación: una página que responde en 20 en lugar de 500 milisegundos carga menos el presupuesto de rastreo, y los rastreadores pueden recoger más páginas en el mismo tiempo.
• Contenidos actualizados: como los cambios invalidan las páginas al instante, los rastreadores nunca ven una versión obsoleta – importante si mantiene contenidos para la búsqueda y las respuestas de IA.
• Los datos estructurados se conservan: JSON-LD, metadatos y referencias hreflang forman parte de la página almacenada en caché; los sitemaps y los archivos no los toca la caché.

Si además quiere limitar la carga, es una decisión aparte que puede tomar conscientemente – el módulo no se la impone.

Minimizar el HTML y servirlo comprimido

La caché no solo ahorra tiempo de cálculo, sino también volumen de datos. El módulo minimiza el HTML antes de guardarlo y lo entrega comprimido cuando el navegador o el rastreador lo ofrece:

• Minimizar (parámetro website_page_cache.minify): los comentarios HTML desaparecen y el espacio en blanco se agrupa. Solo se elimina por completo donde el navegador lo ignora de todos modos, por ejemplo entre elementos de bloque. Los espacios entre elementos en línea se conservan, pre, textarea y los scripts permanecen sin cambios, y los datos estructurados (JSON-LD) se reescriben de forma compacta. Según la página, estas son entre un 10 y un 30 % más pequeñas. En la prueba con siete páginas reales, el texto, el número de elementos, la posición de todos los elementos y la captura de pantalla fueron idénticos al original. La primera entrega (MISS) está minimizada igual que todas las siguientes (HIT).
• Comprimir (parámetro website_page_cache.compress): las páginas de la caché salen con gzip (Content-Encoding: gzip, Vary: Accept-Encoding). Los grandes paquetes de activos (CSS y JavaScript, de hasta varios MB) los entrega Odoo mismo sin comprimir; el módulo los comprime una vez, guarda la copia en el disco y después la entrega directamente. Así, 2,1 MB de CSS pasaron a 0,27 MB y 4,8 MB de JavaScript a 1,1 MB. Las copias antiguas las limpia la tarea de mantenimiento.
• Tras reiniciar el equipo: la caché en RAM se conserva en los reinicios de Odoo, pero no en el reinicio del servidor. Por eso la tarea de mantenimiento la replica poco a poco en el disco (parámetro website_page_cache.persist) y la restaura al arrancar. El mismo mecanismo de siempre comprueba si una entrada restaurada sigue siendo válida: antigüedad y registro de cambios. La minimización no se vuelve a calcular.

Instalación y ajustes

1. Obtener el módulo: descargar el código fuente de GitHub y colocarlo en una ruta de addons de su 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. Así se crean el registro de cambios, los disparadores y la tarea de mantenimiento (cada 10 minutos).
3. Reiniciar el servicio para que todos los procesos de trabajo carguen el módulo.
4. Abrir el panel de control: Sitio web → Informes → Caché de páginas. Comprobar que el seguimiento de cambios esté completo y elegir la ubicación de almacenamiento (valor predeterminado: automático).
5. Comprobar: solicitar dos veces una página de tienda o de blog y mirar la cabecera X-Page-Cache: la primera vez MISS, después HIT.

Los ajustes existen como parámetros del sistema (website_page_cache.enabled, .backend, .ttl_hours, .max_mb_file, .max_mb_ram) y normalmente se gestionan en el panel de control. El módulo está traducido al alemán. Desinstalar elimina de nuevo por completo los disparadores, el registro y todas las páginas almacenadas en caché.

Consejo para la caché en RAM: el presupuesto de RAM del panel y el tamaño del tmpfs (/dev/shm, opción de montaje size=) deben ajustarse a la necesidad. La comprobación «¿Cabe en la memoria principal?» le indica ambos con valores concretos.

Límites que conviene conocer

• Breve retraso tras los cambios: el índice del registro de cambios se actualiza cada dos segundos. Hasta entonces, una página modificada todavía puede entregarse en su versión antigua.
• Los textos dependientes de las existencias se actualizan mediante los cambios de existencias y la antigüedad máxima.
• Estimación del espacio necesario: no se incluyen versiones adicionales por lista de precios o por país; prever algo de reserva.
• No sustituye a todo: la caché alivia las peticiones que puede atender. Los usuarios con sesión iniciada, las búsquedas y los formularios siguen pasando por Odoo.
• La primera petición sigue siendo lenta: tras un reinicio del servidor (RAM) o un cambio global, cada página se renderiza una vez con normalidad antes de estar en la caché.

Preguntas frecuentes

¿Qué es la caché de páginas para Odoo?

Un módulo de código abierto (website_page_cache, Odoo 19, LGPL-3) que entrega las páginas públicas de tienda y de blog a los visitantes anónimos desde una caché, en lugar de renderizarlas de nuevo en cada petición. La caché reside, a elección, en archivos o en la memoria principal.

¿Bloquea el módulo los motores de búsqueda o los rastreadores de IA?

No. Los motores de búsqueda y los indexadores de IA reciben las mismas páginas que cualquier otro visitante, solo que más rápido. No hay bloqueo, ni limitación, ni versión propia para rastreadores.

¿Se vuelven a almacenar automáticamente en caché las páginas modificadas y las traducciones?

Sí. Los disparadores de PostgreSQL notifican a un registro cada cambio en las tablas relevantes; las páginas afectadas se descartan y, en la siguiente petición, se renderizan de nuevo y se guardan. Las traducciones están cubiertas porque Odoo 19 las guarda en el mismo registro.

¿Debo elegir archivo o RAM?

Por lo general Automático: el módulo usa la RAM mientras todas las páginas quepan y, si no, recurre a los archivos. Los archivos son adecuados si la caché debe sobrevivir a los reinicios o si la RAM es escasa; la RAM es la variante más rápida.

¿Cómo sé si mi sitio web cabe en la memoria principal?

En el panel de control, en Sitio web → Informes → Caché de páginas. La sección «¿Cabe en la memoria principal?» cuenta las páginas por sitio web e idioma, mide el tamaño de página y compara la necesidad con el presupuesto de RAM, el tamaño del tmpfs y la memoria disponible.

¿Cuánta RAM adicional se necesita para una caché en RAM?

El panel la indica en una línea propia. El cálculo: necesidad = páginas × tamaño de página; con reserva de seguridad, dividido entre 0,8. Como la caché solo puede usar como máximo la mitad de la memoria disponible, el doble de eso es la memoria que debe estar libre; la diferencia es la RAM adicional. Si solo el presupuesto de RAM o el tmpfs es demasiado pequeño, el panel indica el ajuste junto con el valor objetivo.

¿Puede la caché mostrar a alguien contenidos ajenos?

No. Solo se almacenan en caché las peticiones GET anónimas sin parámetros de búsqueda. Los usuarios con sesión iniciada, los carritos, los formularios y las búsquedas nunca salen de la caché; el idioma, la lista de precios, la posición fiscal y el consentimiento de cookies forman parte de la clave.

¿Cómo desactivo la caché en una emergencia?

En el panel de control, desactive el interruptor «Activo» o ponga el parámetro del sistema website_page_cache.enabled a 0. Esto se aplica en todos los procesos de trabajo como máximo tras 30 segundos. Una desinstalación elimina además los disparadores, el registro y las páginas almacenadas en caché.

¿Cómo sé si una página ha salido de la caché?

Por la cabecera de respuesta X-Page-Cache: HIT significa desde la caché, MISS significa recién renderizada y guardada.

¿Hace el módulo que el HTML sea más pequeño y lo comprime?

Sí. Las páginas almacenadas en caché se minimizan de forma conservadora (los comentarios y el espacio en blanco superfluo desaparecen, el contenido y la presentación permanecen iguales) y, en los aciertos de caché, se entregan con gzip; los paquetes de activos se comprimen una vez y se sirven desde el disco. Ambas cosas se pueden desactivar con los parámetros website_page_cache.minify y website_page_cache.compress.

Asistencia de Biricon IT Services

¿Su sitio web Odoo responde con lentitud bajo la carga de los rastreadores, o desea hacer su tienda y su blog más rápidos y más visibles? Le apoyamos en el análisis de la carga, en la puesta en marcha de la caché de páginas, en el dimensionamiento de la memoria principal y de los procesos de trabajo y en la optimización multilingüe para motores de búsqueda de su sitio web Odoo. El código fuente del módulo lo encontrará en GitHub.

Póngase en contacto ahora

Fecha: 10 de noviembre de 2026. Los valores medidos proceden de un sistema de pruebas con datos de ejemplo y no son una garantía para otras instalaciones.