Cache delle pagine per Odoo: shop e blog da RAM o file – veloce per visitatori, motori di ricerca e IA

10 novembre 2026  |  Sviluppo interno  |  Odoo, prestazioni e motori di ricerca

Un sito web Odoo ricostruisce ogni pagina a ogni richiesta: query al database, template, traduzioni, prezzi. Per un singolo visitatore passa inosservato. Ma quando motori di ricerca e indicizzatori di IA richiamano centinaia o migliaia di pagine in molte lingue, ne nasce un carico costante e anche i clienti veri restano in attesa. Per questo abbiamo sviluppato il modulo Odoo 19 website_page_cache e lo abbiamo pubblicato su GitHub come open source (LGPL-3): le pagine di shop e blog richiamate in forma anonima vengono servite quasi in modo statico da una cache, da file oppure dalla memoria di lavoro (RAM), e ogni modifica – anche a una traduzione – rimuove automaticamente dalla cache le pagine interessate.

Importante per chi vuole essere trovato: il modulo non blocca alcun motore di ricerca né alcun crawler di IA. Tutti gli indicizzatori ricevono gli stessi contenuti di qualsiasi visitatore, solo più velocemente. Questo articolo spiega come funziona la cache, che aspetto ha la dashboard (con schermate), come capire se le vostre pagine stanno nella memoria di lavoro e quanta RAM aggiuntiva servirebbe, quali regole di sicurezza valgono e come installare il modulo.

In sintesi

Il problema: il carico dei crawler sui siti Odoo

Odoo è un sistema ERP completo, il sito web è uno dei tanti moduli. Ogni pagina richiamata da un visitatore o da un robot percorre lo stesso cammino: elaborare la richiesta, interrogare il database, caricare i dati di prodotti e prezzi, renderizzare il template QWeb, inserire le traduzioni e consegnare il risultato. A seconda della pagina ci vogliono alcune centinaia di millisecondi, durante i quali è occupato uno dei pochi processi di lavoro.

Per motori di ricerca e indicizzatori di IA è un tema permanente:

• Molte lingue, molti indirizzi: una pagina disponibile in 46 lingue corrisponde per un crawler a 46 indirizzi diversi.
• Ogni indirizzo viene richiamato singolarmente, spesso da molti mittenti distribuiti contemporaneamente. Una classica cache del browser non serve, perché ogni richiesta riguarda un nuovo indirizzo.
• Pochi processi di lavoro: un servizio Odoo di solito gira con una manciata di processi. Se sono occupati con richieste dei crawler, i visitatori veri restano in coda.
• Stesso contenuto, sempre da capo: un articolo del blog cambia raramente, ma a ogni richiesta viene ricomposto con grande dispendio.

La via d'uscita più ovvia – escludere i crawler – non è un'opzione per un'azienda che vuole essere trovata. La visibilità nei motori di ricerca e nelle risposte dell'IA ha valore. Meglio servire le pagine così in fretta che il carico quasi non conti più. È proprio ciò che fa la cache delle pagine.

Come funziona la cache delle pagine

Il modulo si aggancia all'ingresso delle richieste di Odoo (ir.http). A ogni richiesta di pagina decide in una frazione di millisecondo se la pagina può provenire dalla cache e, in tal caso, la consegna senza database, senza template e senza rendering.

1. Verifica: entra in considerazione solo una richiesta GET anonima senza parametri di ricerca su un percorso consentito (shop, categorie, prodotti, blog). Tutto il resto passa per Odoo come sempre.
2. Chiave di cache: è composta da sito web, classe di host, lingua, percorso, listino prezzi, posizione fiscale e stato del consenso ai cookie. I visitatori che vedrebbero qualcosa di diverso non condividono quindi mai una voce. L'host viene normalizzato: Odoo scrive gli indirizzi assoluti sempre dal dominio del sito web, non dalla richiesta; l'indirizzo della richiesta decide solo se la pagina vale come indirizzo principale (collegamenti di lingua) e se deve essere indicizzata. Tutti i nomi host estranei condividono perciò una sola voce insieme all'indicazione noindex, invece di occupare ciascuno una copia propria.
3. Riscontro: se esiste una voce aggiornata, viene consegnata. Il token CSRF nella pagina viene reimpostato a ogni richiesta. Le visualizzazioni degli articoli del blog continuano a essere conteggiate.
4. Mancato riscontro: se la voce manca o è obsoleta, Odoo renderizza la pagina come di consueto. Se il risultato può essere messo in cache (stato 200, HTML, nessun cookie, nessun ID di sessione nel testo), viene salvato; la richiesta successiva è un riscontro.
5. Visibile nell'header: ogni risposta porta l'header X-Page-Cache: HIT oppure MISS. Così con qualsiasi strumento si può verificare cosa è accaduto.

