Oldal-gyorsítótár Odoohoz: bolt és blog RAM-ból vagy fájlból – gyorsan a látogatóknak, a keresőmotoroknak és az MI-nek

2026. november 10.  |  Saját fejlesztés  |  Odoo, teljesítmény és keresőmotorok

Egy Odoo-weboldal minden egyes lekérésnél újra előállít minden oldalt: adatbázis-lekérdezések, sablonok, fordítások, árak. Egyetlen látogatónál ez fel sem tűnik. Ha azonban keresőmotorok és MI-indexelők százával vagy ezrével kérik le az oldalakat sok nyelven, az tartós terheléssé válik, és a valódi vásárlók is várakoznak. Ezért fejlesztettük ki az Odoo 19-hez a website_page_cache modult, és tettük közzé a GitHubon nyílt forráskódú (LGPL-3) szoftverként: a névtelenül lekért bolt- és blogoldalak szinte statikusan, gyorsítótárból érkeznek, vagy fájlokból, vagy a munkamemóriából (RAM), és minden módosítás – egy fordítás módosítása is – automatikusan eltávolítja az érintett oldalakat a gyorsítótárból.

Fontos mindazoknak, akik meg akarnak jelenni a keresésekben: a modul nem tilt le egyetlen keresőmotort és egyetlen MI-crawlert sem. Minden indexelő ugyanazt a tartalmat kapja, mint bármely látogató, csak gyorsabban. Ez a cikk bemutatja, hogyan működik a gyorsítótár, milyen a vezérlőpult (képernyőképekkel), hogyan ismerhető fel, hogy az oldalak elférnek-e a munkamemóriában, és mennyi többlet-RAM lenne szükséges, milyen biztonsági szabályok érvényesek, és hogyan telepíthető a modul.

Röviden

A probléma: crawlerterhelés az Odoo-weboldalakon

Az Odoo teljes értékű ERP-rendszer, a weboldal csupán egy a sok modul közül. Minden oldal, amelyet egy látogató vagy egy robot lekér, ugyanazt az utat járja be: a kérés feldolgozása, az adatbázis lekérdezése, a termék- és áradatok betöltése, a QWeb-sablon előállítása, a fordítások beillesztése és az eredmény kiszolgálása. Ez oldalanként néhány száz ezredmásodpercig tart, és közben lefoglalja a kevés munkafolyamat egyikét.

A keresőmotorok és MI-indexelők számára ez állandó téma:

• Sok nyelv, sok cím: egy 46 nyelven elérhető oldal a crawler számára 46 különböző cím.
• Minden címet külön kérnek le, gyakran sok elosztott feladó egyszerre. A klasszikus böngészős gyorsítótár itt nem segít, mert minden lekérés új címre vonatkozik.
• Kevés munkafolyamat: egy Odoo-szolgáltatás jellemzően maroknyi folyamattal fut. Ha ezeket crawlerkérések foglalják le, a valódi látogatók a sorban várakoznak.
• Ugyanaz a tartalom, újra és újra: egy blogbejegyzés ritkán változik, mégis minden lekérésnél költségesen újra összeállítják.

A kézenfekvő kiút – a crawlerek kizárása – egy olyan cég számára, amely meg akar jelenni a keresésekben, nem járható út. A keresőmotorokban és az MI-válaszokban való láthatóság értékes. Jobb az oldalakat olyan gyorsan kiszolgálni, hogy a terhelés alig számítson. Pontosan ezt teszi az oldal-gyorsítótár.

Így működik az oldal-gyorsítótár

A modul az Odoo kéréseinek bemeneti pontjára kapcsolódik (ir.http). Minden oldallekérésnél a másodperc törtrésze alatt eldönti, hogy az oldal származhat-e a gyorsítótárból, és ha igen, adatbázis, sablon és előállítás nélkül szolgálja ki.

