Кеширование в Drupal: как связаны BigPipe, теги и контексты

Если Drupal показывает одному пользователю персональный блок другого, виноват не обязательно BigPipe: чаще всего компонент закешировали без нужного контекста. В Drupal 10 и 11 теги, контексты и max-age описывают, когда кеш пригоден; BigPipe отдельно помогает отправить страницу раньше, подставив динамические фрагменты позже. Смешать эти механизмы — значит либо раздавать устаревшее, либо отключить кеш там, где он мог бы работать.

Четыре механизма, которые легко перепутать

В Drupal рендер-массив — не просто HTML для вывода. Вместе с результатом рендеринга система может сохранить метаданные кеширования, а затем использовать их, чтобы понять, кому подходит сохранённый результат, когда его сбросить и как долго считать действительным.

• Теги связывают кеш с данными или конфигурацией. Если изменился материал, помеченный тегом node:42, кешированные результаты с этим тегом могут быть инвалидированы.
• Контексты разделяют варианты результата. Например, если вывод зависит от роли пользователя, нужен контекст вроде user.roles; если от языка интерфейса — languages:language_interface.
• max-age задаёт максимальный срок годности результата в секундах. Значение 0 означает, что результат нельзя кешировать.
• BigPipe разбивает отдачу страницы на первоначальный ответ и последующие фрагменты для мест, которые Drupal может подставить отдельно. Это способ доставки, а не замена тегам, контекстам или сроку кеширования.

Контекст кеша¹ — признак, по которому Drupal выбирает отдельный вариант сохранённого результата. Если блок зависит от параметра URL, но контекст этого параметра не указан, кеш может ошибочно считать два разных вывода одинаковыми.

BigPipe может раньше показать оболочку страницы. Он не может угадать, какие данные меняют ваш блок и для кого этот блок должен быть разным.

Почему теги и контексты решают разные задачи

Представьте блок со списком последних материалов. Его содержимое меняется, когда создают или редактируют публикации, но обычно не должно отличаться для разных посетителей. Здесь важны теги: кешу нужно сообщить, какие изменения делают сохранённый список устаревшим. Добавление пользовательского контекста не поможет обновить список после редактирования.

Теперь другой блок показывает ссылку только пользователям с определённой ролью. Здесь нужен контекст, разделяющий варианты для разных ролей. Тег сам по себе не объяснит, что посетителям с разными правами нужны разные результаты. Если при этом ссылка зависит от настройки сайта, понадобится и тег конфигурации.

Теги не являются таймером, а контексты не инвалидируют данные при изменении. max-age тоже не заменяет ни то ни другое: короткий срок может временно маскировать ошибку, но не делает модель кеша корректной.

Где в этой схеме находится BigPipe

BigPipe полезен, когда часть страницы готова быстро, а некоторые фрагменты требуют персональных или более дорогих вычислений. Вместо ожидания всех частей Drupal может начать отдавать страницу, а затем заменить placeholder — место, оставленное для такого фрагмента, — его результатом.

Это меняет воспринимаемое время загрузки, но не обязательно уменьшает объём вычислений на сервере. Если тяжёлый фрагмент по-прежнему требует дорогого запроса, BigPipe может раньше показать остальную страницу, но сам запрос дешевле не станет. Если фрагмент рассчитан неверно или получил неправильные метаданные кеша, более быстрый вывод не исправит ошибку.

Поэтому проверяйте отдельно два вопроса:

• Можно ли безопасно повторно использовать результат блока для другого запроса или пользователя? Это вопрос контекстов, тегов и max-age.
• Можно ли отдать остальную страницу до того, как готов этот блок? Это вопрос разметки на placeholders и работы BigPipe.

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

Типичные ошибки при настройке

Убрали персонализацию, но оставили кешируемый общий результат

Когда вывод зависит от пользователя, роли, языка или запроса, проверьте, передаются ли соответствующие контексты в метаданных компонента. Иначе Drupal может повторно использовать результат, сформированный в другом варианте. Для диагностики сопоставьте два запроса, которые должны давать разный вывод, и выясните, какие метаданные сопровождают блок в каждом случае.