Quanto più veloce?

Nel nostro sistema di prova (copia dei nostri siti web, alcune centinaia di pagine) il tempo medio di rendering di una pagina era di circa 490 millisecondi, la consegna dalla cache di circa 23 millisecondi: all'incirca venti volte più veloce. Quanto più complessa è una pagina, tanto maggiore è il vantaggio. Dai due valori la dashboard calcola inoltre il tempo server risparmiato stimato.

File o RAM: scegliere la posizione di archiviazione

La cache conosce due posizioni di archiviazione. Entrambe sono visibili in comune a tutti i processi di lavoro di Odoo, perciò ogni pagina esiste una sola volta, non una volta per processo.

Per la maggior parte delle installazioni Automatica è la scelta giusta: si ottiene la velocità della RAM quando c'è spazio e altrimenti si ricade sui file senza intervento.

Il sito web sta nella memoria di lavoro? E quanta RAM manca?

La possibilità di una cache in RAM dipende da tre fattori: dal numero di pagine, dalla loro dimensione media e dalla memoria disponibile. La dashboard fa il calcolo per voi:

• Numero di pagine: per ogni sito web conta i prodotti pubblicati, le pagine elenco dello shop, le categorie, gli articoli del blog e gli elenchi del blog e moltiplica per il numero di lingue.
• Dimensione delle pagine: non appena ci sono pagine nella cache, viene misurata la media effettiva; fino ad allora vale un valore presunto.
• Spazio per la cache: il valore più piccolo tra il budget RAM impostato, la dimensione del tmpfs e la metà della memoria di lavoro disponibile. Il server non deve mai finire in carenza di memoria a causa della cache.
• Verdetto: «sta con riserva», «al limite», «troppo grande» oppure «cache RAM non disponibile». «Sta» vale quando il fabbisogno è al massimo l'80 per cento dello spazio disponibile.

Novità: quanta RAM aggiuntiva servirebbe?

Se la cache non ci sta, si vuole sapere cosa occorre cambiare. La dashboard indica perciò sotto il verdetto una riga concreta: «RAM aggiuntiva per una cache RAM: circa … di memoria di lavoro in più su questo server» – oppure «nessuna» se lo spazio basta già. Se invece del server è troppo piccola solo un'impostazione, sotto è indicato quale: il budget RAM del modulo o la dimensione del tmpfs (/dev/shm).

Il calcolo che sta dietro è semplice e comprensibile:

1. Fabbisogno = pagine × dimensione media delle pagine.
2. Con riserva = fabbisogno diviso per 0,8. Questo valore deve rientrare nel budget RAM e nel tmpfs perché il verdetto sia «sta».
3. Memoria libera: poiché la cache può usare al massimo la metà della memoria di lavoro disponibile, il server necessita almeno del doppio del valore del passaggio 2 come memoria liberamente disponibile. Se manca qualcosa, la differenza è la RAM aggiuntiva necessaria.

L'esempio nell'immagine (12.000 pagine da 25 KB ciascuna) è un aiuto al calcolo, non una misurazione delle nostre pagine. Per siti web piccoli bastano poche decine di megabyte; i dati di esempio nelle schermate si accontentavano di circa 13 MB.

Importante per inquadrare il tutto: la stima non conta versioni aggiuntive per listino prezzi o per paese. Chi ne usa molte prevede un po' di riserva. E inoltre: un budget RAM troppo piccolo è il motivo più frequente per cui l'automatismo resta sui file – non la mancanza di memoria di lavoro. In questo caso la dashboard mostra esattamente questa riga.

Modifiche e traduzioni ripuliscono la cache

Una cache è utilizzabile solo se non consegna mai pagine obsolete. Un semplice limite di tempo («scartare ogni dodici ore») sarebbe troppo grossolano: un prezzo modificato o un refuso corretto dovrebbe attendere fino a dodici ore. Il modulo lavora perciò in base al contenuto.

1. Trigger del database: su tutte le tabelle che possono influenzare una pagina (prodotti, varianti, immagini, giacenze, attributi, categorie, prezzi, imposte, listini, articoli del blog e tag, dati di partner e azienda, viste, asset, menu, lingue, impostazioni del sito web) sono presenti trigger PostgreSQL. Registrano ogni modifica in un registro delle modifiche.
2. Dipendenze e stato del database: ogni pagina in cache ricorda quali record mostra e lo stato del database con cui è stata generata.
3. Confronto: se esiste una voce di registro successiva a questo stato che riguarda uno di quei record, la pagina è obsoleta.
4. Nuova memorizzazione: alla richiesta successiva la pagina obsoleta viene scartata, renderizzata di nuovo e salvata di nuovo.

