Sidcache för Odoo: butik och blogg från RAM eller fil – snabbt för besökare, sökmotorer och AI

10 november 2026  |  Egenutveckling  |  Odoo, prestanda och sökmotorer

En Odoo-webbplats renderar varje sida på nytt vid varje anrop: databasfrågor, mallar, översättningar, priser. För en enskild besökare märks det knappt. Men när sökmotorer och AI-indexerare hämtar hundratals eller tusentals sidor på många språk blir det en ständig belastning, och riktiga kunder får vänta med. Därför har vi utvecklat Odoo 19-modulen website_page_cache och publicerat den på GitHub som öppen källkod (LGPL-3): Butiks- och bloggsidor som anropas anonymt levereras nästan statiskt från en cache, antingen från filer eller från arbetsminnet (RAM), och varje ändring – även av en översättning – tar automatiskt bort de berörda sidorna ur cachen.

Viktigt för alla som vill bli hittade: Modulen blockerar ingen sökmotor och ingen AI-crawler. Alla indexerare får samma innehåll som alla andra besökare, bara snabbare. Det här inlägget förklarar hur cachen fungerar, hur instrumentpanelen ser ut (med skärmbilder), hur du ser om dina sidor ryms i arbetsminnet och hur mycket extra RAM som skulle behövas, vilka säkerhetsregler som gäller och hur du installerar modulen.

Sammanfattning

Problemet: crawlerbelastning på Odoo-webbplatser

Odoo är ett komplett ERP-system, och webbplatsen är en av många moduler. Varje sida som en besökare eller en robot anropar går samma väg: bearbeta förfrågan, fråga databasen, läsa in produkt- och prisdata, rendera QWeb-mallen, infoga översättningar och leverera resultatet. Beroende på sida tar det några hundra millisekunder och upptar under tiden en av de få arbetsprocesserna.

För sökmotorer och AI-indexerare är det ett ständigt problem:

• Många språk, många adresser: En sida som finns på 46 språk blir 46 olika adresser för en crawler.
• Varje adress hämtas för sig, ofta av många distribuerade avsändare samtidigt. En vanlig webbläsarcache hjälper inte här, eftersom varje anrop gäller en ny adress.
• Få arbetsprocesser: En Odoo-tjänst körs vanligtvis med en handfull processer. Är de upptagna med crawlerförfrågningar får riktiga besökare stå i kö.
• Samma innehåll, om och om igen: Ett blogginlägg ändras sällan, men sätts ihop på nytt med stor möda vid varje anrop.

Den närliggande utvägen – att stänga ute crawlers – är inget alternativ för ett företag som vill bli hittat. Synlighet i sökmotorer och i AI-svar är värdefull. Bättre är att leverera sidorna så snabbt att belastningen knappt märks. Precis det gör sidcachen.

Så fungerar sidcachen

Modulen kopplar in sig i Odoos ingång för förfrågningar (ir.http). Vid varje sidanrop avgör den på en bråkdel av en millisekund om sidan får komma från cachen, och levererar den då utan databas, utan mall och utan rendering.

1. Kontroll: Endast ett anonymt GET-anrop utan sökparametrar till en tillåten sökväg (butik, kategorier, produkter, blogg) kommer i fråga. Allt annat går som vanligt genom Odoo.
2. Cachenyckel: Den består av webbplats, värdklass, språk, sökväg, prislista, skatteposition och status för cookie-samtycke. Besökare som skulle se något annat delar därför aldrig en post. Värden normaliseras: Odoo skriver alltid absoluta adresser utifrån webbplatsens domän, inte utifrån förfrågan; förfrågans adress avgör bara om sidan räknas som huvudadress (språklänkar) och om den ska indexeras. Alla främmande värdnamn delar därför en post inklusive noindex-anvisning, i stället för att var och en upptar en egen kopia.
3. Träff: Finns det en aktuell post levereras den. CSRF-token i sidan sätts då om för varje förfrågan. Visningar av blogginlägg räknas fortfarande.
4. Miss: Saknas posten eller är den föråldrad renderar Odoo sidan som vanligt. Om resultatet kan cachas (status 200, HTML, ingen cookie, inget sessions-ID i texten) sparas det; nästa anrop blir en träff.
5. Synligt i headern: Varje svar har headern X-Page-Cache: HIT eller MISS. Så kan man med vilket verktyg som helst kontrollera vad som hände.

