Как настроить Cache-Control в Apache

Quick Links

• How Does Caching Work?

• How to Use Cache-Control in Apache

Как работает кэширование?

При первом посещении сайта браузер скачивает статические ресурсы (CSS, JS, изображения и т. п.) и сохраняет их в локальном кэше. При следующем переходе браузер может загрузить эти файлы из диска или памяти, а не заново по сети — это ускоряет отображение страниц и снижает нагрузку на сервер.

Кэш на стороне клиента — это одно звено. Многие сайты также используют CDN (Content Delivery Network) — сеть серверов, расположенных ближе к пользователям. CDN кэширует страницы и ресурсы, увеличивая пропускную способность, уменьшая задержки и снимая нагрузку с исходного (origin) сервера.

Заголовок Cache-Control, который ваш сервер добавляет в HTTP-ответы, сообщает браузерам и промежуточным кэшам (CDN, reverse proxy), как и сколько хранить ресурс. Правильная настройка позволяет сочетать быстрое кэширование статики и свежесть содержимого для динамических страниц.

Ключевые термины в одну строку:

• TTL (Time-To-Live): время жизни ресурса в кэше.
• CDN: сеть для распределённого кэширования и доставки контента.

Важно: нельзя кэшировать страницы с персональными данными в общих (shared) кэших — это может привести к утечке данных между пользователями.

Cache-Control: основные директивы

Ниже — основные значения заголовка Cache-Control и их смысл. Сохраняйте директивы в точности (англ.).

• public — разрешает кеширование всеми, включая CDN и браузеры. Применимо для статических ресурсов.
• private — запрещает кеширование общими кэшем; только браузер пользователя может кэшировать ответ. Используется для страниц с аутентификацией.
• no-cache — не запрещает хранение в кэше, но требует у сервера проверки актуальности перед использованием. Подходит, когда нужно обязательное подтверждение валидности.
• no-store — отключает хранение полностью; используйте для очень чувствительных данных.
• no-transform — запрещает преобразования контента (например, сжатие изображений) со стороны CDN.

Дополнительно часто указывают max-age=<секунды>, где значение — время в секундах. Примеры:

• 300 — 5 минут
• 86400 — 1 день
• 63072000 — 2 года (обычно для неизменяемых ассетов)

Пример комбинированного заголовка:

Cache-Control: max-age=63072000, public, immutable

Примечание: директива immutable подсказывает браузеру, что ресурс не изменится до истечения max-age; полезно для ассетов с версионированием.

Примеры конфигурации Apache

В Apache заголовки устанавливаются с помощью модуля headers и директивы Header set. Ниже — практические примеры.

Установка таймаута по умолчанию (site-wide):

Header set Cache-Control "max-age=84600, public"

Применение длительного TTL для статических файлов (рекомендуется):

  Header set Cache-Control "max-age=63072000, public, immutable"

Ограничение кэширования для динамических или приватных директорий:

  Header set Cache-Control "max-age=300, private, no-transform"

Установка для одного файла:

  Header set Cache-Control "max-age=300, private"

Если у вас нет доступа к основному конфигу, можно использовать .htaccess в нужной директории с теми же директивами. Однако .htaccess медленнее и не рекомендуется для крупных сайтов.

Совет по управлению обновлениями статических файлов: используйте версионирование имён, например

styles-1.0.1.css

при обновлении меняйте имя файла (или добавляйте хэш в имя), чтобы заставить браузеры и CDN перезагрузить ресурс.

Использование Surrogate-Control для CDN

Заголовок Surrogate-Control действует как Cache-Control, но применим только к CDN и reverse-proxy. Это полезно, когда вы хотите, чтобы CDN кэшировал дольше или короче, чем браузер.

Header set Surrogate-Control "max-age=300, public"

Проверьте поддержку у вашего CDN: не все провайдеры корректно обрабатывают Surrogate-Control.

Проверка и отладка

Проверять заголовки ответа можно несколькими способами.

1. curl (инструмент командной строки):

curl -I https://example.com/styles-1.0.1.css

Вы увидите блок заголовков, среди которых будет Cache-Control (и Surrogate-Control, если задан).

2. Chrome DevTools: откройте вкладку Network → выберите ресурс → вкладка Headers → Response Headers. По-русски: Сеть → Заголовки.

3. Проверка через CDN: многие CDN предоставляют интерфейс и логи, где видно, попал ли запрос в кэш или был проброшен к origin (cache hit/miss). Используйте их инструменты или API для подробного анализа.

Критерии приёмки

• Для набора статических файлов (CSS, JS, шрифты, картинки) установлен Cache-Control с max-age ≥ 1 неделя или 2 года при версионировании.
• Для приватных страниц — private или no-store, если данные чувствительны.
• Проверено через curl и DevTools: заголовки фактически присутствуют и соответствуют политике.

Шпаргалка — типичные значения max-age

Чек-листы по ролям

DevOps:

• Включить модуль headers.
• Настроить FilesMatch для статических файлов.
• Убедиться, что более специализированные блоки переопределяют общие правила.
• Настроить Surrogate-Control для CDN (если поддерживается).

Frontend-разработчик:

• Использовать версионирование имён/хэши в сборке.
• Обсудить с DevOps политику кэша для ассетов и API.

Специалист по безопасности:

• Обозначить все страницы с ПДн как no-store или private.
• Проверить, что аутентифицированный контент не кэшируется в shared прокси.

Альтернативные подходы и когда они применимы

• Политики на уровне CDN: некоторые CDN позволяют настраивать правила кэширования на своей панели, что может быть удобнее, чем правка конфигов сервера.
• ETag / Last-Modified: механизмы валидации содержимого; хороши в сочетании с no-cache или кратким max-age.
• Service Worker: позволяет полностью контролировать кэш в браузере для PWA, но требует клиентской логики.

Контрпримеры / когда это не работает

• Если CDN игнорирует Surrogate-Control, придётся настраивать правила на стороне CDN.
• Неправильное версионирование имён приведёт к тому, что клиенты будут загружать устаревший контент.
• Если заголовки конфликтуют (например, два источника устанавливают разный Cache-Control), поведение зависит от порядка обработки и конкретного прокси.

Тестовые сценарии и приёмочные критерии

• Запрос статического файла: ожидается заголовок Cache-Control с долгим max-age и статус 200; на повторный запрос — age в заголовках (при проксировании).
• Запрос приватной страницы для аутентифицированного пользователя: ожидается Cache-Control: private или no-store.
• Изменение версии ассета: после обновления имени файла старые клиенты должны получить новый файл.

Простая методика принятия решения (flowchart)

flowchart TD
  A[Новый ресурс?] -->|да| B{Статический и версионируемый}
  B -->|да| C[Установить max-age=63072000, public, immutable]
  B -->|нет| D{Показывает персональные данные}
  D -->|да| E[Установить private или no-store]
  D -->|нет| F[Установить краткий max-age + no-cache]

Краткий глоссарий (1 строка)

• Cache-Control: заголовок HTTP для управления кэшированием; max-age — время в секундах.
• Surrogate-Control: заголовок для указаний только CDN/reverse-proxy.
• CDN: сеть доставки контента, кэш перед origin.

Итог

Cache-Control в Apache — мощный инструмент для оптимизации производительности и снижения нагрузки на сервер. Правильно разделяйте политику для статических и приватных ресурсов, используйте версионирование имён для безопасного долгого кэширования и проверяйте результаты через curl и DevTools.

Важно: тестируйте взаимодействие настроек сервера с настройками вашего CDN и прокси, чтобы избежать неожиданных конфликтов кэширования.