Кеширане на страници, CDN и банери за съгласие: как да не показвате грешно състояние на съгласие
Бързи страници, грешно съгласие
Кеширането на страници е едно от най-добрите неща, които можете да направите за скоростта и разходите за хостинг. То е и един от най-лесните начини да счупите настройката за съгласие, без да забележите. Кешът прави точно каквото му е казано: запазва отговор веднъж и го сервира на всеки, който съвпада със същия ключ. Ако запазеният отговор съдържа нещо, специфично за избора на съгласие или местоположението на един посетител, следващият посетител го получава също.
Това ръководство обхваща слоевете на кеширане, които обикновено стоят пред сайта на издателя — кешове на периферията на CDN, приставки за кеширане на цели страници, обратни проксита, service worker и самия браузър — и как да не позволите на никой от тях да показва грешното изживяване за съгласие.
Основното правило: дръжте съгласието извън кешираното HTML
Най-безопасната архитектура изгражда кешираната HTML страница като неутрална към съгласието. Страницата съдържа зареждащия код на CMP и вашите тагове в блокирано или чакащо състояние, но не и решение за този конкретен посетител. След това CMP работи в браузъра, чете запазения избор, решава дали да покаже банера и съответно отключва таговете.
Проблемите започват, когато сървърът взема решения за съгласието при изграждането на страницата, например:
- тема или приставка, която извежда рекламни или аналитични тагове само когато има бисквитка за съгласие;
- сървърен код, който пропуска маркировката на банера за посетители, които вече са избрали;
- шаблони, които вграждат състоянието на съгласие на посетителя в променлива на вграден скрипт.
След като тази страница бъде кеширана, състоянието на първия посетител става състояние на всички. Посетител, отказал проследяване, може да получи страница с вече активни тагове, а нов посетител може никога да не види банер, защото кешираното копие идва от човек, който вече го е затворил.
Защо „Vary: Cookie“ рядко е отговорът
Учебниковото решение за съдържание, зависещо от посетителя, е да кажете на кешовете да различават по заглавката за бисквитки. На практика посетителите носят много бисквитки с уникални стойности, затова различаването по цялата заглавка за бисквитки обикновено свежда процента на попаденията в кеша почти до нула. Някои CDN позволяват ключът на кеша да се изгражда от стойността на една бисквитка, което е изпълнимо, ако бисквитката за съгласие има малък брой възможни състояния, но добавя сложност и пак умножава броя на кешираните копия. Преместването на решението в браузъра е по-просто и държи кеша ефективен.
География на периферията
Много издатели показват различни банери по региони: банер с opt-in за ЕС и Великобритания, известие за отказ за щатите в САЩ и нещо по-леко другаде. Ако сървърът избира варианта по IP адреса на посетителя и страницата е кеширана, европейски читател може да получи кеширана американска страница или обратното.
Три подхода избягват това:
- Геолокация от страна на клиента. Оставете CMP да определя региона в браузъра, така че кешираното HTML да е едно и също за всички.
- Държава в ключа на кеша. Ако трябва да решавате на периферията, включете в ключа на кеша кода на държавата, който предоставя вашият CDN. Получавате по едно кеширано копие на държава, което е предвидимо.
- Некеширана логика на периферията. Изпълнявайте регионалното решение във функция на периферията, която вмъква малка некеширана стойност в иначе кеширана страница.
Какъвто и вариант да изберете, документирайте го. Грешките с геолокацията са сред най-трудните за възпроизвеждане, защото се появяват само при посетители от едно място, на които случайно се е паднала страница, кеширана от някого другаде.
Кеширане на самия CMP скрипт
Дългото кеширане на зареждащия код на CMP е добро за производителността, но има цена, когато конфигурацията се променя. Ако обновите вендори, цели или текста на банера, а скриптът или конфигурационният файл е кеширан за година, част от посетителите ще продължат да виждат старата версия. Проверете как вашата CMP версионира файловете си: променящо се име на файл или параметър за версия ви позволява да кеширате агресивно, като пак внедрявате промените веднага. Уверете се и че вашият CDN не премахва низовете на заявките от URL адресите на скриптове на трети страни, ако CMP разчита на тях.
Service worker и офлайн кешове
Сайтовете със слой за прогресивно уеб приложение често кешират HTML в service worker. Важи същото правило: никога не запазвайте страница, която отразява конкретно решение за съгласие. Изключете свързаните със съгласието крайни точки и страниците на центъра за предпочитания от кеширането на service worker и се уверете, че свежа конфигурация на CMP винаги може да бъде изтеглена.
Кешът за назад/напред
Съвременните браузъри държат наскоро посетените страници в паметта, за да може бутонът „назад“ да ги възстановява мигновено. Ако посетител отвори центъра за предпочитания на една страница, оттегли съгласието и после натисне „назад“, възстановената страница може още да има тагове, работещи от преди. Слушайте събитието pageshow и проверявайте свойството му persisted: когато страница е възстановена от този кеш, прочетете отново запазеното състояние на съгласие и спрете или пуснете таговете съответно.
Процедура за тестване
- Заредете страница в чиста сесия, откажете, после заредете втора страница и се уверете, че не се задействат тагове за проследяване.
- Повторете с втори чист браузър и се уверете, че банерът се появява, което доказва, че не е бил кеширан.
- Проверете заглавките на отговора, за да видите дали страниците се сервират от кеша, и сравнете HTML със и без бисквитка за съгласие — трябва да е идентично.
- Тествайте от поне два региона след изчистване на кеша и отново, след като кешът се е затоплил.
- Оттеглете съгласието, използвайте бутона „назад“ и проверете дали таговете спират.
Основни изводи
- Кешираното HTML трябва да е неутрално към съгласието; оставете CMP да решава в браузъра.
- Избягвайте различаване по цялата заглавка за бисквитки; то унищожава процента на попаденията.
- Ако банерите се различават по региони, решавайте от страна на клиента или добавете държавата в ключа на кеша.
- Версионирайте файловете на CMP, за да не забавят дългите срокове на кеширане промените в конфигурацията.
- Обработете service worker и кеша за назад/напред и тествайте със затоплен кеш, не само след изчистване.