1. Vizsgálat: csak a névtelen, keresési paraméter nélküli GET lekérés jöhet szóba egy engedélyezett útvonalon (bolt, kategóriák, termékek, blog). Minden más a megszokott módon halad át az Odoón.
2. Gyorsítótár-kulcs: a weboldalból, a hostosztályból, a nyelvből, az útvonalból, az árlistából, az adópozícióból és a sütik elfogadási állapotából áll. Azok a látogatók, akik valami mást látnának, ezért soha nem osztoznak egy bejegyzésen. A host normalizált: az Odoo az abszolút címeket mindig a weboldal domainjéből írja, nem a kérésből; a kérés címe csak azt dönti el, hogy az oldal főcímnek számít-e (nyelvi hivatkozások), és hogy indexelni kell-e. Az összes idegen hostnév ezért egyetlen bejegyzésen osztozik a noindex jelzéssel, ahelyett, hogy mindegyik saját másolatot foglalna.
3. Találat: ha van aktuális bejegyzés, azt szolgálja ki. Az oldalban lévő CSRF-token ilyenkor kérésenként újra beállításra kerül. A blogbejegyzések lekéréseit továbbra is számolja.
4. Tévesztés: ha a bejegyzés hiányzik vagy elavult, az Odoo a szokott módon állítja elő az oldalt. Ha az eredmény gyorsítótárazható (200-as állapot, HTML, nincs süti, nincs munkamenet-azonosító a szövegben), eltárolja; a következő lekérés találat lesz.
5. Látható a fejlécben: minden válasz tartalmazza a X-Page-Cache: HIT vagy a MISS fejlécet. Így bármely eszközzel ellenőrizhető, mi történt.

Mennyivel gyorsabb?

A tesztrendszerünkben (a weboldalaink másolata, néhány száz oldal) egy oldal átlagos előállítási ideje körülbelül 490 ezredmásodperc, a gyorsítótárból történő kiszolgálásé körülbelül 23 ezredmásodperc volt: nagyjából a húszszorosa. Minél költségesebb egy oldal, annál nagyobb a nyereség. A vezérlőpult a két értékből ezenkívül kiszámítja a becsült megtakarított szerveridőt.

Fájl vagy RAM: a tárolóhely kiválasztása

A gyorsítótárnak két tárolóhelye van. Mindkettő közösen látható az összes Odoo-munkafolyamat számára, így minden oldal csak egyszer van meg, nem folyamatonként egyszer.

A legtöbb telepítésnél az Automatikus a helyes választás: RAM-sebességet kap, ha van hely, egyébként beavatkozás nélkül visszaesik a fájlokra.

Elfér a weboldal a munkamemóriában? És mennyi RAM hiányzik?

Hogy lehetséges-e RAM-gyorsítótár, három dologtól függ: az oldalak számától, az átlagos méretüktől és a rendelkezésre álló memóriától. A vezérlőpult kiszámolja Önnek:

• Oldalszám: weboldalanként megszámolja a közzétett termékeket, a bolt listaoldalait, a kategóriákat, a blogbejegyzéseket és a bloglistákat, és megszorozza a nyelvek számával.
• Oldalméret: amint oldalak kerülnek a gyorsítótárba, a tényleges átlagot mérik; addig egy feltételezett érték érvényes.
• Hely a gyorsítótárnak: a beállított RAM-keret, a tmpfs mérete és a rendelkezésre álló munkamemória fele közül a legkisebb érték. A szerver a gyorsítótár miatt soha nem kerülhet memóriahiányba.
• Ítélet: „belefér tartalékkal”, „szűkös”, „túl nagy” vagy „a RAM-gyorsítótár nem érhető el”. A „belefér” akkor érvényes, ha az igény legfeljebb a rendelkezésre álló hely 80 százaléka.

Új: mennyi többlet-RAM lenne szükséges?

Ha a gyorsítótár nem fér el, tudni kell, mit kell megváltoztatni. A vezérlőpult ezért az ítélet alatt egy konkrét sort jelenít meg: „Többlet-RAM a RAM-gyorsítótárhoz: körülbelül … több munkamemória ezen a szerveren” – vagy „nincs”, ha a hely már elegendő. Ha nem a szerver, hanem csak egy beállítás túl kicsi, alatta megjelenik, melyik: a modul RAM-kerete vagy a tmpfs mérete (/dev/shm).

A mögötte lévő számítás egyszerű és követhető:

1. Igény = oldalak × átlagos oldalméret.
2. Tartalékkal = az igény osztva 0,8-cal. Ennek az értéknek bele kell férnie a RAM-keretbe és a tmpfs-be, hogy az ítélet „belefér” legyen.
3. Szabad memória: mivel a gyorsítótár legfeljebb a rendelkezésre álló munkamemória felét használhatja, a szervernek legalább a 2. lépés értékének kétszeresére van szüksége szabadon elérhető memóriaként. Ha valami hiányzik, a különbség a többletként szükséges RAM.

