Кэш старонак для Odoo: крама і блог з RAM або файла – хутка для наведвальнікаў, пошукавых сістэм і ШІ

10 лістапада 2026  |  Уласная распрацоўка  |  Odoo, прадукцыйнасць і пошукавыя сістэмы

Вэб-сайт на Odoo фармуе кожную старонку нанова пры кожным звароце: запыты да базы даных, шаблоны, пераклады, цэны. Для аднаго наведвальніка гэта незаўважна. Але калі пошукавыя сістэмы і ШІ-індэксатары запытваюць сотні ці тысячы старонак на многіх мовах, узнікае пастаянная нагрузка, і сапраўдныя кліенты вымушаны чакаць. Таму мы распрацавалі модуль для Odoo 19 website_page_cache і апублікавалі яго на GitHub як Open Source (LGPL-3): старонкі крамы і блога, якія запытваюцца ананімна, выдаюцца амаль як статычныя з кэша – альбо з файлаў, альбо з аператыўнай памяці (RAM), а кожная змена – у тым ліку перакладу – аўтаматычна выдаляе закрануты старонкі з кэша.

Важна для ўсіх, хто хоча, каб іх знаходзілі: модуль не блакуе ніводную пошукавую сістэму і ніводнага ШІ-краўлера. Усе індэксатары атрымліваюць тое ж змесціва, што і кожны наведвальнік, толькі хутчэй. У гэтым артыкуле тлумачыцца, як працуе кэш, як выглядае панэль кіравання (са здымкамі экрана), як вызначыць, ці змяшчаюцца вашы старонкі ў аператыўную памяць і колькі дадатковай RAM спатрэбілася б, якія правілы бяспекі дзейнічаюць і як усталяваць модуль.

Коратка

Праблема: нагрузка ад краўлераў на вэб-сайты Odoo

Odoo – поўнафункцыянальная ERP-сістэма, а вэб-сайт – адзін з многіх яе модуляў. Кожная старонка, да якой звяртаецца наведвальнік або робат, праходзіць адзін і той жа шлях: апрацоўка запыту, зварот да базы даных, загрузка звестак пра тавары і цэны, рэндэрынг шаблона QWeb, падстаноўка перакладаў і выдача выніку. У залежнасці ад старонкі гэта займае некалькі соцень мілісекунд і на гэты час займае адзін з нешматлікіх працоўных працэсаў.

Для пошукавых сістэм і ШІ-індэксатараў гэта пастаянная праблема:

• Шмат моў, шмат адрасоў: старонка, даступная на 46 мовах, для краўлера складаецца з 46 розных адрасоў.
• Кожны адрас запытваецца асобна, часта адначасова ад многіх размеркаваных адпраўнікоў. Класічны кэш браўзера тут не дапамагае, бо кожны запыт датычыцца новага адраса.
• Мала працоўных працэсаў: служба Odoo звычайна працуе з некалькімі працэсамі. Калі яны занятыя запытамі краўлераў, сапраўдныя наведвальнікі стаяць у чарзе.
• Тое ж змесціва зноў і зноў: артыкул блога змяняецца рэдка, але пры кожным звароце яго нанова складаюць з вялікімі выдаткамі.

Відавочны выхад – закрыць доступ краўлерам – не варыянт для кампаніі, якая хоча, каб яе знаходзілі. Бачнасць у пошукавых сістэмах і ў адказах ШІ каштоўная. Лепш выдаваць старонкі так хутка, каб нагрузка амаль не адчувалася. Менавіта гэта і робіць кэш старонак.

Як працуе кэш старонак

Модуль падключаецца да ўваходу запытаў Odoo (ir.http). Пры кожным звароце да старонкі ён за долі мілісекунды вырашае, ці можна выдаць старонку з кэша, і тады выдае яе без базы даных, без шаблона і без рэндэрынгу.

