Szybkie strony, zła zgoda

Cache stron to jedna z najlepszych rzeczy, jakie możesz zrobić dla szybkości i kosztów hostingu. To także jeden z najłatwiejszych sposobów na niezauważone zepsucie ustawień zgody. Cache robi dokładnie to, co mu każesz: zapisuje odpowiedź raz i serwuje ją każdemu, kto pasuje do tego samego klucza. Jeśli zapisana odpowiedź zawiera cokolwiek specyficznego dla wyboru zgody lub lokalizacji jednego odwiedzającego, dostanie to także następny.

Ten przewodnik obejmuje warstwy cache, które zwykle stoją przed witryną wydawcy — cache brzegowe CDN, wtyczki do pełnego cache stron, reverse proxy, service workery i samą przeglądarkę — oraz sposoby, jak uniemożliwić każdej z nich serwowanie złego doświadczenia zgody.

Podstawowa zasada: trzymaj zgodę poza cache’owanym HTML

Najbezpieczniejsza architektura renderuje cache’owaną stronę HTML jako neutralną wobec zgody. Strona zawiera loader CMP i Twoje tagi w stanie zablokowanym lub oczekującym, ale żadnej decyzji dotyczącej tego konkretnego odwiedzającego. CMP działa następnie w przeglądarce, odczytuje zapisany wybór, decyduje, czy pokazać baner, i odpowiednio zwalnia tagi.

Problemy zaczynają się, gdy serwer podejmuje decyzje o zgodzie w czasie renderowania, na przykład:

• motyw lub wtyczka, która drukuje tagi reklamowe lub analityczne tylko wtedy, gdy obecne jest cookie zgody;
• kod po stronie serwera, który pomija znacznik banera dla odwiedzających, którzy już dokonali wyboru;
• szablony, które osadzają stan zgody odwiedzającego w zmiennej skryptu inline.

Gdy taka strona trafi do cache, stan pierwszego odwiedzającego staje się stanem wszystkich. Odwiedzający, który odrzucił śledzenie, może dostać stronę z już aktywnymi tagami, albo nowy odwiedzający może nigdy nie zobaczyć banera, bo cache’owana kopia pochodzi od kogoś, kto już go zamknął.

Dlaczego „Vary: Cookie” rzadko jest odpowiedzią

Podręcznikowa poprawka dla treści zależnych od odwiedzającego to polecenie, by cache różnicowały według nagłówka cookie. W praktyce odwiedzający mają wiele cookies o unikalnych wartościach, więc różnicowanie według całego nagłówka cookie zwykle sprowadza współczynnik trafień cache niemal do zera. Niektóre CDN pozwalają zbudować klucz cache z wartości pojedynczego cookie, co jest wykonalne, jeśli Twoje cookie zgody ma niewielką liczbę możliwych stanów, ale dodaje złożoności i nadal mnoży liczbę kopii w cache. Przeniesienie decyzji do przeglądarki jest prostsze i utrzymuje wydajność cache.

Geografia na brzegu

Wielu wydawców pokazuje różne banery w zależności od regionu: baner opt-in dla UE i Wielkiej Brytanii, informację o rezygnacji dla stanów USA i coś lżejszego gdzie indziej. Jeśli serwer wybiera wariant na podstawie adresu IP odwiedzającego, a strona jest cache’owana, europejski czytelnik może dostać cache’owaną stronę amerykańską lub odwrotnie.

Trzy wzorce temu zapobiegają:

1. Geolokalizacja po stronie klienta. Pozwól CMP ustalić region w przeglądarce, aby cache’owany HTML pozostał taki sam dla wszystkich.
2. Kraj w kluczu cache. Jeśli musisz decydować na brzegu, dołącz do klucza cache kod kraju dostarczany przez CDN. Otrzymujesz jedną kopię w cache na kraj, co jest przewidywalne.
3. Niecache’owana logika brzegowa. Uruchom decyzję regionalną w funkcji brzegowej, która wstrzykuje niewielką niecache’owaną wartość do skądinąd cache’owanej strony.

Cokolwiek wybierzesz, udokumentuj to. Błędy geograficzne należą do najtrudniejszych do odtworzenia, bo pojawiają się tylko u odwiedzających z jednego miejsca, którzy akurat dostali stronę zbuforowaną przez kogoś z innego.

Cache’owanie samego skryptu CMP

Długie cache’owanie loadera CMP jest dobre dla wydajności, ale ma swoją cenę, gdy zmienia się konfiguracja. Jeśli zaktualizujesz dostawców, cele lub tekst banera, a skrypt lub plik konfiguracyjny jest cache’owany przez rok, część odwiedzających będzie nadal widzieć starą wersję. Sprawdź, jak Twoje CMP wersjonuje pliki: zmieniająca się nazwa pliku lub parametr wersji pozwala cache’ować agresywnie, a mimo to wdrażać zmiany natychmiast. Upewnij się też, że Twój własny CDN nie usuwa ciągów zapytań z adresów URL skryptów zewnętrznych, jeśli CMP na nich polega.

Service workery i cache offline

Witryny z warstwą aplikacji progresywnej często cache’ują HTML w service workerze. Obowiązuje ta sama zasada: nigdy nie zapisuj strony odzwierciedlającej konkretną decyzję o zgodzie. Wyklucz endpointy związane ze zgodą i strony centrum preferencji z cache’owania przez service worker i upewnij się, że zawsze można pobrać świeżą konfigurację CMP.

Cache wstecz/dalej

Nowoczesne przeglądarki trzymają niedawno odwiedzone strony w pamięci, aby przycisk wstecz przywracał je natychmiast. Jeśli odwiedzający otworzy centrum preferencji na jednej stronie, wycofa zgodę, a następnie naciśnie wstecz, przywrócona strona może nadal mieć uruchomione tagi sprzed zmiany. Nasłuchuj zdarzenia pageshow i sprawdzaj jego właściwość persisted: gdy strona jest przywracana z tego cache, ponownie odczytaj zapisany stan zgody i zatrzymaj lub uruchom tagi odpowiednio.

Procedura testowa

• Załaduj stronę w czystej sesji, odrzuć, następnie załaduj drugą stronę i potwierdź, że żadne tagi śledzące się nie uruchamiają.
• Powtórz w drugiej czystej przeglądarce i potwierdź, że baner się pojawia, co dowodzi, że nie został wycache’owany.
• Sprawdź nagłówki odpowiedzi, czy strony są serwowane z cache, i porównaj HTML z cookie zgody i bez — powinien być identyczny.
• Testuj z co najmniej dwóch regionów po wyczyszczeniu cache, a potem ponownie po jego rozgrzaniu.
• Wycofaj zgodę, użyj przycisku wstecz i sprawdź, czy tagi się zatrzymują.

Najważniejsze wnioski

• Cache’owany HTML powinien być neutralny wobec zgody; pozwól CMP decydować w przeglądarce.
• Unikaj różnicowania według pełnego nagłówka cookie; niszczy to współczynnik trafień.
• Jeśli banery różnią się według regionu, decyduj po stronie klienta lub dodaj kraj do klucza cache.
• Wersjonuj pliki CMP, aby długie czasy życia cache nie opóźniały zmian konfiguracji.
• Obsłuż service workery i cache wstecz/dalej oraz testuj z rozgrzanym cache, nie tylko po wyczyszczeniu.