Добавили тег, ожидая разделения по аудитории

Тег отвечает на вопрос «что изменилось?», а контекст — «для какого варианта запроса это значение?». Тег материала может инвалидировать блок после правки этого материала, но не разделит результат между ролями. Если вывод различается, сначала ищите недостающий контекст.

Поставили max-age 0 на весь компонент

Это может скрыть проблему с устаревшим выводом, но одновременно отключает повторное использование результата. На страницах с множеством блоков потеря кеширования повышает нагрузку и может ухудшить время ответа. Ищите минимальную часть, которая действительно меняется, и проверьте, можно ли вынести её в отдельный placeholder.

Считаете, что BigPipe делает блок кешируемым

Placeholder позволяет отдать фрагмент отдельно, но сам по себе не определяет, кому подходит его результат и когда его сбросить. Эти свойства по-прежнему описывают метаданные кеширования. Если проблему видно только при включённом BigPipe, сравните ответы с ним и без него, но не пропускайте проверку тегов, контекстов и max-age.

Что проверять на проекте

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

1. Назовите зависимость. Это сущность, конфигурация, пользовательская роль, язык, маршрут или параметр запроса? Если зависимостей несколько, перечислите их отдельно.
2. Подберите метаданные. Изменение данных должно отражаться тегом; различие между запросами — контекстом; ограничение по времени — max-age. Не подменяйте одну задачу другой.
3. Проверьте два разных сценария. Например, две роли или два языка, если именно они должны менять результат. Убедитесь, что Drupal не повторно использует для них неподходящий вариант.
4. Проверьте инвалидирование. Измените сущность или настройку, от которой зависит блок, и убедитесь, что следующий запрос не получает устаревший результат.
5. Только затем оценивайте BigPipe. Посмотрите, какие части страницы приходят отдельно и меняется ли время до первого полезного содержимого. Сравнивайте один и тот же сценарий при одинаковых условиях.

Для диагностики смотрите метаданные рендеринга и заголовки кеширования в инструментах разработчика или логах. Точный способ зависит от того, какой слой рассматриваете: рендер-кеш Drupal, Dynamic Page Cache, кеш браузера, CDN или прокси. Ответ «включён кеш» недостаточен: важно понять, какой именно слой отдал конкретный ответ.

Когда подход ломается

Проблема часто возникает на границе слоёв. Drupal может правильно разделять варианты в своём кеше, а внешний прокси — отдавать один HTTP-ответ всем посетителям, если его правила не учитывают нужные заголовки и персонализацию. Возможна и обратная ситуация: Drupal выставляет корректные метаданные, но внешний кеш настроен так, что всё содержимое страницы не кешируется.

Отдельно проверяйте блоки, зависящие от времени, случайного выбора, внешнего API или данных, меняющихся вне Drupal. Для них нужно понять, каким событием инвалидировать результат и допустима ли задержка обновления. Нельзя автоматически считать, что тег сущности Drupal узнает об изменении, произошедшем в сторонней системе.

При замерах фиксируйте версию Drupal, состояние прогрева кеша, тип запросов, число параллельных пользователей и то, включён ли внешний кеш. Без этих условий цифра «стало быстрее» мало что говорит: прогретый ответ может сравниваться с холодным, а выигрыш BigPipe — с эффектом CDN.

Что делать дальше

Выберите один проблемный блок и составьте для него короткую карту зависимостей: какие данные меняют содержимое, какие запросы должны видеть разные варианты и сколько допустимо держать результат. Сверьте её с тегами, контекстами и max-age, затем отдельно проверьте, даёт ли BigPipe более раннее отображение нужной части страницы. После исправления наблюдайте за временем ответа и долей попаданий в кеш на каждом задействованном слое.

Сноска 1. Контекст кеша — именованная характеристика запроса или окружения, по которой Drupal хранит разные варианты результата. Он не содержит сам HTML-блок и не сообщает, когда данные изменились.