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

10 листопада 2026 року  |  Власна розробка  |  Odoo, продуктивність і пошукові системи

Вебсайт Odoo формує кожну сторінку заново при кожному зверненні: запити до бази даних, шаблони, переклади, ціни. Для одного відвідувача це непомітно. Але коли пошукові системи та ШІ-індексатори запитують сотні чи тисячі сторінок багатьма мовами, виникає постійне навантаження, і справжнім клієнтам доводиться чекати. Тому ми розробили модуль Odoo 19 website_page_cache і опублікували його на GitHub як відкритий код (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 КБ) – це допомога для розрахунку, а не вимірювання наших сторінок. Для малих вебсайтів вистачає кількох десятків мегабайтів; приклад даних на знімках екрана обійшовся приблизно 13 МБ.

Важливо для оцінки: розрахунок не враховує додаткових версій за прайс-листами чи країнами. Тим, хто ними багато користується, варто закласти трохи запасу. І ще: надто малий бюджет RAM – найчастіша причина, чому автоматика залишається на файлах, а не брак оперативної пам'яті. У такому разі панель керування показує саме цей рядок.

Зміни й переклади очищають кеш

Кеш придатний лише тоді, коли ніколи не віддає застарілих сторінок. Простий часовий ліміт («скидати кожні дванадцять годин») був би надто грубим: змінена ціна чи виправлена помилка мали б чекати до дванадцяти годин. Тому модуль працює за змістом.

1. Тригери бази даних: на всіх таблицях, що можуть впливати на сторінку (товари, варіанти, зображення, залишки, атрибути, категорії, ціни, податки, прайс-листи, дописи блогу й теги, дані партнерів і компаній, подання, ресурси, меню, мови, налаштування вебсайту), встановлено тригери PostgreSQL. Вони заносять кожну зміну до журналу змін.
2. Залежності й стан бази даних: кожна кешована сторінка запам'ятовує, які записи вона показує, і стан бази даних, з яким її створено.
3. Звірення: якщо є запис журналу, створений після цього стану й такий, що стосується одного з цих записів, сторінка застаріла.
4. Повторне кешування: при наступному зверненні застарілу сторінку відкидають, формують заново й знову зберігають.

Переклади також охоплені

Odoo 19 зберігає перекладені тексти в тому самому записі, що й оригінальний текст (як поле JSON). Тому змінений переклад для бази даних – звичайна зміна рядка, і тригер її бачить. Це однаково стосується редагування через інтерфейс, імпорту, інтерфейсів (API) і скриптів, що пишуть безпосередньо в базу даних. Автоматичний переклад 46 мовами робить недійсними саме ті сторінки, текст яких змінився, і не більше.

• Вибірково, а не всі разом: змінений товар робить недійсними його сторінки, списки, де він є, і відповідну категорію. Решта лишається в кеші.
• Глобальні зміни (шаблони, ресурси, мови, меню, податки, валюти) роблять недійсним усе одразу, адже можуть стосуватися кожної сторінки.
• Лічильники не враховуються: лічильник переглядів дописів блогу змінюється при кожному візиті; він свідомо не спричиняє скасування, інакше кеш для популярних дописів був би безглуздим.
• Страхувальна сітка: додатково діє максимальний вік сторінки (за замовчуванням 12 годин).
• Кеш не спричиняє помилок запису: помилка всередині тригера журналюється як попередження й не призводить до збою самого збереження.

Панель керування та статистика

Усе, що потрібно для експлуатації, зібрано в одному місці: в Odoo у розділі Вебсайт → Звіти → Кеш сторінок. Розділ Огляд – це панель керування (з налаштуваннями), розділ Історія показує цифри за днями та вебсайтами.

Знімок екрана з тестової системи з копіями наших вебсайтів; назви вебсайтів замінено на умовні позначки.

Налаштування

Стан і статистика

Стан показує активне місце зберігання з межею, кількість і розмір кешованих сторінок та відстеження змін: скільки змін зафіксовано за останні 24 години й скільки таблиць контролюється. Якщо контроль бракує, панель керування чітко попереджає, бо тоді кешу довіряти не можна. Кнопки вгорі дозволяють негайно запустити обслуговування, очистити кеш або перевірити тригери й за потреби створити їх заново.

Статистика (Сьогодні, 7 днів, 30 днів) містить:

