Sidecache til Odoo: Shop og blog fra RAM eller fil – hurtigt for besøgende, søgemaskiner og AI

10. november 2026  |  Egenudvikling  |  Odoo, ydeevne og søgemaskiner

Et Odoo-websted gengiver hver side forfra ved hvert kald: databaseforespørgsler, skabeloner, oversættelser, priser. For en enkelt besøgende er det ubemærket. Men når søgemaskiner og AI-indeksere henter hundredvis eller tusindvis af sider på mange sprog, bliver det til en vedvarende belastning, og rigtige kunder må vente med. Vi har udviklet Odoo 19-modulet website_page_cache til netop dette og udgivet det som Open Source (LGPL-3) på GitHub: Shop- og blogsider, der hentes anonymt, leveres næsten statisk fra en cache, enten fra filer eller fra arbejdshukommelsen (RAM), og hver ændring – også af en oversættelse – fjerner automatisk de berørte sider fra cachen igen.

Vigtigt for alle, der vil kunne findes: Modulet blokerer ingen søgemaskine og ingen AI-crawler. Alle indeksere får det samme indhold som enhver besøgende, blot hurtigere. Dette indlæg forklarer, hvordan cachen virker, hvordan dashboardet ser ud (med skærmbilleder), hvordan De kan se, om Deres sider kan være i arbejdshukommelsen, og hvor meget ekstra RAM der ville være nødvendigt, hvilke sikkerhedsregler der gælder, og hvordan De installerer modulet.

Kort fortalt

Problemet: crawler-belastning på Odoo-websteder

Odoo er et komplet ERP-system, og webstedet er blot et af mange moduler. Hver side, som en besøgende eller en robot henter, gennemgår den samme vej: behandle forespørgslen, spørge databasen, indlæse produkt- og prisdata, gengive QWeb-skabelonen, indsætte oversættelser og levere resultatet. Det tager afhængigt af siden nogle hundrede millisekunder og optager i den tid en af de få arbejdsprocesser.

For søgemaskiner og AI-indeksere er det et vedvarende problem:

• Mange sprog, mange adresser: En side, der findes på 46 sprog, er for en crawler 46 forskellige adresser.
• Hver adresse hentes enkeltvis, ofte af mange distribuerede afsendere samtidig. En klassisk browsercache hjælper ikke her, fordi hvert kald gælder en ny adresse.
• Få arbejdsprocesser: En Odoo-tjeneste kører typisk med en håndfuld processer. Er de optaget af crawler-forespørgsler, står rigtige besøgende i kø.
• Samme indhold, igen og igen: Et blogindlæg ændres sjældent, men samles omstændeligt forfra ved hvert kald.

Den nærliggende udvej – at udelukke crawlere – er for en virksomhed, der vil findes, ingen mulighed. Synlighed i søgemaskiner og i AI-svar er værdifuld. Bedre er det at levere siderne så hurtigt, at belastningen næsten ikke betyder noget. Det er præcis, hvad sidecachen gør.

Sådan fungerer sidecachen

Modulet kobler sig på Odoos forespørgselsindgang (ir.http). Ved hvert sidekald afgør det på brøkdele af et millisekund, om siden må komme fra cachen, og leverer den så uden database, uden skabelon og uden gengivelse.

1. Kontrol: Kun et anonymt GET-kald uden søgeparametre på en tilladt sti (shop, kategorier, produkter, blog) kommer i betragtning. Alt andet kører som sædvanligt gennem Odoo.
2. Cache-nøgle: Den består af websted, værtsklasse, sprog, sti, prisliste, skatteposition og cookie-samtykkestatus. Besøgende, der ville se noget andet, deler derfor aldrig en post. Værten normaliseres: Odoo skriver absolutte adresser altid ud fra webstedets domæne, ikke ud fra forespørgslen; forespørgselsadressen afgør kun, om siden gælder som hovedadresse (sprogreferencer), og om den skal indekseres. Alle fremmede værtsnavne deler derfor én post inklusive noindex-angivelse i stedet for hver at optage en egen kopi.
3. Hit: Findes der en aktuel post, leveres den. CSRF-tokenet i siden sættes her påny for hver forespørgsel. Kald af blogindlæg tælles stadig med.
4. Miss: Mangler posten, eller er den forældet, gengiver Odoo siden som sædvanligt. Kan resultatet caches (status 200, HTML, ingen cookie, intet sessions-id i teksten), gemmes det; næste kald er et hit.
5. Synligt i headeren: Hvert svar bærer headeren X-Page-Cache: HIT eller MISS. Så kan man med ethvert værktøj kontrollere, hvad der skete.