Anche le traduzioni sono coperte

Odoo 19 memorizza i testi tradotti nello stesso record del testo originale (come campo JSON). Una traduzione modificata è quindi per il database una normalissima modifica di riga – e il trigger la vede. Ciò vale allo stesso modo per la modifica tramite interfaccia, per le importazioni, per le interfacce e per gli script che scrivono direttamente nel database. Una traduzione automatica in 46 lingue invalida dunque esattamente le pagine il cui testo è cambiato, e non di più.

• Mirato anziché generalizzato: un prodotto modificato invalida le sue pagine, gli elenchi in cui compare e la categoria corrispondente. Il resto rimane nella cache.
• Le modifiche globali (template, asset, lingue, menu, imposte, valute) invalidano tutto in una volta, perché possono riguardare ogni pagina.
• I contatori restano fuori: il contatore delle visualizzazioni degli articoli del blog cambia a ogni visita; volutamente non provoca alcuna invalidazione, altrimenti la cache sarebbe inefficace per gli articoli più popolari.
• Rete di sicurezza: esiste inoltre un'età massima per pagina (di default 12 ore).
• Nessun errore di scrittura causato dalla cache: un errore all'interno di un trigger viene registrato come avviso e non fa fallire il salvataggio vero e proprio.

Dashboard e statistiche

Tutto ciò che serve per l'esercizio si trova in un unico punto: in Odoo sotto Sito web → Report → Cache delle pagine. La sezione Panoramica è la dashboard (con le impostazioni), la sezione Storico mostra i numeri per giorno e per sito web.

Schermata da un sistema di prova con copie dei nostri siti web; i nomi dei siti web sono stati sostituiti con segnaposto.

Impostazioni

Stato e statistiche

Lo stato mostra la posizione di archiviazione attiva con il relativo limite, il numero e la dimensione delle pagine in cache e il monitoraggio delle modifiche: quante modifiche sono state registrate nelle ultime 24 ore e quante tabelle sono sorvegliate. Se manca una sorveglianza, la dashboard avvisa chiaramente, perché allora non ci si può fidare della cache. I pulsanti in alto consentono di eseguire subito la manutenzione, svuotare la cache o controllare i trigger e, se necessario, ricrearli.

Le statistiche (oggi, 7 giorni, 30 giorni) contengono:

• Dalla cache e Renderizzato: riscontri e mancati riscontri, e da questi il tasso di riscontro
• Rimosso (modificato/scaduto): quante pagine sono state scartate per modifica o scadenza
• Tempo di rendering e tempo di cache: la media per pagina a confronto
• Tempo server risparmiato stimato e volume di dati dalla cache

I numeri vengono raccolti da ogni processo di lavoro per conto proprio e scritti una volta al minuto; le righe più vecchie di 90 giorni vengono eliminate dal job di manutenzione.

Storico come grafico, pivot ed elenco

Sotto Storico sono disponibili i valori giornalieri per sito web – come grafico, come tabella pivot o come elenco. Così si vede se il tasso di riscontro risale dopo un riavvio o dopo una grande modifica e quale sito web riceve più traffico dalla cache.

Sicurezza: ciò che non proviene mai dalla cache

Una cache delle pagine non deve mai portare qualcuno a vedere i contenuti di un altro. Il modulo procede quindi secondo il principio: nel dubbio non mettere in cache.

• Solo visitatori anonimi: chi è connesso, ha un carrello o porta con sé un altro stato di sessione riceve sempre la pagina renderizzata normalmente.
• Solo GET senza parametri di ricerca: ricerche, filtri, ordinamenti, moduli, carrello e cassa restano intatti.
• Solo stato 200 e HTML: pagine di errore, reindirizzamenti e file non vengono salvati.
• Nessun ID di sessione nella cache: una pagina che contiene un ID di sessione o imposta un cookie non viene salvata (e viene registrata come avviso).
• Token CSRF per richiesta: il token nella pagina in cache è un segnaposto e viene reinserito a ogni consegna.
• Chiave fine: sito web, lingua, listino prezzi, posizione fiscale e consenso ai cookie fanno parte della chiave di cache; chi vede qualcosa di diverso riceve un'altra voce.
• Più database: ogni database ha voci proprie, un proprio registro e proprie statistiche.
• Nessuna fuga di dati: la cache si trova localmente sul server (file o RAM). Non vengono trasmessi dati a terzi.

Motori di ricerca e indicizzatori di IA: non viene bloccato nulla