Hur mycket snabbare?

I vårt testsystem (en kopia av våra webbplatser, några hundra sidor) låg den genomsnittliga renderingstiden per sida på cirka 490 millisekunder och leveransen från cachen på cirka 23 millisekunder: ungefär tjugo gånger snabbare. Ju mer komplex en sida är, desto större vinst. Utifrån båda värdena beräknar instrumentpanelen dessutom den uppskattade besparingen i servertid.

Fil eller RAM: välj lagringsplats

Cachen har två lagringsplatser. Båda är gemensamt synliga för alla Odoo-arbetsprocesser, så varje sida finns bara en gång, inte en gång per process.

För de flesta installationer är Automatiskt rätt val: Du får RAM-hastighet när utrymmet finns och faller annars tillbaka på filer utan att behöva ingripa.

Ryms webbplatsen i arbetsminnet? Och hur mycket RAM saknas?

Om en RAM-cache är möjlig beror på tre saker: antalet sidor, deras genomsnittliga storlek och det tillgängliga minnet. Instrumentpanelen räknar ut det åt dig:

• Antal sidor: För varje webbplats räknas publicerade produkter, butikslistor, kategorier, blogginlägg och blogglistor, multiplicerat med antalet språk.
• Sidstorlek: Så snart sidor finns i cachen mäts det faktiska genomsnittet; tills dess används ett antaget värde.
• Utrymme för cachen: det minsta av den inställda RAM-budgeten, storleken på tmpfs och hälften av det tillgängliga arbetsminnet. Servern ska aldrig hamna i minnesbrist på grund av cachen.
• Utlåtande: ”ryms med marginal”, ”knappt”, ”för stort” eller ”RAM-cache inte tillgänglig”. ”Ryms” gäller när behovet uppgår till högst 80 procent av det tillgängliga utrymmet.

Nytt: Hur mycket extra RAM skulle behövas?

Om cachen inte ryms vill man veta vad som måste ändras. Instrumentpanelen anger därför under utlåtandet en konkret rad: ”Extra RAM för en RAM-cache: ungefär … mer arbetsminne på den här servern” – eller ”inget” om utrymmet redan räcker. Om det i stället är en inställning som är för liten, står det under raden vilken: modulens RAM-budget eller storleken på tmpfs (/dev/shm).

Beräkningen bakom är enkel och lätt att följa:

1. Behov = sidor × genomsnittlig sidstorlek.
2. Med marginal = behovet dividerat med 0,8. Det här värdet måste rymmas i RAM-budgeten och i tmpfs för att utlåtandet ska bli ”ryms”.
3. Ledigt minne: Eftersom cachen får använda högst hälften av det tillgängliga arbetsminnet behöver servern minst dubbelt så mycket som värdet i steg 2 som ledigt tillgängligt minne. Saknas något är differensen det extra RAM som behövs.

Exemplet i bilden (12 000 sidor på 25 KB vardera) är ett räknehjälpmedel, inte en mätning av våra sidor. För små webbplatser räcker några tiotal megabyte; exempeldatan i skärmbilderna klarade sig med cirka 13 MB.

Viktigt för bedömningen: Uppskattningen räknar inte med extra versioner per prislista eller land. Den som använder många sådana planerar in lite marginal. Och: En för liten RAM-budget är den vanligaste orsaken till att automatiken stannar på filer – inte brist på arbetsminne. Instrumentpanelen visar i så fall just den raden.

Ändringar och översättningar rensar cachen

En cache är bara användbar om den aldrig levererar föråldrade sidor. En ren tidsgräns (”släng allt var tolfte timme”) vore för grov: Ett ändrat pris eller ett rättat stavfel skulle få vänta upp till tolv timmar. Modulen arbetar därför innehållsbaserat.

1. Databastriggrar: På alla tabeller som kan påverka en sida (produkter, varianter, bilder, lager, attribut, kategorier, priser, skatter, prislistor, blogginlägg och taggar, partner- och företagsdata, vyer, tillgångar, menyer, språk, webbplatsinställningar) finns PostgreSQL-triggrar. De för in varje ändring i en ändringsjournal.
2. Beroenden och databasstatus: Varje cachad sida minns vilka poster den visar och vilken databasstatus den skapades med.
3. Avstämning: Finns det en journalpost som skapades efter den statusen och som rör någon av dessa poster är sidan föråldrad.
4. Cacha på nytt: Vid nästa anrop kasseras den föråldrade sidan, renderas på nytt och sparas igen.