Hvor meget hurtigere?

I vores testsystem (kopi af vores websteder, nogle hundrede sider) lå den gennemsnitlige gengivelsestid for en side på omkring 490 millisekunder, levering fra cachen på omkring 23 millisekunder: ca. tyve gange hurtigere. Jo mere kompleks en side er, desto større er gevinsten. Dashboardet beregner desuden ud fra begge værdier den anslåede sparede servertid.

Fil eller RAM: vælg lagringssted

Cachen kender to lagringssteder. Begge er fælles synlige for alle Odoo-arbejdsprocesser, så hver side findes kun én gang, ikke én gang pr. proces.

For de fleste installationer er Automatisk det rigtige valg: De får RAM-hastighed, når der er plads, og falder ellers uden indgreb tilbage til filer.

Kan webstedet være i arbejdshukommelsen? Og hvor meget RAM mangler?

Om en RAM-cache er mulig, afhænger af tre ting: antallet af sider, deres gennemsnitlige størrelse og den tilgængelige hukommelse. Dashboardet regner det ud for Dem:

• Sideantal: Pr. websted tæller det publicerede produkter, shoplistesider, kategorier, blogindlæg og bloglister og ganger med antallet af sprog.
• Sidestørrelse: Så snart der ligger sider i cachen, måles det faktiske gennemsnit; indtil da gælder en antagelsesværdi.
• Plads til cachen: den mindste værdi af det indstillede RAM-budget, tmpfs-størrelsen og halvdelen af den tilgængelige arbejdshukommelse. Serveren må aldrig komme i hukommelsesnød på grund af cachen.
• Vurdering: „passer med reserve“, „knap“, „for stor“ eller „RAM-cache ikke tilgængelig“. „Passer“ gælder, når behovet højst udgør 80 procent af den tilgængelige plads.

Nyt: Hvor meget ekstra RAM ville der være nødvendigt?

Passer cachen ikke, vil man vide, hvad man skal ændre. Dashboardet angiver derfor under vurderingen en konkret linje: „Ekstra RAM til en RAM-cache: ca. … mere arbejdshukommelse på denne server“ – eller „ingen“, hvis pladsen allerede rækker. Hvis det i stedet for serveren blot er en indstilling, der er for lille, står der under, hvilken: modulets RAM-budget eller tmpfs-størrelsen (/dev/shm).

Beregningen bag er enkel og letforståelig:

1. Behov = sider × gennemsnitlig sidestørrelse.
2. Med reserve = behov divideret med 0,8. Denne værdi skal passe ind i RAM-budgettet og i tmpfs, for at vurderingen bliver „passer“.
3. Fri hukommelse: Da cachen højst må bruge halvdelen af den tilgængelige arbejdshukommelse, har serveren brug for mindst det dobbelte af værdien fra trin 2 som frit tilgængelig hukommelse. Mangler der noget, er forskellen den ekstra nødvendige RAM.

Eksemplet på billedet (12.000 sider à 25 KB) er et regnehjælpemiddel, ikke en måling af vores sider. For små websteder er nogle få dusin megabyte nok; eksempeldataene i skærmbillederne klarede sig med omkring 13 MB.

Vigtigt til vurderingen: Skønnet tæller ikke ekstra pris- eller landeversioner med. Den, der bruger mange af dem, bør planlægge lidt reserve. Og: Et for lille RAM-budget er den hyppigste grund til, at automatikken bliver på filer – ikke manglende arbejdshukommelse. Dashboardet viser i så fald netop denne linje.

Ændringer og oversættelser rydder op i cachen

En cache er kun brugbar, hvis den aldrig leverer forældede sider. En ren tidsgrænse („kassér hver tolvte time“) ville være for grov: En ændret pris eller en rettet tastefejl skulle vente op til tolv timer. Modulet arbejder derfor indholdsbaseret.

1. Databasetriggere: På alle tabeller, der kan påvirke en side (produkter, varianter, billeder, lagerbeholdning, attributter, kategorier, priser, skatter, prislister, blogindlæg og tags, partner- og firmadata, visninger, assets, menuer, sprog, webstedsindstillinger), sidder PostgreSQL-triggere. De registrerer hver ændring i en ændringsjournal.
2. Afhængigheder og databasestatus: Hver cachet side husker, hvilke poster den viser, og den databasestatus, den blev oprettet med.
3. Afstemning: Findes der en journalpost, der opstod efter denne status og berører en af disse poster, er siden forældet.
4. Cache påny: Ved næste kald kasseres den forældede side, gengives påny og gemmes igen.