• З кешу та Сформовано: влучання й промахи, з них частка влучань
• Видалено (змінено/прострочено): скільки сторінок відкинуто через зміну або закінчення терміну
• Час формування та час кешу: порівняння середнього значення на сторінку
• Орієнтовно зекономлений час сервера та обсяг даних із кешу

Цифри кожен робочий процес збирає окремо й записує раз на хвилину; рядки, старші за 90 днів, прибирає завдання обслуговування.

Історія у вигляді діаграми, зведеної таблиці та списку

У розділі Історія доступні добові значення за вебсайтами – у вигляді діаграми, зведеної таблиці або списку. Так видно, чи зростає частка влучань після перезапуску або великої зміни, і який вебсайт отримує найбільше трафіку з кешу.

Безпека: що ніколи не береться з кешу

Кеш сторінок ніколи не повинен призводити до того, щоб хтось побачив чужий вміст. Тому модуль керується принципом: якщо є сумнів, не кешувати.

• Лише анонімні відвідувачі: той, хто увійшов до системи, має кошик або інший стан сесії, завжди отримує сторінку, сформовану в звичайному порядку.
• Лише GET без параметрів пошуку: пошук, фільтри, сортування, форми, кошик і оформлення замовлення не зачіпаються.
• Лише статус 200 і HTML: сторінки помилок, перенаправлення та файли не зберігаються.
• Жодних ідентифікаторів сесії в кеші: сторінка, що містить ідентифікатор сесії або встановлює cookie, не зберігається (і журналюється як попередження).
• Токен CSRF на кожен запит: токен у кешованій сторінці є заповнювачем і підставляється заново при кожній віддачі.
• Докладний ключ: вебсайт, мова, прайс-лист, фіскальна позиція та згода на cookie входять до ключа кешу; хто бачить інше, отримує інший запис.
• Кілька баз даних: кожна база даних має власні записи, власний журнал і власну статистику.
• Жодного витоку даних: кеш лежить локально на сервері (файл або RAM). Жодні дані не передаються третім особам.

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

Дехто з операторів відповідає на навантаження від краулерів блокуванням. Це захищає сервер, але коштує видимості. Модуль обирає протилежний шлях:

• Однаковий вміст для всіх: пошукові системи, ШІ-індексатори та відвідувачі отримують ту саму сторінку. Окремої «версії для краулерів» і розпізнавання за ідентифікатором браузера немає.
• Швидші відповіді допомагають індексації: сторінка, що відповідає за 20 замість 500 мілісекунд, менше навантажує краулінговий бюджет, і краулери можуть за той самий час охопити більше сторінок.
• Актуальний вміст: оскільки зміни негайно скасовують чинність сторінок, краулери ніколи не бачать застарілої версії – це важливо, якщо ви ведете вміст для пошуку та відповідей ШІ.
• Структуровані дані зберігаються: JSON-LD, мета-дані та посилання hreflang є частиною кешованої сторінки; карт сайту й файлів кеш не торкається.

Якщо ви хочете додатково обмежити навантаження, це окреме рішення, яке можна ухвалити свідомо – модуль не нав'язує його вам.

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

Кеш економить не лише час обчислень, а й обсяг даних. Модуль мінімізує HTML перед збереженням і віддає його стисненим, якщо браузер або краулер це підтримує:

• Мінімізація (параметр website_page_cache.minify): коментарі HTML видаляються, пропуски об'єднуються. Повністю вони прибираються лише там, де браузер їх однаково ігнорує, наприклад між блоковими елементами. Відступи між рядковими елементами зберігаються, pre, textarea і скрипти лишаються без змін, структуровані дані (JSON-LD) переписуються компактно. Залежно від сторінки вони стають на 10-30 % меншими. У тесті із сімома справжніми сторінками текст, кількість елементів, розташування всіх елементів і знімок екрана збіглися з оригіналом. Перша віддача (MISS) мінімізована так само, як і кожна наступна (HIT).
• Стиснення (параметр website_page_cache.compress): сторінки з кешу відправляються через gzip (Content-Encoding: gzip, Vary: Accept-Encoding). Великі пакети ресурсів (CSS і JavaScript, до кількох МБ) Odoo сам віддає нестисненими; модуль стискає їх один раз, кладе копію на диск і далі віддає безпосередньо. Так 2,1 МБ CSS стали 0,27 МБ, а 4,8 МБ JavaScript – 1,1 МБ. Старі копії прибирає завдання обслуговування.
• Після перезавантаження комп'ютера: кеш у 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 року. Виміряні значення отримано в тестовій системі з прикладами даних; вони не є гарантією для інших установок.