1. Праверка: разглядаецца толькі ананімны GET-запыт без параметраў пошуку на дазволены шлях (крама, катэгорыі, тавары, блог). Усё астатняе праходзіць праз Odoo, як заўсёды.
2. Ключ кэша: ён складаецца з вэб-сайта, класа хоста, мовы, шляху, прайскуранта, падатковай пазіцыі і стану згоды на cookie. Таму наведвальнікі, якія ўбачылі б нешта іншае, ніколі не падзяляюць адзін запіс. Хост пры гэтым нармалізуецца: Odoo заўсёды запісвае абсалютныя адрасы з дамена вэб-сайта, а не з запыту; адрас запыту вырашае толькі, ці лічыцца старонка асноўным адрасам (спасылкі на мовы) і ці трэба яе індэксаваць. Усе староннія імёны хостаў таму падзяляюць адзін запіс разам з указаннем noindex, замест таго каб займаць па ўласнай копіі.
3. Трапленне: калі ёсць актуальны запіс, ён выдаецца. CSRF-токен у старонцы пры гэтым усталёўваецца нанова для кожнага запыту. Праглядзі артыкулаў блога па-ранейшаму ўлічваюцца.
4. Промах: калі запісу няма або ён састарэў, Odoo рэндэрыць старонку, як звычайна. Калі вынік можна кэшаваць (статус 200, HTML, без cookie, без ідэнтыфікатара сесіі ў тэксце), ён захоўваецца; наступны запыт будзе трапленнем.
5. Бачна ў загалоўку: кожны адказ змяшчае загаловак X-Page-Cache: HIT або MISS. Так любым інструментам можна праверыць, што адбылося.

Наколькі хутчэй?

У нашай тэставай сістэме (копія нашых вэб-сайтаў, некалькі соцень старонак) сярэдні час рэндэрынгу старонкі складаў каля 490 мілісекунд, а выдача з кэша – каля 23 мілісекунд: прыкладна ў дваццаць разоў хутчэй. Чым складанейшая старонка, тым большая выгада. З абодвух значэнняў панэль кіравання таксама разлічвае прыблізна зэканомлены час сервера.

Файл ці RAM: выбар месца захоўвання

Кэш мае два месцы захоўвання. Абодва бачныя ўсім працоўным працэсам Odoo разам, таму кожная старонка існуе толькі ў адным экзэмпляры, а не па адным на працэс.

Для большасці ўсталёвак Аўтаматычна – правільны выбар: вы атрымліваеце хуткасць RAM, калі ёсць месца, а інакш без ўмяшання пераходзіце на файлы.

Ці змяшчаецца вэб-сайт у аператыўную памяць? І колькі RAM не стае?

Ці магчымы кэш у RAM, залежыць ад трох фактараў: ад колькасці старонак, ад іх сярэдняга памеру і ад даступнай памяці. Панэль кіравання разлічвае гэта за вас:

• Колькасць старонак: для кожнага вэб-сайта лічыць апублікаваныя тавары, старонкі спісаў крамы, катэгорыі, артыкулы блога і спісы блога і памнажае на колькасць моў.
• Памер старонак: калі старонкі ўжо ў кэшы, вымяраецца фактычная сярэдняя велічыня; да таго часу ўжываецца прыблізнае значэнне.
• Месца пад кэш: найменшае са значэнняў бюджэту RAM, памеру tmpfs і паловы даступнай аператыўнай памяці. Сервер ніколі не павінен трапляць у недахоп памяці з-за кэша.
• Вердыкт: «змяшчаецца з запасам», «на мяжы», «занадта вялікі» або «кэш у RAM недаступны». «Змяшчаецца» дзейнічае, калі патрэба складае не больш за 80 працэнтаў даступнага месца.

Новае: колькі дадатковай RAM спатрэбілася б?

Калі кэш не змяшчаецца, хочацца ведаць, што трэба змяніць. Таму панэль кіравання пад вердыктам паказвае канкрэтны радок: «Дадатковая RAM для кэша ў RAM: прыблізна … больш аператыўнай памяці на гэтым серверы» – або «не патрэбна», калі месца ўжо хапае. Калі замест сервера замалая толькі адна з налад, ніжэй паказана, якая іменна: бюджэт RAM модуля або памер tmpfs (/dev/shm).

Разлік за гэтым просты і празрысты:

1. Патрэба = старонкі × сярэдні памер старонкі.
2. З запасам = патрэба, падзеленая на 0,8. Гэта значэнне павінна змяшчацца ў бюджэт RAM і ў tmpfs, каб вердыкт гучаў «змяшчаецца».
3. Вольная памяць: паколькі кэш можа выкарыстоўваць не больш за палову даступнай аператыўнай памяці, серверу патрэбна як мінімум удвая большае за значэнне з кроку 2 вольнай даступнай памяці. Калі чаго-небудзь не стае, розніца і ёсць неабходная дадатковая RAM.