Også oversættelser er dækket

Odoo 19 gemmer oversatte tekster i samme post som originalteksten (som JSON-felt). En ændret oversættelse er derfor for databasen en helt almindelig rækkeændring – og triggeren ser den. Det gælder lige så vel redigering via brugerfladen som importer, grænseflader og scripts, der skriver direkte i databasen. En automatisk oversættelse af 46 sprog gør altså netop de sider ugyldige, hvis tekst er ændret, og ikke flere.

• Målrettet i stedet for generelt: Et ændret produkt gør dets sider, de lister, det står i, og den tilhørende kategori ugyldige. Resten bliver i cachen.
• Globale ændringer (skabeloner, assets, sprog, menuer, skatter, valutaer) gør alt ugyldigt på én gang, fordi de kan berøre enhver side.
• Tællere holdes udenfor: Visningstælleren på blogindlæg ændres ved hvert besøg; den udløser bevidst ingen ugyldiggørelse, ellers ville cachen være virkningsløs for populære indlæg.
• Sikkerhedsnet: Desuden findes en maksimal alder pr. side (standard 12 timer).
• Ingen skrivefejl på grund af cachen: En fejl inde i en trigger logges som advarsel og lader ikke den egentlige lagring mislykkes.

Dashboard og statistik

Alt, hvad De behøver til driften, findes ét sted: i Odoo under Website → Rapportering → Sidecache. Afsnittet Oversigt er dashboardet (med indstillingerne), afsnittet Forløb viser tallene pr. dag og websted.

Skærmbillede fra et testsystem med kopier af vores websteder; webstedsnavnene er erstattet af pladsholdere.

Indstillinger

Status og statistik

Status viser det aktive lagringssted inklusive grænse, antallet og størrelsen af de cachede sider og ændringssporingen: hvor mange ændringer der er registreret de seneste 24 timer, og hvor mange tabeller der overvåges. Mangler der en overvågning, advarer dashboardet tydeligt, for så må man ikke stole på cachen. Knapperne øverst gør det muligt at køre vedligeholdelsen med det samme, tømme cachen eller kontrollere triggerne og om nødvendigt oprette dem påny.

Statistikken (I dag, 7 dage, 30 dage) indeholder:

• Fra cachen og Gengivet: hits og misses, heraf hitraten
• Fjernet (ændret/udløbet): hvor mange sider der blev kasseret på grund af ændring eller udløb
• Gengivelsestid og cachetid: gennemsnittet pr. side sammenlignet
• Anslået sparet servertid og datamængde fra cachen

Tallene indsamles af hver arbejdsproces for sig og skrives én gang i minuttet; rækker, der er ældre end 90 dage, ryddes af vedligeholdelsesjobbet.

Forløb som diagram, pivot og liste

Under Forløb findes dagsværdierne pr. websted – som diagram, som pivottabel eller som liste. Således kan De se, om hitraten stiger igen efter en genstart eller en stor ændring, og hvilket websted der får mest trafik fra cachen.

Sikkerhed: hvad der aldrig kommer fra cachen

En sidecache må aldrig medføre, at nogen ser en andens indhold. Modulet følger derfor princippet: Hvis i tvivl, så ingen cache.

• Kun anonyme besøgende: Den, der er logget ind, har en indkøbskurv eller medbringer en anden sessionstilstand, får altid den normalt gengivne side.
• Kun GET uden søgeparametre: Søgninger, filtre, sorteringer, formularer, indkøbskurv og kasse forbliver urørt.
• Kun status 200 og HTML: Fejlsider, omdirigeringer og filer gemmes ikke.
• Ingen sessions-id'er i cachen: En side, der indeholder et sessions-id eller sætter en cookie, gemmes ikke (og logges som advarsel).
• CSRF-token pr. forespørgsel: Tokenet i den cachede side er en pladsholder og indsættes påny ved hver levering.
• Fin nøgle: Websted, sprog, prisliste, skatteposition og cookie-samtykke indgår i cache-nøglen; den, der ser noget andet, får en anden post.
• Flere databaser: Hver database har egne poster, eget journal og egen statistik.
• Ingen dataudsivning: Cachen ligger lokalt på serveren (fil eller RAM). Der overføres ingen data til tredjeparter.