Alcuni gestori reagiscono al carico dei crawler con dei blocchi. Ciò protegge il server, ma costa visibilità. Il modulo sceglie la via opposta:

• Stessi contenuti per tutti: motori di ricerca, indicizzatori di IA e visitatori ricevono la stessa pagina. Non esiste una «versione per crawler» né un riconoscimento tramite identificativo del browser.
• Risposte più rapide aiutano l'indicizzazione: una pagina che risponde in 20 anziché 500 millisecondi grava meno sul crawl budget e i crawler possono acquisire più pagine nello stesso tempo.
• Contenuti aggiornati: poiché le modifiche invalidano subito le pagine, i crawler non vedono mai una versione obsoleta – importante se curate contenuti per la ricerca e le risposte dell'IA.
• I dati strutturati restano: JSON-LD, meta tag e riferimenti hreflang fanno parte della pagina in cache; sitemap e file non vengono toccati dalla cache.

Se volete inoltre limitare il carico, è una decisione separata che potete prendere consapevolmente – il modulo non ve la impone.

Minimizzare l'HTML e servirlo compresso

La cache non risparmia solo tempo di calcolo, ma anche volume di dati. Il modulo minimizza l'HTML prima di salvarlo e lo consegna compresso quando il browser o il crawler lo consente:

• Minimizzazione (parametro website_page_cache.minify): i commenti HTML vengono eliminati, gli spazi vengono riuniti. Vengono rimossi completamente solo dove il browser li ignora comunque, ad esempio tra elementi di blocco. Gli spazi tra elementi inline restano, pre, textarea e gli script rimangono invariati, i dati strutturati (JSON-LD) vengono riscritti in forma compatta. A seconda della pagina, le pagine sono più piccole del 10-30 %. Nel test con sette pagine reali, testo, numero di elementi, posizione di tutti gli elementi e schermata erano identici all'originale. La prima consegna (MISS) è minimizzata esattamente come ogni successiva (HIT).
• Compressione (parametro website_page_cache.compress): le pagine dalla cache escono tramite gzip (Content-Encoding: gzip, Vary: Accept-Encoding). I grandi pacchetti di asset (CSS e JavaScript, fino ad alcuni MB) vengono consegnati da Odoo stesso non compressi; il modulo li comprime una volta, salva la copia su disco e poi la consegna direttamente. Così 2,1 MB di CSS sono diventati 0,27 MB e 4,8 MB di JavaScript 1,1 MB. Le vecchie copie vengono ripulite dal job di manutenzione.
• Dopo il riavvio del computer: la cache RAM resta ai riavvii di Odoo, ma non al riavvio del server. Per questo il job di manutenzione la replica gradualmente su disco (parametro website_page_cache.persist) e la ripristina all'avvio. Se una voce ripristinata è ancora valida lo verifica lo stesso meccanismo di sempre: età e registro delle modifiche. La minimizzazione non viene ricalcolata.

Installazione e impostazioni

1. Ottenere il modulo: scaricare il codice sorgente da GitHub e collocarlo in un percorso addons della vostra installazione Odoo 19: github.com/Alex0176/odoo-website-page-cache
2. Installare: odoo-bin -d <Datenbank> -i website_page_cache --stop-after-init. In questo modo nascono il registro delle modifiche, i trigger e il job di manutenzione (ogni 10 minuti).
3. Riavviare il servizio, in modo che tutti i processi di lavoro carichino il modulo.
4. Aprire la dashboard: Sito web → Report → Cache delle pagine. Verificare che il monitoraggio delle modifiche sia completo e scegliere la posizione di archiviazione (predefinita: automatica).
5. Controllare: richiamare due volte una pagina dello shop o del blog e guardare l'header X-Page-Cache: la prima volta MISS, poi HIT.

Le impostazioni sono presenti come parametri di sistema (website_page_cache.enabled, .backend, .ttl_hours, .max_mb_file, .max_mb_ram) e vengono normalmente gestite nella dashboard. Il modulo è tradotto in tedesco. La disinstallazione rimuove di nuovo completamente trigger, registro e tutte le pagine in cache.

Consiglio per la cache RAM: il budget RAM nella dashboard e la dimensione del tmpfs (/dev/shm, opzione di mount size=) devono corrispondere al fabbisogno. Entrambi i valori sono indicati dal controllo «Sta nella memoria di lavoro?» con numeri concreti.

Limiti da conoscere