Även översättningar omfattas

Odoo 19 lagrar översatta texter i samma post som originaltexten (som ett JSON-fält). En ändrad översättning är därför för databasen en alldeles vanlig radändring – och triggern ser den. Det gäller lika för redigering via gränssnittet, för importer, för gränssnitt (API:er) och för skript som skriver direkt i databasen. En automatisk översättning till 46 språk gör alltså exakt de sidor ogiltiga vars text har ändrats, och inga fler.

• Riktat i stället för generellt: En ändrad produkt gör dess sidor ogiltiga, listorna där den ingår och den tillhörande kategorin. Resten blir kvar i cachen.
• Globala ändringar (mallar, tillgångar, språk, menyer, skatter, valutor) gör allt ogiltigt på en gång, eftersom de kan påverka varje sida.
• Räknare lämnas utanför: Visningsräknaren för blogginlägg ändras vid varje besök; den utlöser medvetet ingen ogiltigförklaring, annars vore cachen verkningslös för populära inlägg.
• Skyddsnät: Dessutom finns en maximal ålder per sida (standard 12 timmar).
• Inget skrivfel på grund av cachen: Ett fel i en trigger loggas som en varning och låter inte själva sparandet misslyckas.

Instrumentpanel och statistik

Allt du behöver för driften finns på ett ställe: i Odoo under Webbplats → Rapporter → Sidcache. Avsnittet Översikt är instrumentpanelen (med inställningarna), avsnittet Historik visar siffrorna per dag och webbplats.

Skärmbild från ett testsystem med kopior av våra webbplatser; webbplatsnamnen har ersatts med platshållare.

Inställningar

Status och statistik

Statusen visar den aktiva lagringsplatsen med gräns, antalet och storleken på cachade sidor och ändringsspårningen: hur många ändringar som registrerats under de senaste 24 timmarna och hur många tabeller som övervakas. Saknas någon övervakning varnar instrumentpanelen tydligt, eftersom cachen då inte får litas på. Knapparna högst upp gör det möjligt att köra underhållet direkt, tömma cachen eller kontrollera triggrarna och vid behov skapa dem på nytt.

Statistiken (Idag, 7 dagar, 30 dagar) innehåller:

• Från cachen och Renderat: träffar och missar, och av dem träffkvoten
• Borttagna (ändrade/utgångna): hur många sidor som kasserats på grund av ändring eller utgång
• Renderingstid och cachetid: genomsnittet per sida i jämförelse
• Uppskattad sparad servertid och datamängd från cachen

Siffrorna samlas av varje arbetsprocess för sig och skrivs en gång i minuten; rader som är äldre än 90 dagar rensar underhållsjobbet bort.

Historik som diagram, pivot och lista

Under Historik finns dagsvärdena per webbplats tillgängliga – som diagram, som pivottabell eller som lista. Så ser du om träffkvoten stiger igen efter en omstart eller efter en stor ändring, och vilken webbplats som får mest trafik från cachen.

Säkerhet: vad som aldrig kommer från cachen

En sidcache får aldrig leda till att någon ser en annans innehåll. Modulen följer därför principen: Cacha inte vid tvivel.

• Endast anonyma besökare: Den som är inloggad, har en varukorg eller har något annat sessionstillstånd får alltid den normalt renderade sidan.
• Endast GET utan sökparametrar: Sökningar, filter, sorteringar, formulär, varukorg och kassa berörs inte.
• Endast status 200 och HTML: Felsidor, omdirigeringar och filer sparas inte.
• Inga sessions-ID i cachen: En sida som innehåller ett sessions-ID eller sätter en cookie sparas inte (och loggas som en varning).
• CSRF-token per förfrågan: Token i den cachade sidan är en platshållare och sätts in på nytt vid varje leverans.
• Finkornig nyckel: Webbplats, språk, prislista, skatteposition och cookie-samtycke ingår i cachenyckeln; den som ser något annat får en annan post.
• Flera databaser: Varje databas har egna poster, en egen journal och egen statistik.
• Inget dataläckage: Cachen ligger lokalt på servern (fil eller RAM). Inga data överförs till tredje part.