Az ábrán látható példa (12 000 oldal oldalanként 25 KB-tal) számítási segédlet, nem a mi oldalaink mérése. Kis weboldalaknál néhány tucat megabájt is elég; a képernyőképeken szereplő mintaadatok nagyjából 13 MB-tal is beértek.

Fontos a besoroláshoz: a becslés nem számolja a további árlista- vagy országváltozatokat. Aki sokat használ belőlük, számoljon némi tartalékkal. És még valami: a túl kicsi RAM-keret a leggyakoribb oka annak, hogy az automatika fájloknál marad – nem a hiányzó munkamemória. A vezérlőpult ilyenkor éppen ezt a sort mutatja.

A módosítások és a fordítások rendben tartják a gyorsítótárat

Egy gyorsítótár csak akkor használható, ha soha nem szolgál ki elavult oldalakat. Egy puszta időkorlát („tizenkét óránként eldobni”) túl durva volna: egy megváltozott árnak vagy egy kijavított elírásnak akár tizenkét órát is várnia kellene. A modul ezért tartalom alapján dolgozik.

1. Adatbázis-triggerek: minden olyan táblán, amely hatással lehet egy oldalra (termékek, változatok, képek, készlet, attribútumok, kategóriák, árak, adók, árlisták, blogbejegyzések és címkék, partner- és cégadatok, nézetek, assetek, menük, nyelvek, weboldal-beállítások), PostgreSQL-triggerek működnek. Minden módosítást beírnak egy változásnaplóba.
2. Függőségek és adatbázis-állapot: minden gyorsítótárazott oldal megjegyzi, mely rekordokat mutatja, és milyen adatbázis-állapottal készült.
3. Egyeztetés: ha van olyan naplóbejegyzés, amely ezen állapot után keletkezett, és e rekordok egyikét érinti, az oldal elavult.
4. Újragyorsítótárazás: a következő lekérésnél az elavult oldalt eldobják, újra előállítják és újra eltárolják.

A fordításokat is lefedi

Az Odoo 19 a lefordított szövegeket ugyanabban a rekordban tárolja, mint az eredeti szöveget (JSON-mezőként). Egy módosított fordítás az adatbázis számára ezért teljesen hétköznapi sormódosítás – és a trigger látja. Ez egyaránt érvényes a felületen keresztüli szerkesztésre, az importokra, az interfészekre és az adatbázisba közvetlenül író szkriptekre. A 46 nyelvre történő automatikus fordítás így pontosan azokat az oldalakat érvényteleníti, amelyeknek a szövege megváltozott, és semmi mást.

• Célzottan, nem átalányban: egy módosított termék érvényteleníti a saját oldalait, a listákat, amelyekben szerepel, és a hozzá tartozó kategóriát. A többi a gyorsítótárban marad.
• A globális módosítások (sablonok, assetek, nyelvek, menük, adók, pénznemek) mindent egyszerre érvénytelenítenek, mert bármely oldalt érinthetnek.
• A számlálók kívül maradnak: a blogbejegyzések lekérésszámlálója minden látogatásnál változik; szándékosan nem vált ki érvénytelenítést, különben a gyorsítótár a népszerű bejegyzéseknél hatástalan volna.
• Biztonsági háló: ezenkívül van oldalankénti maximális életkor (alapértelmezés szerint 12 óra).
• A gyorsítótár nem okoz írási hibát: egy triggeren belüli hibát figyelmeztetésként naplóz, és nem hiúsítja meg magát a mentést.

Vezérlőpult és statisztika

Minden, ami az üzemeltetéshez kell, egy helyen található: az Odooban a Weboldal → Jelentések → Oldal-gyorsítótár menüpont alatt. Az Áttekintés szakasz a vezérlőpult (a beállításokkal), az Alakulás szakasz a napi és weboldalankénti számokat mutatja.

Képernyőkép egy tesztrendszerből, amely a weboldalaink másolatait tartalmazza; a weboldalak nevét helyőrzőkre cseréltük.

Beállítások

Állapot és statisztika

Az állapot megmutatja az aktív tárolóhelyet a korlátjával, a gyorsítótárazott oldalak számát és méretét, valamint a változáskövetést: hány módosítást regisztráltak az elmúlt 24 órában, és hány táblát figyelnek. Ha egy figyelés hiányzik, a vezérlőpult egyértelműen figyelmeztet, mert ilyenkor a gyorsítótárban nem szabad megbízni. A felső gombokkal azonnal lefuttatható a karbantartás, kiüríthető a gyorsítótár, vagy ellenőrizhetők a triggerek, és szükség esetén újra létrehozhatók.

