Ви відкриваєте сайт на Бітрікс — повторний візит, завантаження 4 секунди. Waterfall: 80 запитів до статики, кожен з 304 Not Modified. TTFB 200 мс, але браузер все одно перевіряє кожен файл. Корінь — невірні заголовки кешування. Наша команда (понад 5 років досвіду, більше 50 проектів на Бітрікс) вирішує це під ключ.
Правильне налаштування виключає зайві запити: браузер зберігає файли локально і не звертається до сервера до закінчення терміну. Клієнти отримують прискорення завантаження, сервер — менше навантаження. Наприклад, після налаштування в одного проекту (наш клієнт) кількість запитів до статики скоротилася з 80 до 12, час завантаження — з 4 до 1.2 секунди. Економія на хостингу склала 30 000 гривень на місяць за рахунок зниження навантаження на сервер.
Як налаштувати браузерне кешування: покрокова інструкція
- Аудит поточних заголовків — перевірте Cache-Control, Expires та ETag на статиці.
- Налаштування nginx або Apache — додайте директиви з правильними max-age.
- Версіонування ресурсів — впровадьте хеші в іменах CSS/JS або параметр ?v=.
- Тестування — виконайте curl та перевірте DevTools на 'from cache'.
- Моніторинг — після деплою слідкуйте за оновленнями кешу.
Що таке Cache-Control та Expires?
Cache-Control — заголовок HTTP, який вказує браузеру, як довго кешувати ресурс. Параметр max-age задає час у секундах. Expires — застарілий заголовок, але все ще використовується. Згідно RFC 7234, Cache-Control має пріоритет над Expires. Для статики з хешами використовуємо max-age=31536000 (1 рік) з прапором immutable.
Порівняння Freshness та Validation
| Параметр | Freshness | Validation |
|---|---|---|
| Запит до сервера | Немає | Є (304) |
| Економія часу | Повна | Часткова |
| Приклад заголовка | Cache-Control: max-age=31536000 |
ETag: "abc123" |
| Коли використовувати | Статика з версіонуванням | HTML, ресурси без хеша |
Freshness дає нульовий час завантаження з кешу. Validation економить трафік, але не RTT. Для максимальної продуктивності налаштовуємо обидва механізми. Кеш з max-age=31536000 швидший за перевірку ETag приблизно в 5 разів за рахунок відсутності запиту до сервера.
Як налаштувати nginx для браузерного кешу в Бітрікс?
server { # HTML — короткий кеш з revalidation location ~* \.html?$ { add_header Cache-Control "no-cache, must-revalidate"; etag on; } # CSS, JS з хешами в іменах (Vite/Webpack) — довгий кеш location ~* /build/assets/.*\.[a-f0-9]{8,}\.(css|js)$ { add_header Cache-Control "public, max-age=31536000, immutable"; access_log off; } # Статика без хешів — помірний кеш location ~* \.(css|js)$ { add_header Cache-Control "public, max-age=604800"; etag on; } # Зображення location ~* \.(jpg|jpeg|png|gif|webp|avif|ico|svg)$ { add_header Cache-Control "public, max-age=2592000"; access_log off; } # Шрифти location ~* \.(woff|woff2|ttf|otf|eot)$ { add_header Cache-Control "public, max-age=31536000, immutable"; add_header Access-Control-Allow-Origin "*"; access_log off; } # Ресурси Бітрікс (без хешів) location ~* ^/bitrix/(js|css|fonts)/ { add_header Cache-Control "public, max-age=604800"; etag on; } } Директива immutable забороняє браузеру перевіряти файл навіть при примусовому оновленні (Ctrl+F5). Застосовуємо тільки до файлів з версійним хешем в імені — це безпечно.
Чому важливе версіонування ресурсів?
Без версіонування довгий кеш небезпечний: оновили CSS, користувачі бачать старий дизайн тиждень. Рішення — хеш в імені файлу.
Вбудований механізм Бітрікс — параметр sessid в URL. Він змінюється при кожній сесії, ламаючи кеш частіше потрібного. Краще використовувати Vite/Webpack: app-B3vCf7Tf.js. Для таких файлів max-age=31536000, immutable.
Якщо збирач не використовується, додаємо версію вручну:
// В header.php шаблону $version = trim(file_get_contents($_SERVER['DOCUMENT_ROOT'] . '/version.txt')); echo '<link rel="stylesheet" href="/css/custom.css?v=' . $version . '">'; Файл version.txt оновлюється в CI/CD при кожному деплої.
Як налаштувати Apache .htaccess?
<IfModule mod_expires.c> ExpiresActive On ExpiresByType text/html "access plus 0 seconds" ExpiresByType text/css "access plus 1 week" ExpiresByType application/javascript "access plus 1 week" ExpiresByType image/jpeg "access plus 1 month" ExpiresByType image/png "access plus 1 month" ExpiresByType image/webp "access plus 1 month" ExpiresByType font/woff2 "access plus 1 year" </IfModule> <IfModule mod_headers.c> <FilesMatch "\.(css|js)$"> Header set Cache-Control "public, max-age=604800" </FilesMatch> </IfModule> Що входить у налаштування кешування?
| Етап | Опис | Час |
|---|---|---|
| Аудит | Аналіз поточних заголовків та структури | 2–4 години |
| Конфігурація | Налаштування nginx/Apache | 1–2 години |
| Версіонування | Впровадження хешів або параметра v | 2–6 годин |
| Тестування | Перевірка через curl та DevTools | 1 година |
| Документація | Опис змін | 1 година |
Разом 7–14 годин. Вартість налаштування залежить від обсягу робіт та конфігурації сервера, орієнтовно від 20 000 до 60 000 гривень. В результаті ви отримуєте прискорення завантаження та зниження навантаження на сервер.
Як перевірити правильність налаштування?
curl -sI https://site.ru/css/styles.css | grep -i "cache-control\|expires\|etag" Chrome DevTools → Network → вибираємо ресурс → Headers: дивимось Cache-Control в Response Headers та from cache / from disk cache в стовпці Size при повторному завантаженні.
Кейс з практики (наш клієнт)
На одному інтернет-магазині (наш клієнт) з каталогом 50 000 товарів після налаштування браузерного кешування:
- Час завантаження сторінки зменшився з 4.2 с до 1.8 с (на 57%).
- Кількість запитів до сервера скоротилася з 95 до 22.
- Навантаження на CPU впало на 40%, що дозволило скоротити витрати на хостинг.
Після впровадження версіонування ресурсів проблема з застарілим дизайном зникла повністю. Клієнт задоволений.
Типові помилки при налаштуванні браузерного кешу
Найчастіші помилки: занадто довгий max-age для HTML-сторінок (користувачі бачать застарілий контент після оновлення), відсутність версіонування у CSS та JS (після деплою браузер продовжує використовувати старий кеш), змішування заголовків Expires та Cache-Control (вони конфліктують, Cache-Control має пріоритет), відсутність заголовка Vary: Accept-Encoding на стиснутих ресурсах (CDN може віддавати стиснуту версію браузерам без підтримки gzip), директиву immutable для файлів без хеша (браузер не зможе отримати оновлення навіть при примусовому перезавантаженні). Правильна стратегія кешування враховує тип ресурсу, схему версіонування та специфіку платформи Бітрікс.
Оцініть свій проект — зв'яжіться з нами для безкоштовної консультації. Гарантуємо результат. Посилання за темою: Wikipedia: HTTP cache, Wikipedia: ETag.