Хуткія старонкі, няправільная згода

Кэшаванне старонак — адзін з лепшых сродкаў для паскарэння сайта і эканоміі на хостынгу. Але гэта і адзін з самых простых спосабаў незаўважна зламаць налады згоды. Кэш робіць роўна тое, што яму сказана: захоўвае адказ адзін раз і аддае яго ўсім, хто падпадае пад той самы ключ. Калі захаваны адказ утрымлівае нешта, прывязанае да выбару згоды або месцазнаходжання аднаго наведвальніка, наступны наведвальнік атрымае тое самае.

У гэтым кіраўніцтве разгледжаны пласты кэшавання, якія звычайна стаяць перад сайтам выдаўца, — кэшы на мяжы 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 і кэш «назад/наперад» і тэстуйце з прагрэтым кэшам, а не толькі пасля ачысткі.