Cache de pagini pentru Odoo: magazin și blog din RAM sau fișier – rapid pentru vizitatori, motoare de căutare și AI

10 noiembrie 2026  |  Dezvoltare proprie  |  Odoo, performanță și motoare de căutare

Un site Odoo redă fiecare pagină din nou la fiecare accesare: interogări în baza de date, șabloane, traduceri, prețuri. Pentru un singur vizitator, acest lucru trece aproape neobservat. Dar când motoarele de căutare și indexatoarele AI accesează sute sau mii de pagini în multe limbi, apare o sarcină permanentă, iar clienții reali sunt nevoiți să aștepte. De aceea am dezvoltat modulul Odoo 19 website_page_cache și l-am publicat pe GitHub ca open source (LGPL-3): paginile de magazin și de blog accesate anonim sunt livrate aproape static dintr-un cache, fie din fișiere, fie din memoria de lucru (RAM), iar orice modificare – inclusiv a unei traduceri – elimină automat din cache paginile afectate.

Important pentru toți cei care vor să fie găsiți: modulul nu blochează niciun motor de căutare și niciun crawler AI. Toate indexatoarele primesc același conținut ca orice vizitator, doar mai repede. Acest articol explică cum funcționează cache-ul, cum arată tabloul de bord (cu capturi de ecran), cum puteți afla dacă paginile dumneavoastră încap în memoria de lucru și cât RAM suplimentar ar fi necesar, ce reguli de securitate se aplică și cum instalați modulul.

Pe scurt

Problema: sarcina generată de crawlere pe site-urile Odoo

Odoo este un sistem ERP complet, iar site-ul este unul dintre numeroasele module. Fiecare pagină accesată de un vizitator sau de un robot parcurge același drum: prelucrarea cererii, interogarea bazei de date, încărcarea datelor despre produse și prețuri, redarea șablonului QWeb, inserarea traducerilor și livrarea rezultatului. În funcție de pagină, aceasta durează câteva sute de milisecunde și ocupă în acest timp unul dintre puținele procese de lucru.

Pentru motoarele de căutare și indexatoarele AI, aceasta este o problemă permanentă:

• Multe limbi, multe adrese: O pagină disponibilă în 46 de limbi înseamnă, pentru un crawler, 46 de adrese diferite.
• Fiecare adresă este accesată separat, adesea de mulți expeditori distribuiți în același timp. Un cache clasic de browser nu ajută aici, deoarece fiecare accesare privește o adresă nouă.
• Puține procese de lucru: Un serviciu Odoo rulează de obicei cu o mână de procese. Dacă acestea sunt ocupate cu cererile crawlerelor, vizitatorii reali stau la coadă.
• Același conținut, mereu din nou: Un articol de blog se schimbă rar, dar este reconstruit costisitor la fiecare accesare.

Ieșirea evidentă – blocarea crawlerelor – este exclusă pentru o firmă care vrea să fie găsită. Vizibilitatea în motoarele de căutare și în răspunsurile AI este valoroasă. Este mai bine să livrați paginile atât de repede încât sarcina să nu mai conteze aproape deloc. Exact asta face cache-ul de pagini.

Cum funcționează cache-ul de pagini

Modulul se atașează la intrarea cererilor din Odoo (ir.http). La fiecare accesare de pagină, decide în fracțiuni de milisecundă dacă pagina poate proveni din cache și o livrează apoi fără bază de date, fără șablon și fără redare.

