HTTP-кэширование позволяет ускорить индексацию сайта поисковыми роботами и снизить нагрузку на сервер. На больших каталогах правильно настроенное кэширование снимает заметную часть нагрузки от карточек товаров - до 30-40%. Но в 1С-Битрикс эта настройка сложнее, чем кажется, и с ходу не включается.
Статья - для веб-разработчиков, SEO-специалистов и владельцев сайтов на Битрикс, которым нужна быстрая индексация и меньше лишней нагрузки. Разберём логику заголовков и то, как мы поднимаем кэширование под Битрикс.
Зачем кэшировать на уровне HTTP
Когда страница не менялась, нет смысла отдавать её заново - ни боту, ни браузеру. HTTP-кэширование сообщает клиенту дату изменения, и при повторном заходе сервер отвечает коротким 304 Not Modified вместо полной генерации страницы.
- →Яндекс.Вебмастер рекомендует отдавать Last-Modified: чтобы показывать дату в выдаче, попадать в результаты с фильтром по дате и не пересканировать неизменённые страницы.
- →Google PageSpeed Insights требует явные заголовки кэширования для всех ресурсов.
- →Сервер разгружается: вместо рендера страницы отдаёт 304 - это особенно заметно на каталогах в десятки тысяч товаров.
Заголовки, которые управляют кэшем
- →Cache-Control - главный заголовок с директивами: max-age (срок жизни в секундах), public/private, no-cache, no-store, must-revalidate.
- →Expires - дата, до которой кэш считается валидным; ресурс не запрашивают повторно до этого момента.
- →Last-Modified - дата последнего изменения. Браузер при повторном запросе шлёт If-Modified-Since, и сервер отвечает 304, если ничего не поменялось.
- →ETag - то же, но вместо даты хэш содержимого. Браузер шлёт If-None-Match.
- →Date, Pragma, Age - вспомогательные: время сервера, устаревший аналог no-cache из HTTP/1.0 и возраст записи на промежуточных прокси.
Почему Битрикс по умолчанию запрещает кэш
Большинство сайтов на 1С-Битрикс из коробки отдают заголовки, которые запрещают браузерное кэширование:
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Expires: Thu, 19 Nov 1981 08:52:00 GMTЭто побочный эффект вызова session_start() с параметрами по умолчанию - сессия запускается на каждой странице и проставляет запрещающие заголовки. Поэтому просто включить Last-Modified не выходит: сначала нужно убрать это поведение для нужных страниц.
Сколько нагрузки снимает кэш
Замеры повторных заходов на двух интернет-магазинах показывают, ради чего всё затевается:
- →В течение суток - 3-5% повторных заходов.
- →В течение месяца - 15-30%.
- →В течение полугода - 30-40% заходов поисковых ботов приходится на уже виденные страницы.
Каждый такой заход на неизменённую страницу можно закрыть коротким 304 вместо полной генерации. На большом каталоге это и есть та самая снятая нагрузка.
Как мы поднимаем кэширование под Битрикс
Готового переключателя нет, поэтому реализуем механизм, который сам решает, что и насколько кэшировать:
- 01Конфигурация. Список инфоблоков с шаблонами URL, отдельные наборы значимых полей для людей и для ботов, разные сроки max-age под каждую группу.
- 02Индексная таблица. В памяти (Memory engine) храним по каждому элементу даты значимых изменений и ETag - отдельно для людей и для ботов.
- 03Проверка запроса. Сверяем URL с шаблонами, достаём идентификатор элемента, проверяем условные заголовки If-Modified-Since и If-None-Match.
- 04Ответ. Если значимых изменений нет - отдаём 304. Если есть - проставляем заголовки кэширования в событии OnEndBufferContent.
Как проверить свой сайт
- →last-modified.com - показывает, отдаёт ли страница Last-Modified и возвращает ли 304 Not Modified.
- →redbot.org - разбирает заголовки и подсказывает ошибки кэширования.
Если индексация идёт медленно или сервер не справляется с нагрузкой - сначала стоит понять, в кэше дело или в чём-то ещё. Базовую диагностику можно провести самому (самостоятельный аудит сайта на 1С-Битрикс), а запас прочности под наплыв трафика проверяют нагрузочным тестированием. Если хотите, чтобы кэширование настроили под ваш каталог, - разберём задачу на диагностике.
