Настроить кеширование браузера

Зачем настраивать кеширование браузера

Кеширование браузера — один из самых простых и эффективных способов ускорить загрузку сайта для повторных посетителей. Когда пользователь впервые заходит на страницу, браузер скачивает все ресурсы: CSS, JavaScript, шрифты, изображения. Без кеширования при каждом следующем визите браузер запрашивает всё заново. С правильно настроенным кешем статические файлы хранятся локально и загружаются мгновенно.

Для SEO это имеет прямое значение. PageSpeed Insights выдаёт рекомендацию «Serve static assets with an efficient cache policy», если срок кеша слишком короткий или отсутствует. Core Web Vitals — LCP, FCP — напрямую зависят от скорости загрузки ресурсов. Если CSS-файл размером 150 КБ грузится из кеша за 0 мс вместо 200 мс по сети — это ощутимый выигрыш, особенно на мобильных с нестабильным соединением.

По моей практике, правильная настройка кеширования сокращает время повторной загрузки страниц на 40-70%. Для сайтов с высокой долей возвращающихся пользователей — интернет-магазины, сервисы, корпоративные сайты — это критически важная оптимизация.

Пошаговая инструкция

Шаг 1. Разберитесь в механизмах кеширования

Браузерное кеширование управляется HTTP-заголовками. Основные из них:

• Cache-Control — главный заголовок. Директива max-age=2592000 говорит браузеру: «храни этот файл 30 дней, не спрашивая сервер». Это самый важный заголовок, именно его нужно настроить в первую очередь.
• ETag — хеш-сумма файла. Когда срок кеша истекает, браузер отправляет серверу запрос с ETag. Если файл не изменился — сервер отвечает 304 Not Modified без тела ответа. Файл берётся из кеша.
• Expires — устаревший заголовок, задаёт абсолютную дату истечения кеша. Используется как fallback для старых клиентов. Если указан и Cache-Control, и Expires — браузер следует Cache-Control.
• Last-Modified — дата последнего изменения файла. Работает аналогично ETag, но менее точен: два разных файла могут иметь одинаковую дату модификации.

Шаг 2. Определите оптимальное время кеша для разных типов ресурсов

Не все файлы кешируются одинаково. Вот рекомендации, которые я использую в проектах:

• Изображения (JPEG, PNG, WebP, AVIF, SVG) — 1 год (31536000 секунд). Изображения редко меняются, а при изменении обычно получают новое имя файла.
• CSS и JavaScript — от 1 месяца до 1 года. Если используете версионирование файлов (style.css?v=2.1 или style.a1b2c3.css) — ставьте 1 год. Без версионирования — 1 месяц.
• Шрифты (WOFF2, WOFF) — 1 год. Шрифты не меняются практически никогда.
• HTML-страницы — не кешировать или кешировать на очень короткий срок (60-300 секунд). HTML-контент обновляется часто, и пользователь должен видеть актуальную версию.
• Favicon, манифесты — 1 неделя (604800 секунд).

Шаг 3. Настройте кеширование в Nginx

Добавьте в конфигурацию сервера блок location для статических ресурсов:

location ~* \.(jpg|jpeg|png|gif|webp|avif|svg|ico)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    access_log off;
}

location ~* \.(css|js)$ {
    expires 1M;
    add_header Cache-Control "public";
    access_log off;
}

location ~* \.(woff2|woff|ttf|eot)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    access_log off;
}

Директива immutable говорит браузеру: «этот файл не изменится до истечения max-age, не нужно даже проверять». Это убирает условные запросы (304) и дополнительно ускоряет загрузку.

Шаг 4. Настройте кеширование в Caddy

Caddy — современный веб-сервер с автоматическим HTTPS, популярный в небольших проектах. Кеширование настраивается через директиву header в Caddyfile:

@static {
    path *.jpg *.jpeg *.png *.gif *.webp *.avif *.svg *.ico
    path *.woff2 *.woff *.ttf *.eot
}
header @static Cache-Control "public, max-age=31536000, immutable"