1. Verificare: Vine în discuție doar o accesare GET anonimă, fără parametri de căutare, pe o cale permisă (magazin, categorii, produse, blog). Tot restul trece ca de obicei prin Odoo.
2. Cheia de cache: Este alcătuită din site, clasa de host, limbă, cale, listă de prețuri, poziție fiscală și starea consimțământului pentru cookie-uri. Vizitatorii care ar vedea ceva diferit nu împart, prin urmare, niciodată o intrare. Hostul este normalizat în acest scop: Odoo scrie adresele absolute întotdeauna pornind de la domeniul site-ului, nu de la cerere; adresa cererii decide doar dacă pagina este considerată adresă principală (trimiteri între limbi) și dacă trebuie indexată. Toate numele de host străine împart, așadar, o singură intrare împreună cu mențiunea noindex, în loc să ocupe fiecare propria copie.
3. Reușită: Dacă există o intrare actuală, aceasta este livrată. Tokenul CSRF din pagină este setat din nou la fiecare cerere. Accesările articolelor de blog continuă să fie numărate.
4. Ratare: Dacă intrarea lipsește sau este depășită, Odoo redă pagina ca de obicei. Dacă rezultatul poate fi pus în cache (status 200, HTML, fără cookie, fără ID de sesiune în text), el este stocat; următoarea accesare este o reușită.
5. Vizibil în antet: Fiecare răspuns poartă antetul X-Page-Cache: HIT sau MISS. Astfel, cu orice instrument se poate verifica ce s-a întâmplat.

Cu cât mai repede?

În sistemul nostru de test (copie a site-urilor noastre, câteva sute de pagini), timpul mediu de redare al unei pagini a fost de aproximativ 490 de milisecunde, iar livrarea din cache de aproximativ 23 de milisecunde: de circa douăzeci de ori mai rapid. Cu cât pagina este mai complexă, cu atât câștigul este mai mare. Din ambele valori, tabloul de bord calculează în plus timpul de server economisit, estimat.

Fișier sau RAM: alegerea locului de stocare

Cache-ul cunoaște două locuri de stocare. Ambele sunt vizibile în comun pentru toate procesele de lucru Odoo, astfel că fiecare pagină există o singură dată, nu o dată pe proces.

Pentru majoritatea instalărilor, Automat este alegerea potrivită: obțineți viteza RAM-ului când există spațiu și reveniți altfel, fără intervenție, la fișiere.

Încape site-ul în memoria de lucru? Și cât RAM lipsește?

Dacă un cache în RAM este posibil depinde de trei lucruri: de numărul de pagini, de dimensiunea lor medie și de memoria disponibilă. Tabloul de bord calculează acest lucru pentru dumneavoastră:

• Numărul de pagini: Pentru fiecare site, numără produsele publicate, paginile de listă ale magazinului, categoriile, articolele de blog și listele de blog și înmulțește cu numărul de limbi.
• Dimensiunea paginii: De îndată ce există pagini în cache, se măsoară media reală; până atunci se aplică o valoare presupusă.
• Spațiu pentru cache: cea mai mică valoare dintre bugetul RAM setat, dimensiunea tmpfs și jumătate din memoria de lucru disponibilă. Serverul nu trebuie să ajungă niciodată în lipsă de memorie din cauza cache-ului.
• Verdict: „încape cu rezervă”, „la limită”, „prea mare” sau „cache în RAM indisponibil”. „Încape” se aplică atunci când necesarul este de cel mult 80 la sută din spațiul disponibil.

Nou: Cât RAM suplimentar este necesar?

Dacă cache-ul nu încape, se dorește să se știe ce trebuie schimbat. Tabloul de bord indică de aceea, sub verdict, o linie concretă: „RAM suplimentar pentru un cache în RAM: aproximativ … memorie de lucru în plus pe acest server” – sau „niciunul”, dacă spațiul este deja suficient. Dacă nu serverul, ci doar o setare este prea mică, dedesubt se indică care anume: bugetul RAM al modulului sau dimensiunea tmpfs (/dev/shm).

Calculul din spate este simplu și ușor de urmărit:

1. Necesar = pagini × dimensiunea medie a paginii.
2. Cu rezervă = necesar împărțit la 0,8. Această valoare trebuie să încapă în bugetul RAM și în tmpfs, pentru ca verdictul să fie „încape”.
3. Memorie liberă: Deoarece cache-ul poate folosi cel mult jumătate din memoria de lucru disponibilă, serverul are nevoie de cel puțin dublul valorii de la pasul 2 sub formă de memorie liberă disponibilă. Dacă lipsește ceva, diferența reprezintă RAM-ul suplimentar necesar.