A statisztika (Ma, 7 nap, 30 nap) tartalmazza:

• A gyorsítótárból és Előállítva: találatok és tévesztések, ezekből a találati arány
• Eltávolítva (módosult/lejárt): hány oldalt dobtak el módosítás vagy lejárat miatt
• Előállítási idő és gyorsítótár-idő: az oldalankénti átlag összehasonlítása
• Becsült megtakarított szerveridő és a gyorsítótárból kiszolgált adatmennyiség

A számokat minden munkafolyamat külön gyűjti, és percenként egyszer írja ki; a 90 napnál régebbi sorokat a karbantartó feladat takarítja el.

Alakulás diagramként, pivotként és listaként

Az Alakulás alatt a napi értékek weboldalanként állnak rendelkezésre – diagramként, pivot táblaként vagy listaként. Így látható, hogy a találati arány újraindítás vagy nagyobb módosítás után ismét emelkedik-e, és melyik weboldal kapja a legtöbb forgalmat a gyorsítótárból.

Biztonság: ami soha nem érkezik a gyorsítótárból

Egy oldal-gyorsítótár nem vezethet oda, hogy valaki más tartalmát lássa meg egy látogató. A modul ezért az alábbi elv szerint jár el: kétség esetén ne gyorsítótározzon.

• Csak névtelen látogatók: aki be van jelentkezve, kosara van, vagy más munkamenet-állapotot hoz magával, mindig a normálisan előállított oldalt kapja.
• Csak keresési paraméter nélküli GET: a keresések, szűrők, rendezések, űrlapok, a kosár és a pénztár érintetlenek maradnak.
• Csak 200-as állapot és HTML: a hibaoldalak, átirányítások és fájlok nem kerülnek eltárolásra.
• Nincs munkamenet-azonosító a gyorsítótárban: az az oldal, amely munkamenet-azonosítót tartalmaz vagy sütit állít be, nem kerül eltárolásra (és figyelmeztetésként naplózódik).
• CSRF-token kérésenként: a gyorsítótárazott oldalban lévő token helyőrző, és minden kiszolgálásnál újra beillesztésre kerül.
• Finom kulcs: a weboldal, a nyelv, az árlista, az adópozíció és a sütik elfogadása a gyorsítótár-kulcs részei; aki mást lát, másik bejegyzést kap.
• Több adatbázis: minden adatbázisnak saját bejegyzései, saját naplója és saját statisztikája van.
• Nincs adatszivárgás: a gyorsítótár helyben, a szerveren található (fájl vagy RAM). Harmadik félnek nem kerül átvitelre adat.

Keresőmotorok és MI-indexelők: semmi sincs letiltva

Egyes üzemeltetők a crawlerterhelésre tiltással reagálnak. Ez védi a szervert, de láthatóságba kerül. A modul az ellenkező utat választja:

• Ugyanazok a tartalmak mindenkinek: a keresőmotorok, az MI-indexelők és a látogatók ugyanazt az oldalt kapják. Nincs külön „crawlerverzió”, és nincs böngészőazonosító alapján történő felismerés.
• A gyorsabb válaszok segítik az indexelést: egy 500 helyett 20 ezredmásodperc alatt válaszoló oldal kevésbé terheli a crawl budgetet, és a crawlerek ugyanannyi idő alatt több oldalt tudnak felvenni.
• Naprakész tartalmak: mivel a módosítások azonnal érvénytelenítik az oldalakat, a crawlerek soha nem látnak elavult változatot – ez fontos, ha a tartalmakat a keresés és az MI-válaszok számára gondozza.
• A strukturált adatok megmaradnak: a JSON-LD, a meta adatok és a hreflang hivatkozások a gyorsítótárazott oldal részei; a sitemapekhez és a fájlokhoz a gyorsítótár nem nyúl.

Ha ezenkívül korlátozni szeretné a terhelést, az külön döntés, amelyet tudatosan meghozhat – a modul nem kényszeríti Önre.

A HTML minimalizálása és tömörített kiszolgálása

A gyorsítótár nemcsak számítási időt, hanem adatmennyiséget is megtakarít. A modul a HTML-t tárolás előtt minimalizálja, és tömörítve szolgálja ki, ha a böngésző vagy a crawler ezt kéri:

