Paginacache voor Odoo: shop en blog uit RAM of bestand – snel voor bezoekers, zoekmachines en AI

10 november 2026  |  Eigen ontwikkeling  |  Odoo, prestaties en zoekmachines

Een Odoo-website rendert elke pagina bij elke aanroep opnieuw: databasequery's, templates, vertalingen, prijzen. Voor één enkele bezoeker valt dat nauwelijks op. Maar wanneer zoekmachines en AI-indexeerders honderden of duizenden pagina's in veel talen ophalen, wordt het een permanente belasting en moeten echte klanten meewachten. Daarom hebben wij de Odoo 19-module website_page_cache ontwikkeld en als open source (LGPL-3) op GitHub gepubliceerd: anoniem opgevraagde shop- en blogpagina's komen vrijwel statisch uit een cache, hetzij uit bestanden, hetzij uit het werkgeheugen (RAM), en elke wijziging – ook in een vertaling – verwijdert de betrokken pagina's automatisch weer uit de cache.

Belangrijk voor iedereen die gevonden wil worden: de module blokkeert geen zoekmachine en geen AI-crawler. Alle indexeerders krijgen dezelfde inhoud als elke bezoeker, alleen sneller. Dit artikel legt uit hoe de cache werkt, hoe het dashboard eruitziet (met schermafbeeldingen), hoe u kunt zien of uw pagina's in het werkgeheugen passen en hoeveel extra RAM er nodig zou zijn, welke veiligheidsregels gelden en hoe u de module installeert.

Samenvatting

Het probleem: crawlerbelasting op Odoo-websites

Odoo is een volwaardig ERP-systeem; de website is slechts één van de vele modules. Elke pagina die een bezoeker of robot opvraagt, doorloopt dezelfde route: aanvraag verwerken, database raadplegen, product- en prijsgegevens laden, de QWeb-template renderen, vertalingen invoegen en het resultaat uitleveren. Dat duurt, afhankelijk van de pagina, enkele honderden milliseconden en bezet gedurende die tijd een van de weinige werkprocessen.

Voor zoekmachines en AI-indexeerders is dit een blijvend probleem:

• Veel talen, veel adressen: Een pagina die in 46 talen bestaat, zijn voor een crawler 46 verschillende adressen.
• Elk adres wordt afzonderlijk opgevraagd, vaak door veel gedistribueerde afzenders tegelijk. Een klassieke browsercache helpt hier niet, omdat elke aanroep een nieuw adres betreft.
• Weinig werkprocessen: Een Odoo-service draait doorgaans met een handvol processen. Zijn die bezet met crawleraanvragen, dan staan echte bezoekers in de rij.
• Dezelfde inhoud, steeds opnieuw: Een blogartikel verandert zelden, maar wordt bij elke aanroep opnieuw met veel moeite opgebouwd.

De voor de hand liggende uitweg – crawlers buitensluiten – is geen optie voor een bedrijf dat gevonden wil worden. Zichtbaarheid in zoekmachines en in AI-antwoorden is waardevol. Beter is het de pagina's zo snel uit te leveren dat de belasting nauwelijks nog meetelt. Precies dat doet de paginacache.

Zo werkt de paginacache

De module koppelt zich aan de aanvraagingang van Odoo (ir.http). Bij elke pagina-aanroep beslist zij in een fractie van een milliseconde of de pagina uit de cache mag komen, en levert die dan uit zonder database, zonder template en zonder rendering.