@assets {
    path *.css *.js
}
header @assets Cache-Control "public, max-age=2592000"

Шаг 5. Настройте кеширование в WordPress без доступа к серверу

Если нет доступа к конфигурации веб-сервера, используйте плагины:

• WP Rocket (платный) — включает кеширование браузера автоматически, прописывая правила в .htaccess для Apache. Дополнительно создаёт статические HTML-копии страниц.
• W3 Total Cache (бесплатный) — раздел Browser Cache позволяет задать заголовки для каждого типа файлов. Настройка гибкая, но интерфейс перегружен.
• LiteSpeed Cache — если сайт на LiteSpeed/OpenLiteSpeed, этот плагин работает на уровне сервера и эффективнее всех аналогов.

Для Apache плагины обычно добавляют правила в .htaccess:

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType font/woff2 "access plus 1 year"
</IfModule>

Шаг 6. Внедрите версионирование статических файлов

Длинный срок кеша создаёт проблему: когда вы обновляете CSS или JS, пользователи видят старую версию из кеша. Решение — версионирование. WordPress по умолчанию добавляет параметр ?ver= к файлам, но некоторые CDN игнорируют query string. Надёжнее включать хеш в имя файла: style.a3f8b2.css. При изменении файла хеш меняется, браузер воспринимает это как новый ресурс и загружает заново.

Шаг 7. Проверьте настройки

Откройте DevTools в Chrome (F12), перейдите на вкладку Network. Загрузите страницу, найдите любой статический файл (CSS, JS, изображение). В заголовках ответа (Response Headers) должны присутствовать:

• Cache-Control: public, max-age=... — с корректным значением
• ETag — для условного кеширования

Повторно загрузите страницу — в колонке Size должно отображаться «disk cache» или «memory cache» для статических ресурсов. Если видите полный размер файла — кеширование не работает.

Также проверьте через PageSpeed Insights: рекомендация «Serve static assets with an efficient cache policy» должна исчезнуть.

Типичные ошибки

• Кешировать HTML-страницы на длительный срок. Если закешировать HTML на месяц — пользователь не увидит обновления контента, новые акции, изменённые цены. HTML кешируется максимум на несколько минут или не кешируется вовсе. Серверное кеширование (создание статических HTML-копий) — это другой механизм, не путайте с браузерным.
• Не использовать версионирование при длинном кеше. Поставили max-age=1y для CSS — обновили стили — пользователь видит сломанную вёрстку ещё год. Без версионирования длинный кеш создаёт больше проблем, чем пользы.
• Конфликт заголовков. Если Nginx и WordPress-плагин оба задают Cache-Control — результат непредсказуем. Настраивайте кеширование на одном уровне: либо на сервере, либо через плагин. Проверяйте итоговые заголовки в DevTools.
• Отключать ETag. Некоторые руководства советуют убрать ETag для экономии трафика. В современных реалиях это вредный совет: ETag обеспечивает корректное обновление файлов после истечения кеша и стоит минимум ресурсов.
• Забывать про API-запросы и динамические данные. AJAX-ответы, данные корзины, результаты поиска — всё это не должно кешироваться. Используйте Cache-Control: no-store для эндпоинтов с динамическими данными.

Что проверить в итоге

• В DevTools все статические ресурсы (CSS, JS, изображения, шрифты) отдаются с заголовком Cache-Control и значением max-age не менее 2592000 (30 дней).
• При повторной загрузке страницы статика берётся из disk cache или memory cache.
• HTML-страницы не кешируются на длительный срок (max-age не больше 300 секунд или no-cache).
• PageSpeed Insights не показывает рекомендацию «Serve static assets with an efficient cache policy».
• Реализовано версионирование CSS и JS (параметр ?ver= или хеш в имени файла).
• Нет конфликтов заголовков между сервером и плагинами (один источник управления кешем).
• API-эндпоинты и динамические ответы отдаются с заголовком Cache-Control: no-store.