Налаштування кешування на стороні браузера для 1С-Бітрікс

Налаштування кешування на стороні браузера для 1С-Бітрікс

Повторний відвідувач завантажує сторінку за 4 секунди при тому, що логи показують TTFB 200 мс. Waterfall у DevTools пояснює: 80 запитів до статики, кожен з 304 Not Modified. Файли віддаються з кешу браузера, але браузер все одно запитує сервер «чи не змінився?». Правильно виставлені заголовки кешування виключають ці запити повністю.

Модель браузерного кешу

Браузер використовує два механізми:

Freshness — браузер знає, до якого моменту файл актуальний, і не звертається до сервера взагалі. Керується заголовками Cache-Control: max-age і Expires.

Validation — браузер запитує сервер «чи змінився файл?», використовуючи ETag або Last-Modified. Сервер відповідає 304, браузер використовує кеш. Економить трафік, але не RTT.

Мета — максимально використовувати Freshness для статики з версіонуванням і Validation для HTML.

Конфігурація 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 у Cache-Control — браузер не перевірятиме файл навіть при ручному оновленні сторінки (Ctrl+F5 не діє). Застосовувати лише до файлів з версійним хешем в імені.

Версіонування ресурсів у Бітрікс

Без версіонування довгий кеш небезпечний: оновили CSS, користувачі бачать старий дизайн тиждень.

Вбудований механізм Бітрікс — параметр sessid в URL ресурсів. Не ідеальний: змінюється при кожній сесії, ламає кеш частіше, ніж потрібно.

Через .htaccess / nginx map — додаємо в URL статики хеш від вмісту файлу при деплої:

# Скрипт у деплої: генеруємо версії
for f in /var/www/site/public/css/*.css; do
    hash=$(md5sum "$f" | cut -c1-8)
    # Створюємо symlink з хешем
    ln -sf "$(basename $f)" "${f%.css}.${hash}.css"
done

Vite/Webpack — якщо фронтенд збирається через Vite (як у цьому проекті), хеші в іменах файлів генеруються автоматично: app-B3vCf7Tf.js. Для таких файлів можна сміливо ставити max-age=31536000, immutable.

Інвалідація кешу Бітрікс через параметр

Для ресурсів без автоматичного версіонування використовуємо ручний параметр у шаблоні:

// У header.php шаблону
$version = '2024031301'; // оновлюємо при деплої

echo '<link rel="stylesheet" href="/css/custom.css?v=' . $version . '">';

Автоматизуємо: читаємо версію з файлу version.txt, що оновлюється CI/CD:

$version = trim(file_get_contents($_SERVER['DOCUMENT_ROOT'] . '/version.txt'));

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>

Перевірка

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 при повторному завантаженні.