1. Controle: Alleen een anonieme GET-aanroep zonder zoekparameters naar een toegestaan pad (shop, categorieën, producten, blog) komt in aanmerking. Al het andere loopt zoals gewoonlijk door Odoo.
2. Cachesleutel: Deze bestaat uit website, hostklasse, taal, pad, prijslijst, fiscale positie en de status van de cookietoestemming. Bezoekers die iets anders zouden zien, delen daarom nooit een item. De host wordt daarbij genormaliseerd: Odoo schrijft absolute adressen altijd vanuit het domein van de website, niet vanuit de aanvraag; het adres van de aanvraag bepaalt alleen of de pagina als hoofdadres geldt (taalverwijzingen) en of zij geïndexeerd moet worden. Alle vreemde hostnamen delen daarom één item inclusief noindex-aanwijzing, in plaats van elk een eigen kopie in te nemen.
3. Hit: Bestaat er een actueel item, dan wordt dat uitgeleverd. Het CSRF-token in de pagina wordt daarbij per aanvraag opnieuw ingesteld. Aanroepen van blogartikelen worden nog steeds geteld.
4. Miss: Ontbreekt het item of is het verouderd, dan rendert Odoo de pagina zoals gewoonlijk. Is het resultaat cachebaar (status 200, HTML, geen cookie, geen sessie-ID in de tekst), dan wordt het opgeslagen; de volgende aanroep is een hit.
5. Zichtbaar in de header: Elk antwoord bevat de header X-Page-Cache: HIT of MISS. Zo kunt u met elk hulpmiddel controleren wat er gebeurd is.

Hoeveel sneller?