Sökmotorer och AI-indexerare: inget blockeras

Vissa operatörer svarar på crawlerbelastning med blockeringar. Det skyddar servern men kostar synlighet. Modulen väljer motsatt väg:

• Samma innehåll för alla: Sökmotorer, AI-indexerare och besökare får samma sida. Det finns ingen egen ”crawlerversion” och ingen igenkänning via user agent.
• Snabbare svar underlättar indexeringen: En sida som svarar på 20 i stället för 500 millisekunder belastar crawlbudgeten mindre, och crawlers hinner med fler sidor på samma tid.
• Aktuellt innehåll: Eftersom ändringar gör sidorna ogiltiga omedelbart ser crawlers aldrig en föråldrad version – viktigt om du underhåller innehåll för sök- och AI-svar.
• Strukturerade data bevaras: JSON-LD, metauppgifter och hreflang-länkar är en del av den cachade sidan; sitemaps och filer rörs inte av cachen.

Om du dessutom vill begränsa belastningen är det ett separat beslut som du kan fatta medvetet – modulen tvingar inte på dig något.

Minimera HTML och leverera komprimerat

Cachen sparar inte bara beräkningstid utan även datavolym. Modulen minimerar HTML innan den sparas och levererar den komprimerad när webbläsaren eller crawlern erbjuder det:

• Minimera (parameter website_page_cache.minify): HTML-kommentarer tas bort, blanktecken slås ihop. De tas bort helt endast där webbläsaren ändå ignorerar dem, till exempel mellan blockelement. Mellanrum mellan inline-element bevaras, pre, textarea och skript lämnas oförändrade, strukturerade data (JSON-LD) skrivs om kompakt. Beroende på sida blir sidorna 10 till 30 % mindre. I testet med sju riktiga sidor var text, antal element, placering av alla element och skärmbild identiska med originalet. Den första leveransen (MISS) är minimerad på exakt samma sätt som varje följande (HIT).
• Komprimera (parameter website_page_cache.compress): Sidor från cachen skickas ut med gzip (Content-Encoding: gzip, Vary: Accept-Encoding). De stora tillgångspaketen (CSS och JavaScript, upp till några MB) levererar Odoo själv okomprimerade; modulen komprimerar dem en gång, lägger kopian på disken och levererar den därefter direkt. Av 2,1 MB CSS blev det så 0,27 MB, av 4,8 MB JavaScript 1,1 MB. Gamla kopior rensar underhållsjobbet bort.
• Efter en omstart av datorn: RAM-cachen finns kvar vid omstarter av Odoo, men inte vid omstart av servern. Därför speglar underhållsjobbet den stegvis till disken (parameter website_page_cache.persist) och återställer den vid start. Om en återställd post fortfarande är giltig kontrolleras av samma mekanism som annars: ålder och ändringsjournal. Minimeringen beräknas då inte om.

Installation och inställningar

1. Hämta modulen: Ladda ned källkoden från GitHub och lägg den i en addons-sökväg i din Odoo 19-installation: github.com/Alex0176/odoo-website-page-cache
2. Installera: odoo-bin -d <Datenbank> -i website_page_cache --stop-after-init. Då skapas ändringsjournalen, triggrarna och underhållsjobbet (var tionde minut).
3. Starta om tjänsten så att alla arbetsprocesser läser in modulen.
4. Öppna instrumentpanelen: Webbplats → Rapporter → Sidcache. Kontrollera att ändringsspårningen är fullständig och välj lagringsplats (standard: automatiskt).
5. Kontrollera: Hämta en butiks- eller bloggsida två gånger och titta på headern X-Page-Cache: första gången MISS, sedan HIT.

Inställningarna finns som systemparametrar (website_page_cache.enabled, .backend, .ttl_hours, .max_mb_file, .max_mb_ram) och sköts normalt i instrumentpanelen. Modulen är översatt till tyska. Avinstallation tar åter bort triggrar, journal och alla cachade sidor fullständigt.

Tips för RAM-cachen: RAM-budgeten i instrumentpanelen och storleken på tmpfs (/dev/shm, mount-alternativ size=) måste passa behovet. Båda anger kontrollen ”Ryms det i arbetsminnet?” med konkreta värden.

Begränsningar du bör känna till