Прыклад на малюнку (12 000 старонак па 25 KB) – дапаможны разлік, а не вымярэнне нашых старонак. Для невялікіх вэб-сайтаў дастаткова некалькіх дзясяткаў мегабайтаў; прыкладныя даныя на здымках экрана абыходзіліся прыблізна 13 MB.

Важна для правільнай ацэнкі: ацэнка не ўлічвае дадатковыя версіі па прайскурантах або краінах. Хто карыстаецца імі шмат, павінен планаваць пэўны запас. І яшчэ: замалы бюджэт RAM – найчасцейшая прычына, чаму аўтаматыка застаецца на файлах, а не недахоп аператыўнай памяці. Панэль кіравання ў такім выпадку паказвае менавіта гэты радок.

Змены і пераклады ачышчаюць кэш

Кэш прыдатны, толькі калі ён ніколі не выдае састарэлыя старонкі. Простае абмежаванне па часе («адкідаць кожныя дванаццаць гадзін») было б занадта грубым: змененая цана або выпраўленая памылка друку чакалі б да дванаццаці гадзін. Таму модуль працуе па змесціве.

1. Трыгеры базы даных: на ўсіх табліцах, якія могуць уплываць на старонку (тавары, варыянты, выявы, запасы, атрыбуты, катэгорыі, цэны, падаткі, прайскуранты, артыкулы блога і тэгі, даныя партнёраў і кампаній, прадстаўленні, актывы, меню, мовы, налады вэб-сайта), стаяць трыгеры PostgreSQL. Яны запісваюць кожную змену ў журнал змен.
2. Залежнасці і стан базы даных: кожная кэшаваная старонка памятае, якія запісы яна паказвае, і стан базы даных, з якім яна была створана.
3. Звяранне: калі ёсць запіс журнала, які ўзнік пасля гэтага стану і датычыцца аднаго з гэтых запісаў, старонка састарэла.
4. Нанова кэшаваць: пры наступным звароце састарэлая старонка адкідаецца, рэндэрыцца нанова і зноў захоўваецца.

Пераклады таксама ўлічаны

Odoo 19 захоўвае перакладзеныя тэксты ў тым жа запісе, што і зыходны тэкст (як поле JSON). Змена перакладу для базы даных – таму звычайная змена радка, і трыгер яе бачыць. Гэта аднолькава дзейнічае для рэдагавання праз інтэрфейс, для імпартаў, для інтэрфейсаў да іншых сістэм і для скрыптоў, якія пішуць наўпрост у базу даных. Аўтаматычны пераклад на 46 моў прызнае састарэлымі роўна тыя старонкі, тэкст якіх змяніўся, і не больш.

• Дакладна, а не наогул: зменены тавар робіць састарэлымі свае старонкі, спісы, у якіх ён ёсць, і адпаведную катэгорыю. Астатняе застаецца ў кэшы.
• Глабальныя змены (шаблоны, актывы, мовы, меню, падаткі, валюты) робяць састарэлым усё адразу, бо могуць закрануць кожную старонку.
• Лічыльнікі не ўлічваюцца: лічыльнік праглядаў артыкулаў блога мяняецца пры кожным наведванні; ён наўмысна не выклікае прызнання састарэлым, інакш кэш быў бы бескарысны для папулярных артыкулаў.
• Страхоўка: дадаткова існуе максімальны ўзрост кожнай старонкі (па змаўчанні 12 гадзін).
• Кэш не выклікае памылкі запісу: памылка ўнутры трыгера фіксуецца як папярэджанне і не прыводзіць да збою самога захавання.

Панэль кіравання і статыстыка

Усё, што патрэбна для эксплуатацыі, знаходзіцца ў адным месцы: у Odoo пад Вэб-сайт → Справаздачы → Кэш старонак. Раздзел Агляд – гэта панэль кіравання (з наладамі), раздзел Гісторыя паказвае лічбы па днях і вэб-сайтах.

Здымак экрана тэставай сістэмы з копіямі нашых вэб-сайтаў; назвы вэб-сайтаў заменены на ўмоўныя.

Налады

Стан і статыстыка

Стан паказвае актыўнае месца захоўвання з лімітам, колькасць і памер кэшаваных старонак і адсочванне змен: колькі змен зарэгістравана за апошнія 24 гадзіны і колькі табліц кантралюецца. Калі кантроль адсутнічае, панэль кіравання выразна папярэджвае, бо тады кэшу нельга давяраць. Кнопкі ўверсе дазваляюць неадкладна выканаць абслугоўванне, ачысціць кэш або праверыць трыгеры і пры патрэбе стварыць іх нанова.