• Minimalizálás (paraméter: website_page_cache.minify): a HTML-megjegyzések elmaradnak, a szóközök összevonásra kerülnek. Teljesen csak ott törlődnek, ahol a böngésző úgyis figyelmen kívül hagyja őket, például blokkelemek között. A soron belüli elemek közötti távolságok megmaradnak, a pre, a textarea és a szkriptek változatlanok maradnak, a strukturált adatokat (JSON-LD) kompakt formában írja újra. Oldaltól függően az oldalak 10–30 %-kal kisebbek. A hét valódi oldallal végzett tesztben a szöveg, az elemek száma, az összes elem pozíciója és a képernyőkép megegyezett az eredetivel. Az első kiszolgálás (MISS) ugyanúgy minimalizált, mint minden további (HIT).
• Tömörítés (paraméter: website_page_cache.compress): a gyorsítótárból érkező oldalak gzippel mennek ki (Content-Encoding: gzip, Vary: Accept-Encoding). A nagy asset-csomagokat (CSS és JavaScript, akár több MB) az Odoo maga tömörítetlenül szolgálja ki; a modul egyszer tömöríti őket, a másolatot a lemezre helyezi, majd közvetlenül onnan szolgálja ki. Így 2,1 MB CSS-ből 0,27 MB, 4,8 MB JavaScriptből 1,1 MB lett. A régi másolatokat a karbantartó feladat takarítja el.
• A számítógép újraindítása után: a RAM-gyorsítótár az Odoo újraindításakor megmarad, a szerver újraindításakor azonban nem. Ezért a karbantartó feladat fokozatosan tükrözi a lemezre (paraméter: website_page_cache.persist), és induláskor visszaállítja. Hogy egy visszaállított bejegyzés még érvényes-e, ugyanaz a mechanizmus ellenőrzi, mint egyébként: az életkor és a változásnapló. A minimalizálást ilyenkor nem számolják újra.

Telepítés és beállítások

1. A modul beszerzése: a forráskódot le kell tölteni a GitHubról, és az Odoo 19 telepítés egyik addons-útvonalára kell helyezni: github.com/Alex0176/odoo-website-page-cache
2. Telepítés: odoo-bin -d <Datenbank> -i website_page_cache --stop-after-init. Ennek során létrejön a változásnapló, a triggerek és a karbantartó feladat (10 percenként).
3. A szolgáltatás újraindítása, hogy az összes munkafolyamat betöltse a modult.
4. A vezérlőpult megnyitása: Weboldal → Jelentések → Oldal-gyorsítótár. Ellenőrizni kell, hogy a változáskövetés teljes-e, és ki kell választani a tárolóhelyet (alapértelmezés: automatikus).
5. Ellenőrzés: egy bolt- vagy blogoldalt kétszer kell lekérni, és megnézni a X-Page-Cache fejlécet: először MISS, utána HIT.

A beállítások rendszerparaméterként állnak rendelkezésre (website_page_cache.enabled, .backend, .ttl_hours, .max_mb_file, .max_mb_ram), és általában a vezérlőpulton kezelhetők. A modul németre le van fordítva. Az eltávolítás ismét teljesen törli a triggereket, a naplót és az összes gyorsítótárazott oldalt.

Tipp a RAM-gyorsítótárhoz: a vezérlőpulton lévő RAM-keretnek és a tmpfs méretének (/dev/shm, csatolási opció: size=) illeszkednie kell az igényhez. Mindkettőt konkrét értékekkel megadja a „Elfér a munkamemóriában?” ellenőrzés.

Korlátok, amelyeket érdemes ismerni

• Rövid késleltetés a módosítások után: a változásnapló indexe kétmásodpercenként frissül. Addig egy módosított oldal még a régi változatban is kiszolgálható.
• A készletfüggő szövegek a készletváltozások és a maximális életkor révén frissülnek.
• A helyigény becslése: az árlistánkénti vagy országonkénti további változatok nincsenek beszámítva; érdemes némi tartalékot tervezni.
• Nem pótol mindent: a gyorsítótár azokat a kéréseket tehermentesíti, amelyeket kiszolgálhat. A bejelentkezett felhasználók, a keresések és az űrlapok továbbra is az Odoón futnak át.
• Az első lekérés lassú marad: a szerver újraindítása (RAM) vagy egy globális módosítás után minden oldalt egyszer normál módon állítanak elő, mielőtt a gyorsítótárba kerülne.

Gyakori kérdések

Mi az Odoo oldal-gyorsítótára?

