Кешування сторінок, CDN і банери згоди: як не віддавати хибний стан згоди
Швидкі сторінки, хибна згода
Кешування сторінок — один із найкращих засобів для прискорення сайту й економії на хостингу. Але це й один із найпростіших способів непомітно зламати налаштування згоди. Кеш робить саме те, що йому сказано: зберігає відповідь один раз і віддає її всім, хто підпадає під той самий ключ. Якщо збережена відповідь містить щось, прив’язане до вибору згоди чи місцезнаходження одного відвідувача, наступний відвідувач отримає те саме.
У цьому посібнику розглянуто шари кешування, які зазвичай стоять перед сайтом видавця, — кеші на межі CDN, плагіни кешування повних сторінок, зворотні проксі, service worker і сам браузер — та те, як не дати кожному з них віддавати хибний сценарій згоди.
Головне правило: не допускайте згоду в кешований HTML
Найбезпечніша архітектура формує кешовану HTML-сторінку нейтральною до згоди. Сторінка містить завантажувач CMP і ваші теги в заблокованому чи очікувальному стані, але не містить рішення щодо цього конкретного відвідувача. Далі CMP працює в браузері, зчитує збережений вибір, вирішує, чи показувати банер, і відповідно активує теги.
Проблеми починаються, коли сервер ухвалює рішення про згоду під час формування сторінки, наприклад:
- тема чи плагін виводять рекламні або аналітичні теги лише за наявності cookie згоди;
- серверний код не виводить розмітку банера для відвідувачів, які вже зробили вибір;
- шаблони вбудовують стан згоди відвідувача у змінну вбудованого скрипта.
Щойно така сторінка потрапляє в кеш, стан першого відвідувача стає станом усіх. Відвідувач, який відмовився від відстеження, може отримати сторінку з уже активними тегами, а новий відвідувач може ніколи не побачити банер, бо кешована копія отримана від того, хто вже його закрив.
Чому «Vary: Cookie» рідко рятує
Хрестоматійне рішення для контенту, що залежить від відвідувача, — наказати кешам розрізняти відповіді за заголовком cookie. На практиці відвідувачі мають багато cookie з унікальними значеннями, тож розрізнення за всім заголовком cookie зазвичай зводить частку влучань у кеш майже до нуля. Деякі CDN дозволяють будувати ключ кешу за значенням одного cookie, що прийнятно, якщо ваш cookie згоди має невелику кількість можливих станів, але це ускладнює схему й усе одно примножує кількість кешованих копій. Перенести рішення в браузер простіше, і кеш залишається ефективним.
Географія на межі мережі
Багато видавців показують різні банери за регіонами: банер opt-in для ЄС і Великої Британії, повідомлення про відмову для штатів США та щось легше в інших місцях. Якщо сервер обирає варіант за IP-адресою відвідувача, а сторінка кешується, європейський читач може отримати кешовану американську сторінку чи навпаки.
Цього уникають три підходи:
- Геолокація на боці клієнта. Нехай CMP визначає регіон у браузері, і кешований HTML залишається однаковим для всіх.
- Країна в ключі кешу. Якщо вирішувати доводиться на межі мережі, додайте до ключа кешу код країни, який надає ваш CDN. Ви отримаєте одну кешовану копію на країну, і це передбачувано.
- Некешована логіка на межі. Виконуйте регіональне рішення в 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 і кеш «назад/уперед» та тестуйте з прогрітим кешем, а не лише після очищення.