Статыстыка (Сёння, 7 дзён, 30 дзён) ўключае:

• З кэша і Адрэндэрана: трапленні і промахі, з іх працэнт трапленняў
• Выдалена (зменена/скончыўся тэрмін): колькі старонак адкінута з-за змены або заканчэння тэрміну
• Час рэндэрынгу і час кэша: сярэдняе на старонку ў параўнанні
• Прыблізна зэканомлены час сервера і аб'ём даных з кэша

Лічбы збірае кожны працоўны працэс асобна і запісвае раз у хвіліну; радкі старэйшыя за 90 дзён служба абслугоўвання выдаляе.

Гісторыя ў выглядзе дыяграмы, зводнай табліцы і спісу

Пад Гісторыя даступныя штодзённыя значэнні для кожнага вэб-сайта – у выглядзе дыяграмы, зводнай (pivot) табліцы або спісу. Так вы бачыце, ці расце працэнт трапленняў пасля перазапуску або вялікай змены, і які вэб-сайт атрымлівае найбольшы трафік з кэша.

Бяспека: што ніколі не выдаецца з кэша

Кэш старонак ніколі не павінен прыводзіць да таго, што адзін чалавек бачыць змесціва іншага. Таму модуль кіруецца прынцыпам: пры сумненні не кэшаваць.

• Толькі ананімныя наведвальнікі: хто ўвайшоў у сістэму, мае кошык або іншы стан сесіі, заўсёды атрымлівае звычайна адрэндэраную старонку.
• Толькі GET без параметраў пошуку: пошук, фільтры, сартаванні, формы, кошык і афармленне замовы застаюцца непакранутымі.
• Толькі статус 200 і HTML: старонкі памылак, перанакіраванні і файлы не захоўваюцца.
• Ніякіх ідэнтыфікатараў сесій у кэшы: старонка, якая змяшчае ідэнтыфікатар сесіі або ўсталёўвае cookie, не захоўваецца (і фіксуецца як папярэджанне).
• CSRF-токен для кожнага запыту: токен у кэшаванай старонцы – запаўняльнік і ўстаўляецца нанова пры кожнай выдачы.
• Дакладны ключ: вэб-сайт, мова, прайскурант, падатковая пазіцыя і згода на cookie ўваходзяць у ключ кэша; хто бачыць нешта іншае, атрымлівае іншы запіс.
• Некалькі баз даных: кожная база даных мае свае запісы, свой журнал і сваю статыстыку.
• Ніякага ўцёку даных: кэш знаходзіцца лакальна на серверы (файл або RAM). Даныя трэцім асобам не перадаюцца.

Пошукавыя сістэмы і ШІ-індэксатары: нічога не блакуецца

Некаторыя аператары рэагуюць на нагрузку ад краўлераў блакаваннем. Гэта абараняе сервер, але каштуе бачнасці. Модуль выбірае зваротны шлях:

• Аднолькавае змесціва для ўсіх: пошукавыя сістэмы, ШІ-індэксатары і наведвальнікі атрымліваюць адну і тую ж старонку. Няма асобнай «версіі для краўлераў» і няма распазнавання па ідэнтыфікатары браўзера.
• Больш хуткія адказы дапамагаюць індэксацыі: старонка, якая адказвае за 20, а не за 500 мілісекунд, менш нагружае бюджэт абходу (crawl budget), і краўлеры могуць за той жа час апрацаваць больш старонак.
• Актуальнае змесціва: паколькі змены адразу робяць старонкі састарэлымі, краўлеры ніколі не бачаць састарэлую версію – важна, калі вы падтрымліваеце змесціва для пошуку і адказаў ШІ.
• Структураваныя даныя захоўваюцца: JSON-LD, метаданыя і спасылкі hreflang уваходзяць у кэшаваную старонку; карты сайта і файлы кэш не кране.

Калі вы хочаце дадаткова абмежаваць нагрузку, гэта асобнае рашэнне, якое вы можаце прыняць свядома – модуль не навязвае яго вам.

Мінімізацыя HTML і выдача ў сціснутым выглядзе

Кэш эканоміць не толькі час вылічэнняў, але і аб'ём даных. Модуль мінімізуе HTML перад захаваннем і выдае яго сціснутым, калі браўзер або краўлер гэта падтрымлівае:

• Мінімізацыя (параметр website_page_cache.minify): каментарыі HTML выдаляюцца, прабелы аб'ядноўваюцца. Цалкам яны выдаляюцца толькі там, дзе браўзер іх усё роўна ігнаруе, напрыклад паміж блокавымі элементамі. Адлегласці паміж убудаванымі (inline) элементамі захоўваюцца, pre, textarea і скрыпты застаюцца без змен, структураваныя даныя (JSON-LD) перапісваюцца кампактна. У залежнасці ад старонкі яны на 10–30 % меншыя. Пры тэсце з сямю сапраўднымі старонкамі тэкст, колькасць элементаў, пазіцыя ўсіх элементаў і здымак экрана былі ідэнтычныя арыгіналу. Першая выдача (MISS) мінімізавана гэтак жа, як і кожная наступная (HIT).
• Сціск (параметр website_page_cache.compress): старонкі з кэша адпраўляюцца праз gzip (Content-Encoding: gzip, Vary: Accept-Encoding). Вялікія пакеты актываў (CSS і JavaScript, да некалькіх MB) Odoo выдае сам несціснутымі; модуль сціскае іх адзін раз, захоўвае копію на дыску і пасля выдае яе наўпрост. Так з 2,1 MB CSS атрымалася 0,27 MB, а з 4,8 MB JavaScript – 1,1 MB. Старыя копіі прыбірае службовая задача.
• Пасля перазапуску кампутара: кэш у RAM захоўваецца пры перазапусках Odoo, але не пры перазапуску сервера. Таму службовая задача паступова адлюстроўвае яго на дыск (параметр website_page_cache.persist) і аднаўляе пры запуску. Ці ўсё яшчэ дзейсны адноўлены запіс, правярае той жа механізм, што і звычайна: узрост і журнал змен. Мінімізацыя пры гэтым нанова не вылічаецца.

Усталяванне і налады

1. Атрымаць модуль: спампаваць зыходны код з GitHub і змясціць у шлях addons вашай усталёўкі Odoo 19: github.com/Alex0176/odoo-website-page-cache
2. Усталяваць: odoo-bin -d <Datenbank> -i website_page_cache --stop-after-init. Пры гэтым ствараюцца журнал змен, трыгеры і службовая задача (кожныя 10 хвілін).
3. Перазапусціць службу, каб усе працоўныя працэсы загрузілі модуль.
4. Адкрыць панэль кіравання: Вэб-сайт → Справаздачы → Кэш старонак. Праверыць, ці поўнае адсочванне змен, і выбраць месца захоўвання (па змаўчанні: аўтаматычна).
5. Праверыць: двойчы запытаць старонку крамы або блога і паглядзець загаловак X-Page-Cache: першы раз MISS, потым HIT.

Налады захоўваюцца як сістэмныя параметры (website_page_cache.enabled, .backend, .ttl_hours, .max_mb_file, .max_mb_ram) і звычайна рэдагуюцца ў панэлі кіравання. Модуль перакладзены на нямецкую мову. Выдаленне зноў цалкам выдаляе трыгеры, журнал і ўсе кэшаваныя старонкі.

Парада для кэша ў RAM: бюджэт RAM у панэлі кіравання і памер tmpfs (/dev/shm, параметр мантавання size=) павінны адпавядаць патрэбе. Абодва значэнні вам называе праверка «Ці змяшчаецца ва ўсёй аператыўнай памяці?» з канкрэтнымі лічбамі.

Абмежаванні, пра якія варта ведаць

• Кароткая затрымка пасля змен: індэкс журнала змен абнаўляецца кожныя дзве секунды. Да таго часу змененая старонка можа яшчэ выдавацца ў старой версіі.
• Тэксты, якія залежаць ад запасаў, абнаўляюцца праз змены запасаў і максімальны ўзрост.
• Ацэнка патрэбнага месца: дадатковыя версіі для прайскуранта або краіны не ўлічаны; плануйце некаторы запас.
• Не замяняе ўсё: кэш разгружае запыты, якія ён можа абслугоўваць. Аўтарызаваныя карыстальнікі, пошук і формы па-ранейшаму праходзяць праз Odoo.
• Першы запыт застаецца павольным: пасля перазапуску сервера (RAM) або глабальнай змены кожная старонка адзін раз рэндэрыцца звычайна, перш чым трапіць у кэш.

Частыя пытанні

Што такое кэш старонак для Odoo?

Модуль з адкрытым зыходным кодам (website_page_cache, Odoo 19, LGPL-3), які выдае публічныя старонкі крамы і блога для ананімных наведвальнікаў з кэша, замест таго каб рэндэрыць іх нанова пры кожным звароце. Кэш размяшчаецца на выбар у файлах або ў аператыўнай памяці.