Egy nyílt forráskódú modul (website_page_cache, Odoo 19, LGPL-3), amely a nyilvános bolt- és blogoldalakat a névtelen látogatóknak gyorsítótárból szolgálja ki ahelyett, hogy minden lekérésnél újra előállítaná őket. A gyorsítótár választhatóan fájlokban vagy a munkamemóriában található.

Letiltja a modul a keresőmotorokat vagy az MI-crawlereket?

Nem. A keresőmotorok és az MI-indexelők ugyanazokat az oldalakat kapják, mint bármely más látogató, csak gyorsabban. Nincs tiltás, nincs lassítás, és nincs külön crawlerváltozat.

A módosított oldalak és fordítások automatikusan újra gyorsítótárazódnak?

Igen. A PostgreSQL-triggerek a releváns táblák minden módosítását jelentik egy naplónak; az érintett oldalakat eldobják, és a következő lekérésnél újra előállítják és eltárolják. A fordítások le vannak fedve, mert az Odoo 19 ugyanabban a rekordban tárolja őket.

Fájlt vagy RAM-ot válasszak?

Általában az Automatikust: a modul addig használja a RAM-ot, amíg minden oldal belefér, egyébként fájlokra tér át. A fájlok akkor alkalmasak, ha a gyorsítótárnak túl kell élnie az újraindításokat, vagy ha kevés a RAM; a RAM a leggyorsabb változat.

Honnan tudom, hogy a weboldalam elfér-e a munkamemóriában?

A vezérlőpulton a Weboldal → Jelentések → Oldal-gyorsítótár alatt. A „Elfér a munkamemóriában?” szakasz megszámolja az oldalakat weboldalanként és nyelvenként, megméri az oldalméretet, és összeveti az igényt a RAM-kerettel, a tmpfs méretével és a rendelkezésre álló memóriával.

Mennyi többlet-RAM szükséges egy RAM-gyorsítótárhoz?

A vezérlőpult külön sorban megadja. A számítás: igény = oldalak × oldalméret; biztonsági tartalékkal 0,8-cal osztva. Mivel a gyorsítótár legfeljebb a rendelkezésre álló memória felét használhatja, ennek a kétszerese a szabadon szükséges memória; a különbség a többlet-RAM. Ha csak a RAM-keret vagy a tmpfs túl kicsi, a vezérlőpult megnevezi a beállítást a célértékkel együtt.

Mutathat a gyorsítótár valakinek idegen tartalmakat?

Nem. Csak a névtelen, keresési paraméter nélküli GET lekérésekhez gyorsítótároz. A bejelentkezett felhasználók, a kosarak, az űrlapok és a keresések soha nem a gyorsítótárból érkeznek; a nyelv, az árlista, az adópozíció és a sütik elfogadása a kulcs részei.

Hogyan kapcsolom ki vészhelyzetben a gyorsítótárat?

A vezérlőpulton kapcsolja ki az „Aktív” kapcsolót, vagy állítsa a website_page_cache.enabled rendszerparamétert 0 értékre. Ez az összes munkafolyamatban legkésőbb 30 másodperc után érvényes. Az eltávolítás ezenkívül törli a triggereket, a naplót és a gyorsítótárazott oldalakat.

Honnan tudom, hogy egy oldal a gyorsítótárból érkezett?

A X-Page-Cache válaszfejlécről: a HIT gyorsítótárból érkezettet, a MISS frissen előállított és eltárolt oldalt jelent.

Kisebbé teszi és tömöríti a modul a HTML-t?

Igen. A gyorsítótárazott oldalakat konzervatívan minimalizálja (a megjegyzések és a felesleges szóközök elmaradnak, a tartalom és a megjelenés változatlan marad), a gyorsítótár-találatoknál pedig gzippel szolgálja ki; az asset-csomagokat egyszer tömöríti, és a lemezről szolgálja ki. Mindkettő kikapcsolható a website_page_cache.minify és a website_page_cache.compress paraméterrel.

A Biricon IT Services támogatása

Az Ön Odoo-weboldala crawlerterhelés alatt lassan reagál, vagy gyorsabbá és láthatóbbá szeretné tenni a boltot és a blogot? Támogatást nyújtunk a terhelés elemzésében, az oldal-gyorsítótár beállításában, a munkamemória és a munkafolyamatok méretezésében és az Odoo-weboldal többnyelvű keresőoptimalizálásában. A modul forráskódját a GitHubon találja.

Kapcsolatfelvétel most

Állapot: 2026. november 10. A mérési értékek mintaadatokkal működő tesztrendszerből származnak, és nem jelentenek ígéretet más telepítésekre.