Exemplul din imagine (12.000 de pagini a câte 25 KB) este un ajutor de calcul, nu o măsurătoare a paginilor noastre. La site-urile mici sunt suficiente câteva zeci de megabyți; datele de exemplu din capturile de ecran s-au încadrat în circa 13 MB.

Important pentru încadrare: estimarea nu include versiuni suplimentare pentru liste de prețuri sau țări. Cine folosește multe dintre ele își planifică o anumită rezervă. Și: un buget RAM prea mic este cel mai frecvent motiv pentru care automatizarea rămâne pe fișiere – nu lipsa memoriei de lucru. În acest caz, tabloul de bord afișează exact această linie.

Modificările și traducerile curăță cache-ul

Un cache este utilizabil doar dacă nu livrează niciodată pagini depășite. O simplă limită de timp („se aruncă la fiecare douăsprezece ore”) ar fi prea grosieră: un preț modificat sau o greșeală de scriere corectată ar trebui să aștepte până la douăsprezece ore. De aceea modulul lucrează în funcție de conținut.

1. Declanșatoare de bază de date: Pe toate tabelele care pot influența o pagină (produse, variante, imagini, stoc, atribute, categorii, prețuri, taxe, liste de prețuri, articole de blog și etichete, date de parteneri și de firme, vizualizări, active, meniuri, limbi, setările site-ului) se află declanșatoare PostgreSQL. Ele înregistrează fiecare modificare într-un jurnal de modificări.
2. Dependențe și starea bazei de date: Fiecare pagină din cache reține ce înregistrări afișează și starea bazei de date cu care a fost generată.
3. Comparare: Dacă există o intrare în jurnal apărută după această stare și care privește una dintre aceste înregistrări, pagina este depășită.
4. Punere din nou în cache: La următoarea accesare, pagina depășită este aruncată, redată din nou și stocată iar.

Și traducerile sunt acoperite

Odoo 19 stochează textele traduse în aceeași înregistrare cu textul original (ca un câmp JSON). O traducere modificată este, așadar, pentru baza de date o modificare obișnuită de rând – iar declanșatorul o vede. Acest lucru este valabil în egală măsură pentru editarea prin interfață, pentru importuri, pentru interfețe de integrare și pentru scripturile care scriu direct în baza de date. O traducere automată în 46 de limbi invalidează astfel exact paginile al căror text s-a schimbat, și nu mai multe.

• Țintit, nu global: Un produs modificat invalidează paginile sale, listele în care apare și categoria aferentă. Restul rămâne în cache.
• Modificările globale (șabloane, active, limbi, meniuri, taxe, monede) invalidează totul deodată, deoarece pot afecta orice pagină.
• Contoarele rămân în afară: Contorul de vizualizări al articolelor de blog se schimbă la fiecare vizită; el nu declanșează în mod deliberat nicio invalidare, altfel cache-ul ar fi ineficient pentru articolele populare.
• Plasă de siguranță: În plus, există o vârstă maximă pentru fiecare pagină (implicit 12 ore).
• Nicio eroare de scriere din cauza cache-ului: O eroare în interiorul unui declanșator este înregistrată ca avertisment și nu face să eșueze salvarea propriu-zisă.

Tablou de bord și statistici

Tot ce vă trebuie pentru exploatare se află într-un singur loc: în Odoo, la Site web → Rapoarte → Cache de pagini. Secțiunea Prezentare generală este tabloul de bord (cu setările), secțiunea Evoluție arată cifrele pe zile și pe site.

Captură de ecran dintr-un sistem de test cu copii ale site-urilor noastre; numele site-urilor au fost înlocuite cu substituenți.

Setări

Stare și statistici

Starea arată locul de stocare activ împreună cu limita, numărul și dimensiunea paginilor din cache și urmărirea modificărilor: câte modificări au fost înregistrate în ultimele 24 de ore și câte tabele sunt monitorizate. Dacă lipsește o monitorizare, tabloul de bord avertizează clar, deoarece atunci cache-ul nu mai trebuie considerat de încredere. Butoanele de sus permit executarea imediată a întreținerii, golirea cache-ului sau verificarea declanșatoarelor și, la nevoie, recrearea lor.