Ці блакуе модуль пошукавыя сістэмы або ШІ-краўлеры?

Не. Пошукавыя сістэмы і ШІ-індэксатары атрымліваюць тыя ж старонкі, што і любы іншы наведвальнік, толькі хутчэй. Няма ні блакавання, ні абмежавання, ні асобнай версіі для краўлераў.

Ці кэшуюцца змененыя старонкі і пераклады аўтаматычна нанова?

Так. Трыгеры PostgreSQL паведамляюць у журнал пра кожную змену адпаведных табліц; закрануты старонкі адкідаюцца і пры наступным звароце рэндэрыцца нанова і захоўваюцца. Пераклады ўлічаны, бо Odoo 19 захоўвае іх у тым жа запісе.

Мне абраць файл ці RAM?

Як правіла, Аўтаматычна: модуль выкарыстоўвае RAM, пакуль усе старонкі змяшчаюцца, і інакш пераходзіць на файлы. Файлы падыходзяць, калі кэш павінен перажываць перазапускі або RAM не хапае; RAM – самы хуткі варыянт.

Як даведацца, ці змяшчаецца мой вэб-сайт у аператыўную памяць?

У панэлі кіравання пад Вэб-сайт → Справаздачы → Кэш старонак. Раздзел «Ці змяшчаецца ва ўсёй аператыўнай памяці?» лічыць старонкі для кожнага вэб-сайта і мовы, вымярае памер старонак і параўноўвае патрэбу з бюджэтам RAM, памерам tmpfs і даступнай памяццю.

Колькі дадатковай RAM патрэбна для кэша ў RAM?

Панэль кіравання паказвае гэта асобным радком. Разлік: патрэба = старонкі × памер старонкі; з запасам бяспекі падзелена на 0,8. Паколькі кэш можа выкарыстоўваць не больш за палову даступнай памяці, удвая большае значэнне – неабходная вольная памяць; розніца і ёсць дадатковая RAM. Калі замалы толькі бюджэт RAM або tmpfs, панэль кіравання называе налада разам з мэтавым значэннем.

Ці можа кэш паказаць каму-небудзь чужое змесціва?

Не. Кэшуецца толькі для ананімных GET-запытаў без параметраў пошуку. Аўтарызаваныя карыстальнікі, кошыкі, формы і пошук ніколі не выдаюцца з кэша; мова, прайскурант, падатковая пазіцыя і згода на cookie ўваходзяць у ключ.

Як у надзвычайным выпадку адключыць кэш?

У панэлі кіравання выключыць пераключальнік «Актыўны» або ўсталяваць сістэмны параметр website_page_cache.enabled у 0. Гэта дзейнічае ва ўсіх працоўных працэсах не пазней чым праз 30 секунд. Выдаленне модуля таксама выдаляе трыгеры, журнал і кэшаваныя старонкі.

Як даведацца, ці выдадзена старонка з кэша?

Па загалоўку адказу X-Page-Cache: HIT азначае з кэша, MISS азначае толькі што адрэндэрана і захавана.

Ці робіць модуль HTML меншым і ці сціскае яго?

Так. Кэшаваныя старонкі кансерватыўна мінімізуюцца (каментарыі і лішнія прабелы выдаляюцца, змесціва і выгляд застаюцца тымі ж) і пры трапленнях у кэш выдаюцца праз gzip; пакеты актываў сціскаюцца адзін раз і выдаюцца з дыска. І тое, і другое можна адключыць праз параметры website_page_cache.minify і website_page_cache.compress.

Падтрымка ад Biricon IT Services

Ваш вэб-сайт на Odoo павольна рэагуе пры нагрузцы ад краўлераў, або вы хочаце зрабіць краму і блог хутчэйшымі і больш бачнымі? Мы дапамагаем у аналізе нагрузкі, у наладзе кэша старонак, у вызначэнні неабходнага аб'ёму аператыўнай памяці і колькасці працоўных працэсаў і ў шматмоўнай аптымізацыі для пошукавых сістэм вашага вэб-сайта на Odoo. Зыходны код модуля вы знойдзеце на GitHub.

Звязацца з намі

Стан на 10 лістапада 2026. Вымераныя значэнні атрыманы на тэставай сістэме з прыкладнымі данымі і не з'яўляюцца гарантыяй для іншых усталёвак.