Søgemaskiner og AI-indeksere: intet bliver blokeret

Nogle driftsansvarlige reagerer på crawler-belastning med spærringer. Det beskytter serveren, men koster synlighed. Modulet vælger den modsatte vej:

• Samme indhold til alle: Søgemaskiner, AI-indeksere og besøgende får den samme side. Der findes ingen egen „crawler-version“ og ingen genkendelse via browseridentifikation.
• Hurtigere svar hjælper indekseringen: En side, der svarer på 20 i stedet for 500 millisekunder, belaster crawl-budgettet mindre, og crawlere kan registrere flere sider på samme tid.
• Aktuelt indhold: Fordi ændringer straks gør siderne ugyldige, ser crawlere aldrig en forældet version – vigtigt, hvis De vedligeholder indhold til søgning og AI-svar.
• Strukturerede data bevares: JSON-LD, metaangivelser og hreflang-henvisninger er en del af den cachede side; sitemaps og filer berøres ikke af cachen.

Hvis De desuden vil begrænse belastningen, er det en særskilt beslutning, som De bevidst kan træffe – modulet påtvinger Dem den ikke.

Minimer HTML og lever det komprimeret

Cachen sparer ikke kun regnetid, men også datamængde. Modulet minimerer HTML, før det gemmes, og leverer det komprimeret, når browseren eller crawleren tilbyder det:

• Minimering (parameter website_page_cache.minify): HTML-kommentarer udgår, mellemrum samles. Det fjernes kun helt dér, hvor browseren alligevel ignorerer det, f.eks. mellem blokelementer. Afstande mellem inline-elementer bevares, pre, textarea og scripts forbliver uændrede, strukturerede data (JSON-LD) skrives kompakt påny. Afhængigt af siden bliver siderne 10 til 30 % mindre. Ved testen med syv rigtige sider var tekst, antal elementer, position af alle elementer og skærmbillede identiske med originalen. Den første levering (MISS) er lige så minimeret som hver efterfølgende (HIT).
• Komprimering (parameter website_page_cache.compress): Sider fra cachen sendes af sted med gzip (Content-Encoding: gzip, Vary: Accept-Encoding). De store asset-pakker (CSS og JavaScript, op til nogle få MB) leverer Odoo selv ukomprimeret; modulet komprimerer dem én gang, lægger kopien på disken og leverer dem derefter direkte. Af 2,1 MB CSS blev der således 0,27 MB, af 4,8 MB JavaScript 1,1 MB. Gamle kopier ryddes af vedligeholdelsesjobbet.
• Efter genstart af maskinen: RAM-cachen bevares ved genstart af Odoo, men ikke ved genstart af serveren. Derfor spejler vedligeholdelsesjobbet den gradvist til disken (parameter website_page_cache.persist) og genopretter den ved start. Om en genoprettet post stadig er gyldig, kontrollerer den samme mekanisme som ellers: alder og ændringsjournal. Minimeringen beregnes ikke påny i den forbindelse.

Installation og indstillinger

1. Hent modulet: Download kildekoden fra GitHub og læg den i en addons-sti i Deres Odoo 19-installation: github.com/Alex0176/odoo-website-page-cache
2. Installer: odoo-bin -d <Datenbank> -i website_page_cache --stop-after-init. Herved oprettes ændringsjournalen, triggerne og vedligeholdelsesjobbet (hvert 10. minut).
3. Genstart tjenesten, så alle arbejdsprocesser indlæser modulet.
4. Åbn dashboardet: Website → Rapportering → Sidecache. Kontrollér, at ændringssporingen er fuldstændig, og vælg lagringssted (standard: automatisk).
5. Kontrollér: Hent en shop- eller blogside to gange og se på headeren X-Page-Cache: første gang MISS, derefter HIT.

Indstillingerne findes som systemparametre (website_page_cache.enabled, .backend, .ttl_hours, .max_mb_file, .max_mb_ram) og vedligeholdes normalt i dashboardet. Modulet er oversat til tysk. Afinstallation fjerner igen triggere, journal og alle cachede sider fuldstændigt.

Tip til RAM-cachen: RAM-budgettet i dashboardet og størrelsen af tmpfs (/dev/shm, mount-indstilling size=) skal passe til behovet. Begge dele angiver kontrollen „Kan det være i arbejdshukommelsen?“ med konkrete værdier.

Begrænsninger, De bør kende