Statisticile (Astăzi, 7 zile, 30 de zile) cuprind:

• Din cache și Redat: reușite și ratări, iar din ele rata de reușită
• Eliminate (modificate/expirate): câte pagini au fost aruncate din cauza unei modificări sau a expirării
• Timp de redare și timp din cache: media pe pagină, în comparație
• Timp de server economisit, estimat și volum de date din cache

Cifrele sunt colectate de fiecare proces de lucru separat și scrise o dată pe minut; rândurile mai vechi de 90 de zile sunt curățate de sarcina de întreținere.

Evoluția ca diagramă, tabel pivot și listă

La Evoluție sunt disponibile valorile zilnice pe site – ca diagramă, ca tabel pivot sau ca listă. Astfel vedeți dacă rata de reușită crește din nou după o repornire sau după o modificare mare și care site primește cel mai mult trafic din cache.

Securitate: ce nu provine niciodată din cache

Un cache de pagini nu are voie să ducă niciodată la situația în care cineva vede conținutul altcuiva. Modulul procedează de aceea după principiul: la îndoială, nu se pune în cache.

• Doar vizitatori anonimi: Cine este autentificat, are un coș de cumpărături sau aduce o altă stare de sesiune primește întotdeauna pagina redată normal.
• Doar GET fără parametri de căutare: Căutările, filtrele, sortările, formularele, coșul și finalizarea comenzii rămân neatinse.
• Doar status 200 și HTML: Paginile de eroare, redirecționările și fișierele nu sunt stocate.
• Fără ID-uri de sesiune în cache: O pagină care conține un ID de sesiune sau setează un cookie nu este stocată (și este înregistrată ca avertisment).
• Token CSRF la fiecare cerere: Tokenul din pagina din cache este un substituent și este inserat din nou la fiecare livrare.
• Cheie fină: Site-ul, limba, lista de prețuri, poziția fiscală și consimțământul pentru cookie-uri fac parte din cheia de cache; cine vede altceva primește o altă intrare.
• Mai multe baze de date: Fiecare bază de date are propriile intrări, propriul jurnal și propriile statistici.
• Fără scurgeri de date: Cache-ul se află local pe server (fișier sau RAM). Nu se transmit date către terți.

Motoare de căutare și indexatoare AI: nimic nu este blocat

Unii operatori reacționează la sarcina crawlerelor prin blocări. Acest lucru protejează serverul, dar costă vizibilitate. Modulul alege calea inversă:

• Același conținut pentru toți: Motoarele de căutare, indexatoarele AI și vizitatorii primesc aceeași pagină. Nu există o „versiune pentru crawlere” separată și nicio recunoaștere după identificatorul browserului.
• Răspunsurile mai rapide ajută indexarea: O pagină care răspunde în 20 în loc de 500 de milisecunde încarcă mai puțin bugetul de crawl, iar crawlerele pot parcurge mai multe pagini în același timp.
• Conținut actual: Deoarece modificările invalidează imediat paginile, crawlerele nu văd niciodată o versiune depășită – important dacă întrețineți conținut pentru căutare și pentru răspunsurile AI.
• Datele structurate se păstrează: JSON-LD, informațiile meta și trimiterile hreflang fac parte din pagina din cache; hărțile de site și fișierele nu sunt atinse de cache.

Dacă doriți, în plus, să limitați sarcina, aceasta este o decizie separată pe care o puteți lua în mod conștient – modulul nu v-o impune.

Minimizarea HTML și livrarea comprimată

Cache-ul nu economisește doar timp de calcul, ci și volum de date. Modulul minimizează HTML-ul înainte de a-l stoca și îl livrează comprimat când browserul sau crawlerul oferă această posibilitate:

• Minimizare (parametrul website_page_cache.minify): comentariile HTML dispar, spațiile albe sunt comasate. Ele sunt eliminate complet doar acolo unde browserul oricum le ignoră, de exemplu între elementele de tip bloc. Spațiile dintre elementele inline se păstrează, pre, textarea și scripturile rămân neschimbate, datele structurate (JSON-LD) sunt rescrise compact. În funcție de pagină, paginile sunt cu 10 până la 30 % mai mici. La testul cu șapte pagini reale, textul, numărul de elemente, poziția tuturor elementelor și captura de ecran au fost identice cu originalul. Prima livrare (MISS) este minimizată exact ca oricare următoare (HIT).
• Comprimare (parametrul website_page_cache.compress): Paginile din cache pleacă prin gzip (Content-Encoding: gzip, Vary: Accept-Encoding). Pachetele mari de active (CSS și JavaScript, de până la câțiva MB) sunt livrate de Odoo însuși necomprimate; modulul le comprimă o singură dată, depune copia pe disc și le livrează apoi direct. Din 2,1 MB de CSS au rezultat astfel 0,27 MB, din 4,8 MB de JavaScript 1,1 MB. Copiile vechi sunt curățate de sarcina de întreținere.
• După o repornire a mașinii: Cache-ul în RAM se păstrează la repornirile Odoo, dar nu la repornirea serverului. De aceea sarcina de întreținere îl oglindește treptat pe disc (parametrul website_page_cache.persist) și îl restaurează la pornire. Dacă o intrare restaurată mai este valabilă, verifică același mecanism ca de obicei: vârsta și jurnalul de modificări. Minimizarea nu este recalculată în acest caz.

Instalare și setări

1. Obținerea modulului: Descărcați codul sursă de pe GitHub și plasați-l într-o cale addons a instalării dumneavoastră Odoo 19: github.com/Alex0176/odoo-website-page-cache
2. Instalare: odoo-bin -d <Datenbank> -i website_page_cache --stop-after-init. În acest proces se creează jurnalul de modificări, declanșatoarele și sarcina de întreținere (la fiecare 10 minute).
3. Reporniți serviciul, pentru ca toate procesele de lucru să încarce modulul.
4. Deschideți tabloul de bord: Site web → Rapoarte → Cache de pagini. Verificați dacă urmărirea modificărilor este completă și alegeți locul de stocare (presetare: automat).
5. Verificare: Accesați de două ori o pagină de magazin sau de blog și priviți antetul X-Page-Cache: prima dată MISS, apoi HIT.

Setările există sub formă de parametri de sistem (website_page_cache.enabled, .backend, .ttl_hours, .max_mb_file, .max_mb_ram) și sunt gestionate în mod normal în tabloul de bord. Modulul este tradus în germană. Dezinstalarea elimină din nou complet declanșatoarele, jurnalul și toate paginile din cache.

Sfat pentru cache-ul în RAM: bugetul RAM din tabloul de bord și dimensiunea tmpfs (/dev/shm, opțiunea de montare size=) trebuie să corespundă necesarului. Ambele vă sunt indicate, cu valori concrete, de verificarea „Încape în memoria de lucru?”.

Limite pe care trebuie să le cunoașteți

• Scurtă întârziere după modificări: Indexul jurnalului de modificări este reîmprospătat la fiecare două secunde. Până atunci, o pagină modificată poate fi încă livrată în versiunea veche.
• Textele dependente de stoc sunt actualizate prin modificările de stoc și prin vârsta maximă.
• Estimarea necesarului de spațiu: Versiunile suplimentare pentru fiecare listă de prețuri sau țară nu sunt incluse; planificați o anumită rezervă.
• Nu înlocuiește totul: Cache-ul degrevează cererile pe care are voie să le servească. Utilizatorii autentificați, căutările și formularele trec în continuare prin Odoo.
• Prima accesare rămâne lentă: După o repornire a serverului (RAM) sau după o modificare globală, fiecare pagină este redată o dată normal înainte de a ajunge în cache.

Întrebări frecvente

Ce este cache-ul de pagini pentru Odoo?