• Breve ritardo dopo le modifiche: l'indice del registro delle modifiche viene aggiornato ogni due secondi. Fino ad allora una pagina modificata può essere ancora consegnata nella vecchia versione.
• I testi dipendenti dalla giacenza vengono aggiornati tramite le variazioni di giacenza e l'età massima.
• Stima dello spazio necessario: le versioni aggiuntive per listino o per paese non sono incluse; prevedere un po' di riserva.
• Non sostituisce tutto: la cache alleggerisce le richieste che può servire. Utenti connessi, ricerche e moduli passano ancora per Odoo.
• La prima richiesta resta lenta: dopo un riavvio del server (RAM) o una modifica globale ogni pagina viene renderizzata normalmente una volta prima di trovarsi nella cache.

Domande frequenti

Che cos'è la cache delle pagine per Odoo?

Un modulo open source (website_page_cache, Odoo 19, LGPL-3) che consegna le pagine pubbliche di shop e blog ai visitatori anonimi da una cache invece di renderizzarle di nuovo a ogni richiesta. La cache si trova, a scelta, in file o nella memoria di lavoro.

Il modulo blocca i motori di ricerca o i crawler di IA?

No. Motori di ricerca e indicizzatori di IA ricevono le stesse pagine di qualsiasi altro visitatore, solo più velocemente. Non c'è alcun blocco, alcun rallentamento e alcuna versione dedicata ai crawler.

Le pagine modificate e le traduzioni vengono rimesse automaticamente in cache?

Sì. I trigger PostgreSQL segnalano a un registro ogni modifica delle tabelle rilevanti; le pagine interessate vengono scartate e, alla richiesta successiva, renderizzate di nuovo e salvate. Le traduzioni sono coperte perché Odoo 19 le memorizza nello stesso record.

Devo scegliere file o RAM?

Di norma Automatica: il modulo usa la RAM finché tutte le pagine ci stanno e altrimenti ripiega sui file. I file sono adatti se la cache deve sopravvivere ai riavvii o la RAM è scarsa; la RAM è la variante più veloce.

Come faccio a sapere se il mio sito web sta nella memoria di lavoro?

Nella dashboard sotto Sito web → Report → Cache delle pagine. La sezione «Sta nella memoria di lavoro?» conta le pagine per sito web e lingua, misura la dimensione delle pagine e confronta il fabbisogno con il budget RAM, la dimensione del tmpfs e la memoria disponibile.

Quanta RAM aggiuntiva serve per una cache RAM?

La dashboard la indica in una riga a parte. Il calcolo: fabbisogno = pagine × dimensione delle pagine; con riserva di sicurezza, diviso per 0,8. Poiché la cache può usare al massimo la metà della memoria disponibile, il doppio di questo valore è la memoria che deve essere libera; la differenza è la RAM aggiuntiva. Se è troppo piccolo solo il budget RAM o il tmpfs, la dashboard indica l'impostazione insieme al valore obiettivo.

La cache può mostrare a qualcuno contenuti altrui?

No. Vengono messe in cache solo richieste GET anonime senza parametri di ricerca. Utenti connessi, carrelli, moduli e ricerche non provengono mai dalla cache; lingua, listino prezzi, posizione fiscale e consenso ai cookie fanno parte della chiave.

Come disattivo la cache in caso di emergenza?

Nella dashboard disattivare l'interruttore «Attivo» oppure impostare il parametro di sistema website_page_cache.enabled su 0. Ciò vale in tutti i processi di lavoro al più tardi dopo 30 secondi. Una disinstallazione rimuove inoltre trigger, registro e pagine in cache.

Come riconosco se una pagina proviene dalla cache?

Dall'header di risposta X-Page-Cache: HIT significa dalla cache, MISS significa appena renderizzata e salvata.

Il modulo rende l'HTML più piccolo e lo comprime?

Sì. Le pagine in cache vengono minimizzate in modo prudente (commenti e spazi superflui vengono eliminati, contenuto e aspetto restano uguali) e, nei riscontri della cache, consegnate tramite gzip; i pacchetti di asset vengono compressi una volta e serviti dal disco. Entrambe le funzioni si possono disattivare con i parametri website_page_cache.minify e website_page_cache.compress.

Supporto di Biricon IT Services

Il vostro sito web Odoo reagisce con lentezza sotto il carico dei crawler, oppure volete rendere shop e blog più veloci e più visibili? Vi supportiamo nell'analisi del carico, nella configurazione della cache delle pagine, nel dimensionamento di memoria di lavoro e processi di lavoro e nell'ottimizzazione multilingue per i motori di ricerca del vostro sito web Odoo. Il codice sorgente del modulo è disponibile su GitHub.

Contattateci ora

Aggiornato al: 10 novembre 2026. I valori misurati provengono da un sistema di prova con dati di esempio e non costituiscono una garanzia per altre installazioni.