In ons testsysteem (kopie van onze websites, enkele honderden pagina's) bedroeg de gemiddelde rendertijd van een pagina ongeveer 490 milliseconden, de uitlevering uit de cache ongeveer 23 milliseconden: ruwweg twintig keer zo snel. Hoe complexer een pagina, hoe groter de winst. Uit beide waarden berekent het dashboard bovendien de geschatte bespaarde servertijd.

Bestand of RAM: opslaglocatie kiezen

De cache kent twee opslaglocaties. Beide zijn gemeenschappelijk zichtbaar voor alle Odoo-werkprocessen, dus elke pagina bestaat slechts één keer en niet één keer per proces.

Voor de meeste installaties is Automatisch de juiste keuze: u krijgt RAM-snelheid wanneer er ruimte is en valt anders zonder ingreep terug op bestanden.

Past de website in het werkgeheugen? En hoeveel RAM ontbreekt er?

Of een RAM-cache mogelijk is, hangt af van drie dingen: van het aantal pagina's, van hun gemiddelde grootte en van het beschikbare geheugen. Het dashboard rekent dit voor u uit:

• Aantal pagina's: Per website telt het gepubliceerde producten, shoplijstpagina's, categorieën, blogartikelen en bloglijsten en vermenigvuldigt dit met het aantal talen.
• Paginagrootte: Zodra er pagina's in de cache staan, wordt het werkelijke gemiddelde gemeten; tot dan geldt een aangenomen waarde.
• Ruimte voor de cache: de kleinste waarde van het ingestelde RAM-budget, de grootte van de tmpfs en de helft van het beschikbare werkgeheugen. De server mag door de cache nooit in geheugennood komen.
• Oordeel: “past met reserve”, “krap”, “te groot” of “RAM-cache niet beschikbaar”. “Past” geldt wanneer de behoefte hoogstens 80 procent van de beschikbare ruimte bedraagt.

Nieuw: Hoeveel extra RAM is er nodig?

Past de cache niet, dan wil men weten wat er moet veranderen. Het dashboard noemt daarom onder het oordeel een concrete regel: “Extra RAM voor een RAM-cache: ongeveer … meer werkgeheugen op deze server” – of “geen” als de ruimte al volstaat. Als niet de server maar slechts een instelling te klein is, staat daaronder welke: het RAM-budget van de module of de grootte van de tmpfs (/dev/shm).

De berekening erachter is eenvoudig en navolgbaar:

1. Behoefte = pagina's × gemiddelde paginagrootte.
2. Met reserve = behoefte gedeeld door 0,8. Deze waarde moet in het RAM-budget en in de tmpfs passen, zodat het oordeel “past” luidt.
3. Vrij geheugen: Omdat de cache hoogstens de helft van het beschikbare werkgeheugen mag gebruiken, heeft de server minstens het dubbele van de waarde uit stap 2 nodig als vrij beschikbaar geheugen. Ontbreekt er iets, dan is het verschil het extra benodigde RAM.

Het voorbeeld in de afbeelding (12.000 pagina's van elk 25 KB) is een rekenhulp, geen meting van onze pagina's. Bij kleine websites volstaan al enkele tientallen megabytes; de voorbeeldgegevens in de schermafbeeldingen kwamen met ongeveer 13 MB toe.

Belangrijk ter duiding: de schatting telt geen extra versies per prijslijst of land mee. Wie er veel gebruikt, plant wat reserve in. En: een te klein RAM-budget is de meest voorkomende reden waarom de automatiek bij bestanden blijft – niet te weinig werkgeheugen. Het dashboard toont in dat geval precies deze regel.

Wijzigingen en vertalingen ruimen de cache op

Een cache is pas bruikbaar als ze nooit verouderde pagina's uitlevert. Een zuivere tijdslimiet (“elke twaalf uur weggooien”) zou te grof zijn: een gewijzigde prijs of een gecorrigeerde typefout zou tot twaalf uur moeten wachten. De module werkt daarom inhoudsgericht.

1. Database-triggers: Op alle tabellen die een pagina kunnen beïnvloeden (producten, varianten, afbeeldingen, voorraad, attributen, categorieën, prijzen, belastingen, prijslijsten, blogartikelen en tags, partner- en bedrijfsgegevens, weergaven, assets, menu's, talen, website-instellingen) zitten PostgreSQL-triggers. Ze leggen elke wijziging vast in een wijzigingsjournaal.
2. Afhankelijkheden en databasestand: Elke gecachte pagina onthoudt welke records ze toont en met welke databasestand ze is gegenereerd.
3. Vergelijking: Bestaat er een journaalregel die na die stand is ontstaan en een van deze records betreft, dan is de pagina verouderd.
4. Opnieuw cachen: Bij de volgende aanroep wordt de verouderde pagina weggegooid, opnieuw gerenderd en weer opgeslagen.

Ook vertalingen zijn gedekt

Odoo 19 slaat vertaalde teksten op in hetzelfde record als de oorspronkelijke tekst (als JSON-veld). Een gewijzigde vertaling is voor de database dus een heel gewone rijwijziging – en de trigger ziet die. Dat geldt evenzeer voor bewerking via de interface, voor imports, voor koppelingen en voor scripts die rechtstreeks naar de database schrijven. Een automatische vertaling in 46 talen maakt dus precies de pagina's ongeldig waarvan de tekst is veranderd, en niet meer.

• Gericht in plaats van algemeen: Een gewijzigd product maakt zijn pagina's ongeldig, de lijsten waarin het staat en de bijbehorende categorie. De rest blijft in de cache.
• Globale wijzigingen (templates, assets, talen, menu's, belastingen, valuta's) maken alles in één keer ongeldig, omdat ze elke pagina kunnen raken.
• Tellers blijven buiten beschouwing: De weergaveteller van blogartikelen verandert bij elk bezoek; die veroorzaakt bewust geen ongeldigmaking, anders zou de cache bij populaire artikelen nutteloos zijn.
• Vangnet: Daarnaast is er een maximale leeftijd per pagina (standaard 12 uur).
• Geen schrijffout door de cache: Een fout binnen een trigger wordt als waarschuwing gelogd en laat het eigenlijke opslaan niet mislukken.

Dashboard en statistieken

Alles wat u voor het beheer nodig hebt, staat op één plek: in Odoo onder Website → Rapporten → Paginacache. Het gedeelte Overzicht is het dashboard (met de instellingen), het gedeelte Verloop toont de cijfers per dag en website.

Schermafbeelding uit een testsysteem met kopieën van onze websites; de namen van de websites zijn vervangen door plaatsaanduidingen.

Instellingen

Status en statistieken

De status toont de actieve opslaglocatie met limiet, het aantal en de grootte van de gecachte pagina's en de wijzigingsregistratie: hoeveel wijzigingen er in de afgelopen 24 uur zijn geregistreerd en hoeveel tabellen worden bewaakt. Ontbreekt er een bewaking, dan waarschuwt het dashboard duidelijk, want dan mag de cache niet worden vertrouwd. Met de knoppen bovenaan kunt u het onderhoud direct uitvoeren, de cache legen of de triggers controleren en zo nodig opnieuw aanmaken.

De statistieken (Vandaag, 7 dagen, 30 dagen) bevatten:

• Uit de cache en Gerenderd: hits en misses, en daaruit het hitpercentage
• Verwijderd (gewijzigd/verlopen): hoeveel pagina's wegens wijziging of verlopen zijn weggegooid
• Rendertijd en cachetijd: het gemiddelde per pagina in vergelijking
• Geschatte bespaarde servertijd en hoeveelheid data uit de cache

De cijfers worden door elk werkproces afzonderlijk verzameld en eenmaal per minuut weggeschreven; rijen die ouder zijn dan 90 dagen, ruimt de onderhoudstaak op.

Verloop als diagram, draaitabel en lijst

Onder Verloop vindt u de dagwaarden per website – als diagram, als draaitabel of als lijst. Zo ziet u of het hitpercentage na een herstart of na een grote wijziging weer stijgt, en welke website het meeste verkeer uit de cache krijgt.

Beveiliging: wat nooit uit de cache komt

Een paginacache mag er nooit toe leiden dat iemand de inhoud van een ander ziet. De module volgt daarom het principe: bij twijfel niet cachen.

• Alleen anonieme bezoekers: Wie is aangemeld, een winkelwagen heeft of een andere sessiestatus meebrengt, krijgt altijd de normaal gerenderde pagina.
• Alleen GET zonder zoekparameters: Zoekopdrachten, filters, sorteringen, formulieren, winkelwagen en kassa blijven onaangetast.
• Alleen status 200 en HTML: Foutpagina's, doorverwijzingen en bestanden worden niet opgeslagen.
• Geen sessie-ID's in de cache: Een pagina die een sessie-ID bevat of een cookie plaatst, wordt niet opgeslagen (en als waarschuwing gelogd).
• CSRF-token per aanvraag: Het token in de gecachte pagina is een plaatshouder en wordt bij elke uitlevering opnieuw ingevuld.
• Fijne sleutel: Website, taal, prijslijst, fiscale positie en cookietoestemming horen bij de cachesleutel; wie iets anders ziet, krijgt een ander item.
• Meerdere databases: Elke database heeft eigen items, een eigen journaal en eigen statistieken.
• Geen datalek: De cache staat lokaal op de server (bestand of RAM). Er worden geen gegevens aan derden doorgegeven.

Zoekmachines en AI-indexeerders: er wordt niets geblokkeerd

Sommige beheerders reageren op crawlerbelasting met blokkades. Dat beschermt de server, maar kost zichtbaarheid. De module kiest de omgekeerde weg:

• Dezelfde inhoud voor iedereen: Zoekmachines, AI-indexeerders en bezoekers krijgen dezelfde pagina. Er is geen aparte “crawlerversie” en geen herkenning op basis van de browseridentificatie.
• Snellere antwoorden helpen de indexering: Een pagina die in 20 in plaats van 500 milliseconden antwoordt, belast het crawlbudget minder, en crawlers kunnen in dezelfde tijd meer pagina's verwerken.
• Actuele inhoud: Omdat wijzigingen de pagina's meteen ongeldig maken, zien crawlers nooit een verouderde versie – belangrijk als u inhoud onderhoudt voor zoekopdrachten en AI-antwoorden.
• Gestructureerde gegevens blijven behouden: JSON-LD, metagegevens en hreflang-verwijzingen maken deel uit van de gecachte pagina; sitemaps en bestanden worden door de cache niet aangeraakt.

Wilt u daarnaast belasting beperken, dan is dat een aparte beslissing die u bewust kunt nemen – de module dwingt die niet op.

HTML minimaliseren en gecomprimeerd uitleveren

De cache bespaart niet alleen rekentijd, maar ook datavolume. De module minimaliseert de HTML voordat die wordt opgeslagen en levert deze gecomprimeerd uit wanneer de browser of crawler dat aanbiedt:

• Minimaliseren (parameter website_page_cache.minify): HTML-commentaar vervalt, witruimte wordt samengevoegd. Volledig verwijderd wordt die alleen waar de browser haar toch negeert, bijvoorbeeld tussen blokelementen. Afstanden tussen inline-elementen blijven behouden, pre, textarea en scripts blijven ongewijzigd, gestructureerde gegevens (JSON-LD) worden compact herschreven. Afhankelijk van de pagina zijn de pagina's 10 tot 30 % kleiner. Bij de test met zeven echte pagina's waren tekst, aantal elementen, positie van alle elementen en schermafbeelding identiek aan het origineel. De eerste uitlevering (MISS) is net zo geminimaliseerd als elke volgende (HIT).
• Comprimeren (parameter website_page_cache.compress): Pagina's uit de cache gaan via gzip de deur uit (Content-Encoding: gzip, Vary: Accept-Encoding). De grote assetpakketten (CSS en JavaScript, tot enkele MB) levert Odoo zelf ongecomprimeerd uit; de module comprimeert ze eenmaal, slaat de kopie op de schijf op en levert ze daarna rechtstreeks uit. Uit 2,1 MB CSS werd zo 0,27 MB, uit 4,8 MB JavaScript 1,1 MB. Oude kopieën ruimt de onderhoudstaak op.
• Na een herstart van de machine: De RAM-cache blijft behouden bij herstarts van Odoo, maar niet bij een herstart van de server. Daarom spiegelt de onderhoudstaak hem stapsgewijs naar de schijf (parameter website_page_cache.persist) en herstelt hem bij het opstarten. Of een hersteld item nog geldig is, controleert hetzelfde mechanisme als anders: leeftijd en wijzigingsjournaal. De minimalisatie wordt daarbij niet opnieuw berekend.

Installatie en instellingen

1. Module ophalen: Broncode van GitHub downloaden en in een addons-pad van uw Odoo 19-installatie plaatsen: github.com/Alex0176/odoo-website-page-cache
2. Installeren: odoo-bin -d <Datenbank> -i website_page_cache --stop-after-init. Daarbij ontstaan het wijzigingsjournaal, de triggers en de onderhoudstaak (elke 10 minuten).
3. Service herstarten, zodat alle werkprocessen de module laden.
4. Dashboard openen: Website → Rapporten → Paginacache. Controleren of de wijzigingsregistratie volledig is en de opslaglocatie kiezen (standaard: automatisch).
5. Controleren: Een shop- of blogpagina tweemaal opvragen en de header X-Page-Cache bekijken: de eerste keer MISS, daarna HIT.

De instellingen zijn beschikbaar als systeemparameters (website_page_cache.enabled, .backend, .ttl_hours, .max_mb_file, .max_mb_ram) en worden normaal in het dashboard beheerd. De module is in het Duits vertaald. Verwijderen haalt triggers, journaal en alle gecachte pagina's weer volledig weg.

Tip voor de RAM-cache: het RAM-budget in het dashboard en de grootte van de tmpfs (/dev/shm, mountoptie size=) moeten bij de behoefte passen. Beide worden met concrete waarden genoemd door de controle “Past het in het werkgeheugen?”.

Beperkingen die u moet kennen

• Korte vertraging na wijzigingen: De index van het wijzigingsjournaal wordt elke twee seconden ververst. Een gewijzigde pagina kan tot dat moment nog in de oude versie worden uitgeleverd.
• Voorraadafhankelijke teksten worden bijgewerkt via voorraadwijzigingen en de maximale leeftijd.
• Schatting van de benodigde ruimte: Extra versies per prijslijst of land zijn niet meegerekend; plan wat reserve in.
• Geen vervanging voor alles: De cache ontlast aanvragen die zij mag bedienen. Aangemelde gebruikers, zoekopdrachten en formulieren lopen nog steeds door Odoo.
• Eerste aanroep blijft traag: Na een herstart van de server (RAM) of een globale wijziging wordt elke pagina eenmaal normaal gerenderd voordat ze in de cache staat.

Veelgestelde vragen

Wat is de paginacache voor Odoo?

Een open-sourcemodule (website_page_cache, Odoo 19, LGPL-3) die openbare shop- en blogpagina's voor anonieme bezoekers uit een cache uitlevert in plaats van ze bij elke aanroep opnieuw te renderen. De cache staat naar keuze in bestanden of in het werkgeheugen.

Blokkeert de module zoekmachines of AI-crawlers?

Nee. Zoekmachines en AI-indexeerders krijgen dezelfde pagina's als elke andere bezoeker, alleen sneller. Er is geen blokkade, geen afremming en geen aparte crawlerversie.

Worden gewijzigde pagina's en vertalingen automatisch opnieuw gecachet?

Ja. PostgreSQL-triggers melden elke wijziging in relevante tabellen aan een journaal; betrokken pagina's worden weggegooid en bij de volgende aanroep opnieuw gerenderd en opgeslagen. Vertalingen zijn gedekt, omdat Odoo 19 ze in hetzelfde record opslaat.

Moet ik bestand of RAM kiezen?

Meestal Automatisch: de module gebruikt het RAM zolang alle pagina's passen en wijkt anders uit naar bestanden. Bestanden zijn geschikt als de cache herstarts moet overleven of het RAM krap is; het RAM is de snelste variant.

Hoe weet ik of mijn website in het werkgeheugen past?

In het dashboard onder Website → Rapporten → Paginacache. Het gedeelte “Past het in het werkgeheugen?” telt de pagina's per website en taal, meet de paginagrootte en vergelijkt de behoefte met het RAM-budget, de tmpfs-grootte en het beschikbare geheugen.

Hoeveel extra RAM is er nodig voor een RAM-cache?

Het dashboard noemt dit als een aparte regel. Er wordt gerekend: behoefte = pagina's × paginagrootte; met veiligheidsreserve gedeeld door 0,8. Omdat de cache hoogstens de helft van het beschikbare geheugen mag gebruiken, is het dubbele daarvan het vrij benodigde geheugen; het verschil is het extra RAM. Is alleen het RAM-budget of de tmpfs te klein, dan noemt het dashboard de instelling met de streefwaarde.

Kan de cache iemand vreemde inhoud tonen?

Nee. Er wordt alleen gecachet voor anonieme GET-aanroepen zonder zoekparameters. Aangemelde gebruikers, winkelwagens, formulieren en zoekopdrachten komen nooit uit de cache; taal, prijslijst, fiscale positie en cookietoestemming maken deel uit van de sleutel.

Hoe schakel ik de cache in een noodgeval uit?

Zet in het dashboard de schakelaar “Actief” uit of stel de systeemparameter website_page_cache.enabled in op 0. Dat geldt in alle werkprocessen uiterlijk na 30 seconden. Een deïnstallatie verwijdert bovendien triggers, journaal en gecachte pagina's.

Hoe herken ik of een pagina uit de cache kwam?

Aan de antwoordheader X-Page-Cache: HIT betekent uit de cache, MISS betekent vers gerenderd en opgeslagen.

Maakt de module de HTML kleiner en comprimeert ze die?

Ja. Gecachte pagina's worden conservatief geminimaliseerd (commentaar en overbodige witruimte vervallen, inhoud en weergave blijven gelijk) en bij cachehits via gzip uitgeleverd; de assetpakketten worden eenmaal gecomprimeerd en vanaf de schijf geleverd. Beide kunnen via de parameters website_page_cache.minify en website_page_cache.compress worden uitgeschakeld.

Ondersteuning door Biricon IT Services

Reageert uw Odoo-website traag bij crawlerbelasting, of wilt u shop en blog sneller en zichtbaarder maken? Wij ondersteunen bij de analyse van de belasting, bij de inrichting van de paginacache, bij de dimensionering van werkgeheugen en werkprocessen en bij de meertalige zoekmachineoptimalisatie van uw Odoo-website. De broncode van de module vindt u op GitHub.

Neem nu contact op

Stand: 10 november 2026. Meetwaarden komen uit een testsysteem met voorbeeldgegevens en vormen geen toezegging voor andere installaties.