Un modul open source (website_page_cache, Odoo 19, LGPL-3) care livrează paginile publice de magazin și de blog pentru vizitatorii anonimi dintr-un cache, în loc să le redea din nou la fiecare accesare. Cache-ul se află, la alegere, în fișiere sau în memoria de lucru.

Blochează modulul motoarele de căutare sau crawlerele AI?

Nu. Motoarele de căutare și indexatoarele AI primesc aceleași pagini ca orice alt vizitator, doar mai repede. Nu există blocare, limitare sau o versiune separată pentru crawlere.

Paginile modificate și traducerile sunt puse automat din nou în cache?

Da. Declanșatoarele PostgreSQL raportează fiecare modificare a tabelelor relevante către un jurnal; paginile afectate sunt aruncate și, la următoarea accesare, redate din nou și stocate. Traducerile sunt acoperite, deoarece Odoo 19 le stochează în aceeași înregistrare.

Să aleg fișier sau RAM?

De regulă Automat: modulul folosește RAM-ul cât timp toate paginile încap și trece altfel la fișiere. Fișierele sunt potrivite dacă cache-ul trebuie să supraviețuiască repornirilor sau dacă RAM-ul este limitat; RAM-ul este varianta cea mai rapidă.

Cum aflu dacă site-ul meu încape în memoria de lucru?

În tabloul de bord, la Site web → Rapoarte → Cache de pagini. Secțiunea „Încape în memoria de lucru?” numără paginile pe site și pe limbă, măsoară dimensiunea paginii și compară necesarul cu bugetul RAM, cu dimensiunea tmpfs și cu memoria disponibilă.

Cât RAM suplimentar este necesar pentru un cache în RAM?

Tabloul de bord îl indică pe o linie separată. Calculul este: necesar = pagini × dimensiunea paginii; cu rezervă de siguranță, împărțit la 0,8. Deoarece cache-ul poate folosi cel mult jumătate din memoria disponibilă, dublul acestei valori este memoria liberă necesară; diferența este RAM-ul suplimentar. Dacă doar bugetul RAM sau tmpfs este prea mic, tabloul de bord indică setarea împreună cu valoarea-țintă.

Poate cache-ul să arate cuiva conținutul altcuiva?

Nu. Se pun în cache doar accesările GET anonime, fără parametri de căutare. Utilizatorii autentificați, coșurile, formularele și căutările nu provin niciodată din cache; limba, lista de prețuri, poziția fiscală și consimțământul pentru cookie-uri fac parte din cheie.

Cum opresc cache-ul în caz de urgență?

În tabloul de bord, dezactivați comutatorul „Activ” sau setați parametrul de sistem website_page_cache.enabled la 0. Aceasta se aplică în toate procesele de lucru în cel mult 30 de secunde. O dezinstalare elimină, în plus, declanșatoarele, jurnalul și paginile din cache.

Cum îmi dau seama dacă o pagină a venit din cache?

După antetul de răspuns X-Page-Cache: HIT înseamnă din cache, MISS înseamnă redată proaspăt și stocată.

Face modulul HTML-ul mai mic și îl comprimă?

Da. Paginile din cache sunt minimizate conservator (comentariile și spațiile albe inutile dispar, conținutul și aspectul rămân aceleași) și, la reușitele din cache, livrate prin gzip; pachetele de active sunt comprimate o singură dată și livrate de pe disc. Ambele pot fi dezactivate prin parametrii website_page_cache.minify și website_page_cache.compress.

Asistență din partea Biricon IT Services

Site-ul dumneavoastră Odoo reacționează lent la sarcina generată de crawlere sau doriți să faceți magazinul și blogul mai rapide și mai vizibile? Vă sprijinim la analiza sarcinii, la configurarea cache-ului de pagini, la dimensionarea memoriei de lucru și a proceselor de lucru și la optimizarea multilingvă pentru motoarele de căutare a site-ului dumneavoastră Odoo. Codul sursă al modulului îl găsiți pe GitHub.

Luați legătura acum

Data: 10 noiembrie 2026. Valorile măsurate provin dintr-un sistem de test cu date de exemplu și nu reprezintă o garanție pentru alte instalări.