Быстрые страницы, неверное согласие

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

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

Главное правило: не допускайте согласие в кэшируемый HTML

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

Проблемы начинаются, когда сервер принимает решения о согласии при формировании страницы, например:

• тема или плагин выводят рекламные или аналитические теги только при наличии cookie согласия;
• серверный код не выводит разметку баннера для посетителей, которые уже сделали выбор;
• шаблоны встраивают состояние согласия посетителя в переменную встроенного скрипта.

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

Почему «Vary: Cookie» редко выручает

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

География на границе сети

Многие издатели показывают разные баннеры по регионам: баннер opt-in для ЕС и Великобритании, уведомление об отказе для штатов США и что-то более лёгкое в остальных местах. Если сервер выбирает вариант по IP-адресу посетителя, а страница кэшируется, европейский читатель может получить кэшированную американскую страницу или наоборот.

От этого защищают три подхода:

1. Геолокация на стороне клиента. Пусть CMP определяет регион в браузере, и кэшированный HTML остаётся одинаковым для всех.
2. Страна в ключе кэша. Если решать приходится на границе сети, включите в ключ кэша код страны, который предоставляет ваш CDN. Вы получите одну кэшированную копию на страну, и это предсказуемо.
3. Некэшируемая логика на границе. Выполняйте региональное решение в edge-функции, которая вставляет небольшое некэшируемое значение в остальном кэшированную страницу.

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

Кэширование самого скрипта CMP

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

Service worker и офлайн-кэши

Сайты со слоем прогрессивного веб-приложения часто кэшируют HTML в service worker. Правило то же: никогда не сохраняйте страницу, отражающую конкретное решение о согласии. Исключите из кэширования service worker конечные точки согласия и страницы центра предпочтений и убедитесь, что свежую конфигурацию CMP всегда можно загрузить.

Кэш «назад/вперёд»

Современные браузеры держат недавно посещённые страницы в памяти, чтобы кнопка «назад» восстанавливала их мгновенно. Если посетитель открыл центр предпочтений на одной странице, отозвал согласие, а затем нажал «назад», восстановленная страница может по-прежнему содержать теги, работавшие раньше. Слушайте событие pageshow и проверяйте его свойство persisted: когда страница восстановлена из этого кэша, заново считайте сохранённое состояние согласия и остановите или запустите теги соответственно.

Процедура тестирования

• Загрузите страницу в чистой сессии, откажитесь, затем загрузите вторую страницу и убедитесь, что теги отслеживания не срабатывают.
• Повторите во втором чистом браузере и убедитесь, что баннер появляется, то есть он не был «закэширован».
• Проверьте заголовки ответа, чтобы понять, отдаются ли страницы из кэша, и сравните HTML с cookie согласия и без него — он должен быть идентичным.
• Протестируйте как минимум из двух регионов после очистки кэша, а затем ещё раз, когда кэш прогреется.
• Отзовите согласие, нажмите «назад» и убедитесь, что теги остановились.

Ключевые выводы

• Кэшируемый HTML должен быть нейтрален к согласию; пусть CMP решает в браузере.
• Не различайте ответы по полному заголовку cookie: это разрушает долю попаданий.
• Если баннеры различаются по регионам, решайте на стороне клиента или добавьте страну в ключ кэша.
• Версионируйте файлы CMP, чтобы длинные сроки кэширования не задерживали изменения конфигурации.
• Учитывайте service worker и кэш «назад/вперёд» и тестируйте с прогретым кэшем, а не только после очистки.