• Kort forsinkelse efter ændringer: Indekset for ændringsjournalen opdateres hvert andet sekund. En ændret side kan indtil da stadig blive leveret i den gamle version.
• Lagerafhængige tekster opdateres via lagerændringer og den maksimale alder.
• Skøn over pladsbehovet: Ekstra versioner pr. prisliste eller land er ikke medregnet; planlæg lidt reserve.
• Ingen erstatning for alt: Cachen aflaster de forespørgsler, den må betjene. Loggede brugere, søgninger og formularer kører fortsat gennem Odoo.
• Første kald forbliver langsomt: Efter en genstart af serveren (RAM) eller en global ændring gengives hver side én gang normalt, før den ligger i cachen.

Ofte stillede spørgsmål

Hvad er sidecachen til Odoo?

Et open source-modul (website_page_cache, Odoo 19, LGPL-3), der leverer offentlige shop- og blogsider til anonyme besøgende fra en cache i stedet for at gengive dem forfra ved hvert kald. Cachen ligger efter valg i filer eller i arbejdshukommelsen.

Blokerer modulet søgemaskiner eller AI-crawlere?

Nej. Søgemaskiner og AI-indeksere får de samme sider som enhver anden besøgende, blot hurtigere. Der er ingen spærring, ingen begrænsning og ingen særlig crawler-version.

Bliver ændrede sider og oversættelser automatisk cachet påny?

Ja. PostgreSQL-triggere melder hver ændring af relevante tabeller til et journal; berørte sider kasseres og gengives påny og gemmes ved næste kald. Oversættelser er dækket, fordi Odoo 19 gemmer dem i samme post.

Skal jeg vælge fil eller RAM?

Som regel Automatisk: Modulet bruger RAM, så længe alle sider kan være der, og viger ellers over til filer. Filer egner sig, hvis cachen skal overleve genstart, eller RAM er knap; RAM er den hurtigste variant.

Hvordan finder jeg ud af, om mit websted kan være i arbejdshukommelsen?

I dashboardet under Website → Rapportering → Sidecache. Afsnittet „Kan det være i arbejdshukommelsen?“ tæller siderne pr. websted og sprog, måler sidestørrelsen og sammenligner behovet med RAM-budget, tmpfs-størrelse og tilgængelig hukommelse.

Hvor meget ekstra RAM kræves der til en RAM-cache?

Dashboardet angiver det som en egen linje. Beregningen er: behov = sider × sidestørrelse; med sikkerhedsreserve divideret med 0,8. Da cachen højst må bruge halvdelen af den tilgængelige hukommelse, er det dobbelte heraf den frit nødvendige hukommelse; forskellen er den ekstra RAM. Er blot RAM-budgettet eller tmpfs for lille, angiver dashboardet indstillingen inklusive målværdi.

Kan cachen vise nogen fremmed indhold?

Nej. Der caches kun for anonyme GET-kald uden søgeparametre. Loggede brugere, indkøbskurve, formularer og søgninger kommer aldrig fra cachen; sprog, prisliste, skatteposition og cookie-samtykke er en del af nøglen.

Hvordan slår jeg cachen fra i en nødsituation?

Slå kontakten „Aktiv“ fra i dashboardet, eller sæt systemparameteren website_page_cache.enabled til 0. Det gælder i alle arbejdsprocesser senest efter 30 sekunder. En afinstallation fjerner desuden triggere, journal og cachede sider.

Hvordan kan jeg se, om en side kom fra cachen?

På svarheaderen X-Page-Cache: HIT betyder fra cachen, MISS betyder nygengivet og gemt.

Gør modulet HTML mindre og komprimerer det?

Ja. Cachede sider minimeres konservativt (kommentarer og overflødige mellemrum udgår, indhold og visning forbliver ens) og leveres ved cache-hits med gzip; asset-pakkerne komprimeres én gang og leveres fra disken. Begge dele kan slås fra via parametrene website_page_cache.minify og website_page_cache.compress.

Support fra Biricon IT Services

Reagerer Deres Odoo-websted træg under crawler-belastning, eller vil De gøre shop og blog hurtigere og mere synlige? Vi hjælper med analyse af belastningen, med opsætning af sidecachen, med dimensionering af arbejdshukommelse og arbejdsprocesser og med flersproget søgemaskineoptimering af Deres Odoo-websted. Modulets kildekode finder De på GitHub.

Kontakt os nu

Status: 10. november 2026. Måleværdierne stammer fra et testsystem med eksempeldata og er ikke en tilsagn for andre installationer.