• Kort fördröjning efter ändringar: Indexet för ändringsjournalen uppdateras varannan sekund. Tills dess kan en ändrad sida fortfarande levereras i gammal version.
• Lagerberoende texter uppdateras via lagerändringar och maximal ålder.
• Uppskattning av utrymmesbehovet: Extra versioner per prislista eller land ingår inte; planera in lite marginal.
• Ingen ersättning för allt: Cachen avlastar förfrågningar som den får betjäna. Inloggade användare, sökningar och formulär går fortfarande genom Odoo.
• Första anropet förblir långsamt: Efter en omstart av servern (RAM) eller en global ändring renderas varje sida en gång på vanligt sätt innan den ligger i cachen.

Vanliga frågor

Vad är sidcachen för Odoo?

En modul med öppen källkod (website_page_cache, Odoo 19, LGPL-3) som levererar offentliga butiks- och bloggsidor till anonyma besökare från en cache i stället för att rendera dem på nytt vid varje anrop. Cachen ligger valfritt i filer eller i arbetsminnet.

Blockerar modulen sökmotorer eller AI-crawlers?

Nej. Sökmotorer och AI-indexerare får samma sidor som alla andra besökare, bara snabbare. Det finns ingen blockering, ingen strypning och ingen egen crawlerversion.

Cachas ändrade sidor och översättningar om automatiskt?

Ja. PostgreSQL-triggrar rapporterar varje ändring i relevanta tabeller till en journal; berörda sidor kasseras och renderas om och sparas vid nästa anrop. Översättningar omfattas eftersom Odoo 19 lagrar dem i samma post.

Ska jag välja fil eller RAM?

I regel Automatiskt: Modulen använder RAM så länge alla sidor ryms och väjer annars till filer. Filer passar när cachen ska överleva omstarter eller när RAM är knappt; RAM är det snabbaste alternativet.

Hur får jag veta om min webbplats ryms i arbetsminnet?

I instrumentpanelen under Webbplats → Rapporter → Sidcache. Avsnittet ”Ryms det i arbetsminnet?” räknar sidorna per webbplats och språk, mäter sidstorleken och jämför behovet med RAM-budget, tmpfs-storlek och tillgängligt minne.

Hur mycket extra RAM behövs för en RAM-cache?

Instrumentpanelen anger det som en egen rad. Beräkningen: Behov = sidor × sidstorlek; med säkerhetsmarginal dividerat med 0,8. Eftersom cachen får använda högst hälften av det tillgängliga minnet är dubbla beloppet det lediga minne som behövs; differensen är det extra RAM som krävs. Är bara RAM-budgeten eller tmpfs för litet anger instrumentpanelen inställningen med målvärde.

Kan cachen visa någon annans innehåll?

Nej. Endast anonyma GET-anrop utan sökparametrar cachas. Inloggade användare, varukorgar, formulär och sökningar kommer aldrig från cachen; språk, prislista, skatteposition och cookie-samtycke ingår i nyckeln.

Hur stänger jag av cachen i nödfall?

Stäng av omkopplaren ”Aktiv” i instrumentpanelen eller sätt systemparametern website_page_cache.enabled till 0. Det gäller i alla arbetsprocesser senast efter 30 sekunder. En avinstallation tar dessutom bort triggrar, journal och cachade sidor.

Hur ser jag om en sida kom från cachen?

På svarsheadern X-Page-Cache: HIT betyder från cachen, MISS betyder nyrenderad och sparad.

Minimerar och komprimerar modulen HTML?

Ja. Cachade sidor minimeras försiktigt (kommentarer och överflödiga blanktecken tas bort, innehåll och utseende förblir desamma) och levereras med gzip vid cacheträffar; tillgångspaketen komprimeras en gång och levereras från disken. Båda kan stängas av via parametrarna website_page_cache.minify och website_page_cache.compress.

Stöd från Biricon IT Services

Reagerar din Odoo-webbplats trögt vid crawlerbelastning, eller vill du göra butik och blogg snabbare och mer synliga? Vi hjälper till med analys av belastningen, installation av sidcachen, dimensionering av arbetsminne och arbetsprocesser och flerspråkig sökmotoroptimering av din Odoo-webbplats. Modulens källkod hittar du på GitHub.

Kontakta oss nu

Läget: 10 november 2026. Mätvärdena kommer från ett testsystem med exempeldata och är inget löfte för andra installationer.