Pamięć podręczna strony: rodzaje cache i ich wpływ na szybkość witryny

Czym jest pamięć podręczna strony i dlaczego ma kilka warstw

Pamięć podręczna, nazywana z angielskiego cache, to mechanizm przechowywania wyniku pracy, którą raz już wykonano, po to, aby przy kolejnym żądaniu podać gotowy wynik zamiast liczyć wszystko od nowa. Warstw jest kilka, ponieważ droga od kliknięcia do wyświetlenia strony składa się z kilku etapów i na każdym z nich da się coś zapamiętać.

Warto prześledzić tę drogę na przykładzie strony zbudowanej na WordPressie. Przeglądarka wysyła żądanie, które trafia do serwera. Serwer uruchamia kod PHP, ten wielokrotnie pyta bazę danych o ustawienia, treść wpisu, menu i widżety, a następnie składa z odpowiedzi dokument HTML. Dokument wraca do przeglądarki, która pobiera jeszcze arkusze stylów, skrypty, czcionki i obrazy. Każdy z tych etapów trwa, a przy kilkudziesięciu odwiedzających jednocześnie serwer powtarza identyczne czynności kilkadziesiąt razy.

Poszczególne warstwy pamięci podręcznej skracają różne odcinki tej drogi. Pamięć przeglądarki sprawia, że pliki nie są pobierane ponownie. Pamięć całej strony pozwala pominąć uruchamianie PHP i bazy danych. Pamięć obiektów ogranicza liczbę zapytań do bazy. Pamięć kodu PHP przyspiesza samo wykonywanie programu. Sieć CDN skraca fizyczną odległość między plikiem a odbiorcą. Z tego powodu pytanie, czy strona ma włączony cache, jest nieprecyzyjne. Właściwe pytanie brzmi: które warstwy działają i czy są ze sobą uzgodnione.

Znaczenie tego tematu dla widoczności w wyszukiwarce opisujemy szerzej we wpisie o szybkości strony i pozycjach w Google. Tutaj skupiamy się na samej mechanice, bo to od niej zależy, czy przyspieszenie będzie trwałe i bezpieczne.

Pamięć podręczna przeglądarki: co przyspiesza i jak się nią steruje

Pamięć podręczna przeglądarki przyspiesza kolejne odsłony u tej samej osoby, ponieważ pliki pobrane przy pierwszej wizycie zostają na jej urządzeniu. Steruje się nią nagłówkami odpowiedzi, które serwer dołącza do każdego pliku.

Jak wyjaśnia opracowanie web.dev o pamięci podręcznej HTTP, przeglądarka przed wysłaniem żądania najpierw sprawdza, czy ma już ważną kopię odpowiedzi. Jeśli tak, używa jej i nie łączy się z siecią. O tym, jak długo i w jaki sposób kopia może być przechowywana, decyduje nagłówek Cache-Control. Najważniejsze jego dyrektywy mają następujące znaczenie:

Częstym nieporozumieniem jest znaczenie dyrektywy no-cache. Nie zakazuje ona przechowywania, a jedynie każe pytać serwer, czy kopia jest nadal dobra. Pełny zakaz zapisu wyraża dopiero no-store.

Potwierdzanie aktualności kopii

Gdy termin ważności kopii minie, przeglądarka nie musi pobierać pliku od nowa. Wysyła do serwera krótkie pytanie z identyfikatorem posiadanej wersji. Służy do tego nagłówek ETag, czyli niewielki znacznik będący zwykle skrótem zawartości pliku, albo nagłówek Last-Modified z datą ostatniej zmiany. Jeśli plik się nie zmienił, serwer odpowiada kodem 304 i nie przesyła treści, więc wymiana danych jest minimalna. Według web.dev znacznik ETag jest dokładniejszy niż porównywanie dat.

Pliki z wersją w adresie i dokumenty HTML

To samo źródło zaleca odmienne traktowanie dwóch grup zasobów. Pliki, które mają w nazwie lub adresie oznaczenie wersji, mogą otrzymać najdłuższy termin ważności, czyli max-age równy 31536000 sekund, co odpowiada jednemu rokowi. Jest to bezpieczne, ponieważ po zmianie zawartości zmienia się również adres pliku i przeglądarka pobiera nową wersję. Dokumenty HTML mają stały adres, dlatego dla nich zalecane są ustawienia wymagające potwierdzenia aktualności.

/wp-content/themes/motyw/style.3f9a1c.css
Cache-Control: public, max-age=31536000
ETag: "3f9a1c"

/oferta/
Cache-Control: no-cache
ETag: "a81b07"

Warto wiedzieć, że przeglądarki mają też odrębny mechanizm przywracania całej strony przy użyciu przycisków wstecz i dalej. Pamięć podręczna stanu strony przechowuje nie pojedyncze odpowiedzi, lecz kompletną stronę wraz ze stanem skryptów, dlatego powrót do poprzedniej podstrony bywa natychmiastowy. Jest to osobna funkcja przeglądarki, niezależna od ustawień opisanych wyżej.

Pamięć podręczna całej strony na serwerze: największy zysk przy pierwszej wizycie

Pamięć podręczna całej strony polega na zapisaniu gotowego dokumentu HTML i podawaniu go kolejnym odwiedzającym bez uruchamiania kodu PHP i bez pytań do bazy danych. To warstwa, która najmocniej skraca czas odpowiedzi serwera, także u osoby odwiedzającej witrynę po raz pierwszy.

Dokumentacja WordPressa poświęcona pamięci podręcznej opisuje to wprost: wtyczki tego rodzaju zapisują wpisy i strony jako pliki statyczne, które następnie trafiają do użytkowników, co ogranicza pracę serwera. Według tej dokumentacji w przypadku stron o dość stałej treści wydajność może wzrosnąć nawet kilkaset razy. To samo źródło zastrzega, że serwisy z dużą ilością treści dynamicznych wymagają bardziej złożonej konfiguracji. Tę samą rolę może pełnić oprogramowanie ustawione przed serwerem strony, które według dokumentacji stosuje się głównie w witrynach o bardzo dużym ruchu.

Co nadaje się do zapisu, a co nie

Do zapisu nadają się podstrony, które każdemu wyglądają tak samo: strona główna, oferta, wpisy na blogu, kategorie i karty produktów. Kancelaria z Krakowa, której serwis składa się z opisu specjalizacji, zespołu i publikacji, może w ten sposób obsługiwać niemal cały ruch. Inaczej jest w sklepie z Poznania: tam kategorie i karty produktów mogą pochodzić z pamięci, lecz koszyk, zamówienie i konto klienta muszą powstawać za każdym razem od nowa, ponieważ dla każdej osoby mają inną zawartość.

Druga istotna sprawa to unieważnianie, czyli usuwanie kopii po zmianie treści. Poprawnie skonfigurowana pamięć czyści kopię danej podstrony w chwili jej aktualizacji, a wraz z nią kopie stron, na których ta treść też się pojawia, na przykład listy wpisów. Opracowanie web.dev o skracaniu czasu do pierwszego bajtu zaleca właśnie takie podejście: unieważnianie przy publikacji pozwala łączyć długi czas przechowywania z szybkim pojawianiem się zmian. Ten sam tekst zauważa, że nawet krótki czas przechowywania pomaga na często odwiedzanych stronach, bo do właściwego serwera trafia tylko pierwszy odwiedzający.

Pamięć obiektów i pamięć kodu PHP: przyspieszenie tego, czego nie da się zapisać w całości

Pamięć obiektów przechowuje wyniki zapytań do bazy danych, a pamięć kodu PHP przechowuje przygotowany do wykonania program. Obie przyspieszają te odsłony, których nie można podać jako gotowej kopii: koszyk, wyszukiwarkę wewnętrzną, panel klienta i panel administracyjny.

Pamięć obiektów

WordPress ma wbudowaną pamięć obiektów, lecz, jak podaje opis klasy WP_Object_Cache, domyślnie nie jest ona trwała. Dane żyją wyłącznie w czasie obsługi jednego żądania, więc wynik kosztownego zapytania nie jest powtarzany w obrębie jednego ładowania strony, ale przy następnym żądaniu wszystko zaczyna się od nowa. Trwałość daje dopiero dodatkowa wtyczka połączona z osobnym serwerem pamięci. Dokumentacja WordPressa wymienia wśród popularnych silników Redis i Memcached.

Zysk z trwałej pamięci obiektów dokumentacja WordPressa o optymalizacji tłumaczy tak: ustawienia witryny są potrzebne przy każdej odsłonie, więc przechowywanie ich w szybkiej pamięci zmniejsza liczbę odwołań do bazy, skraca czas odpowiedzi i pomaga przy nagłych wzrostach ruchu. Wymaga to dwóch elementów: serwera pamięci udostępnionego przez firmę hostingową oraz wtyczki, która potrafi z nim współpracować. Z tego względu możliwości serwera warto poznać jeszcze przed wyborem oferty, o czym piszemy we wpisie o hostingu i jego wpływie na SEO.

Dokumentacja podkreśla również zasadę bezpieczeństwa: dane w pamięci obiektów muszą dać się odtworzyć. Jeżeli pamięć zostanie uszkodzona lub wyczyszczona, witryna ma działać dalej, tylko wolniej, do czasu ponownego zapełnienia pamięci.

Pamięć kodu PHP

Pamięć kodu PHP, znana jako OPcache, dotyczy samego programu. W uproszczeniu serwer nie musi przy każdym żądaniu od nowa odczytywać i przygotowywać do wykonania tych samych plików PHP, ponieważ korzysta z postaci przygotowanej wcześniej. Dokumentacja WordPressa stwierdza, że dodanie takiej pamięci poprawia wydajność PHP wielokrotnie i że działa ona dla wszystkich plików PHP na serwerze, nie tylko dla WordPressa. Konfiguruje się ją po stronie serwera i w większości przypadków zajmuje się tym firma hostingowa.

Jest to warstwa niewidoczna dla odwiedzających i nie powoduje pokazywania starych treści, bo dotyczy programu, a nie zawartości podstron. Z naszych wdrożeń wynika natomiast, że po ręcznym wgraniu nowych plików wtyczki lub motywu serwer może przez krótki czas wykonywać wcześniejszą wersję kodu, dlatego warto wtedy wyczyścić także tę pamięć, jeśli panel hostingu na to pozwala.

Sieć CDN: pamięć podręczna blisko odbiorcy

Sieć CDN, czyli sieć dostarczania treści, to grupa serwerów rozmieszczonych w wielu lokalizacjach, które przechowują kopie zasobów witryny i podają je z miejsca położonego bliżej odbiorcy. Przyspiesza przede wszystkim pobieranie plików, a po odpowiedniej konfiguracji także całych dokumentów HTML.

Według opracowania web.dev o sieciach CDN rozwiązanie to działa następująco. Witryna pozostaje na serwerze źródłowym. Przy pierwszym żądaniu serwer brzegowy sieci pobiera zasób ze źródła i zapisuje go u siebie, a następni odbiorcy dostają kopię z najbliższego węzła. Zmniejsza to obciążenie serwera źródłowego i pomaga przetrwać nagłe skoki ruchu.

Skuteczność sieci mierzy współczynnik trafień, czyli liczba odpowiedzi podanych z pamięci podzielona przez liczbę wszystkich żądań w danym okresie. Web.dev wskazuje, że dla większości witryn dobrym celem jest około 90 procent, i wymienia trzy typowe przyczyny słabego wyniku. Pierwszą są parametry w adresach: adres z dopisanym parametrem jest domyślnie traktowany jako odrębny zasób, więc linki z oznaczeniami kampanii potrafią mnożyć kopie tej samej podstrony. Drugą jest niewłaściwie użyty nagłówek Vary, który dzieli pamięć według nagłówków żądania. Trzecią są pliki cookie, ponieważ odpowiedzi ustawiające ciasteczko zwykle nie są zapisywane.

Opracowanie rozróżnia też rodzaje zasobów. Statyczne, takie jak obrazy czy biblioteki z wersją w nazwie, powinny mieć długi termin ważności, rzędu sześciu miesięcy lub roku. Dynamiczne, na przykład strona główna sklepu, mogą mieć termin bardzo krótki, nawet pięć sekund, a w godzinach szczytu i tak wyraźnie odciąży to serwer źródłowy. Prywatne, zawierające dane jednej osoby, nie powinny być zapisywane wcale i należy je oznaczać dyrektywą private. Gdy treść trzeba poprawić natychmiast, na przykład błędną cenę, stosuje się czyszczenie, czyli usunięcie kopii przed upływem terminu ważności.

Hydraulik z Łodzi obsługujący jedno miasto odczuje sieć CDN słabiej niż sklep sprzedający za granicę, ponieważ jego klienci i tak są blisko serwera. Dokumentacja WordPressa zauważa zresztą, że sieć CDN jest najskuteczniejsza w połączeniu z wtyczką pamięci podręcznej, a nie zamiast niej.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

W jakiej kolejności włączać warstwy pamięci podręcznej

Najrozsądniej zaczynać od warstw, które niczego nie mogą zepsuć w treści, a kończyć na tych, które wymagają wyjątków i testów. Żadne ze źródeł, na które się powołujemy, nie narzuca sztywnej kolejności, dlatego poniższy porządek jest naszym zaleceniem wynikającym z praktyki wdrożeń.

Punktem wyjścia powinien być pomiar. Bez zapisanego czasu odpowiedzi serwera i wyników z narzędzia PageSpeed Insights nie da się potem ocenić, co faktycznie pomogło. Sposób odczytywania tych danych opisujemy we wpisie o raporcie PageSpeed Insights.

1. Pamięć kodu PHP

   Działa na poziomie serwera, nie zmienia treści i zwykle jest dostępna w panelu hostingu. Wystarczy potwierdzić, że jest włączona.

2. Nagłówki dla plików statycznych

   Długi termin ważności dla obrazów, stylów i skryptów z wersją w adresie. Ryzyko jest niewielkie, o ile adres pliku zmienia się razem z jego zawartością.

3. Pamięć całej strony

   Daje największy zysk, ale wymaga listy wyjątków: koszyk, zamówienie, konto klienta, strony po zalogowaniu, wyniki wyszukiwania wewnętrznego.

4. Trwała pamięć obiektów

   Ma sens, gdy hosting udostępnia serwer pamięci, a witryna ma dużo odsłon, których nie można podać z gotowej kopii, jak w sklepie lub serwisie z logowaniem.

5. Sieć CDN

   Na końcu, gdy wcześniejsze warstwy są uporządkowane. Najpierw pliki statyczne, a dokumenty HTML dopiero po sprawdzeniu, że czyszczenie kopii działa.

Po każdej zmianie warto powtórzyć pomiar i przejść ręcznie najważniejsze ścieżki: formularz kontaktowy, dodanie produktu do koszyka, logowanie. Włączenie wszystkiego naraz utrudnia ustalenie, która warstwa odpowiada za ewentualny błąd. W małych serwisach firmowych trzy pierwsze pozycje zwykle wystarczają, a dwie ostatnie stają się potrzebne wraz ze wzrostem ruchu, co jest typowe dla sklepów, którymi zajmujemy się w ramach pozycjonowania sklepów internetowych.

Jakie błędy powoduje źle ustawiona pamięć podręczna

Źle ustawiona pamięć podręczna powoduje dwa rodzaje szkód: odwiedzający widzą nieaktualną treść albo, co znacznie groźniejsze, widzą stronę przygotowaną dla kogoś innego. Oba problemy mają konkretne przyczyny i da się im zapobiec.

Nieaktualne treści

Sklep z Poznania zmienia cenę produktu, a klienci przez kolejne godziny widzą poprzednią. Najczęściej oznacza to, że kopia podstrony nie została unieważniona po zapisaniu zmiany albo że wyczyszczono ją tylko w jednej warstwie. Wtyczka usunęła swoją kopię, lecz sieć CDN nadal podaje starą, albo odwrotnie. Podobny skutek daje długi termin ważności nadany plikom, których adres nie zmienia się po aktualizacji: przeglądarki stałych klientów trzymają wtedy stary arkusz stylów i strona po zmianie wyglądu wyświetla się im niepoprawnie.

Oznaczanie wersji w adresach plików rozwiązuje ten problem, ponieważ nowy dokument HTML zawsze wskazuje nowe pliki. Trzeba też pamiętać o kompromisie opisanym przez web.dev: im dłuższy czas przechowywania, tym mniejsze obciążenie serwera, ale większe ryzyko pokazania nieaktualnej treści.

Koszyk lub dane innego klienta

Najpoważniejszy błąd polega na zapisaniu w pamięci wspólnej odpowiedzi przeznaczonej dla jednej osoby. Jeśli strona koszyka, podsumowania zamówienia lub konta klienta trafi do pamięci całej strony albo do sieci CDN, kolejny odwiedzający może otrzymać tę samą kopię, a więc zobaczyć cudze produkty w koszyku, a w skrajnym przypadku cudze dane. Web.dev mówi jednoznacznie, że zasoby prywatne nie powinny być zapisywane w sieci CDN i należy je oznaczać dyrektywą private. Dla treści poufnych przeznaczona jest dyrektywa no-store.

Z naszej praktyki wynika, że w sklepach na WooCommerce z pamięci całej strony trzeba wyłączyć co najmniej koszyk, zamówienie i moje konto, a także odsłony odwiedzających, którzy mają już coś w koszyku. Większość wtyczek robi to samodzielnie, lecz własne podstrony o podobnym charakterze, na przykład kalkulator wyceny, strefa partnera czy lista życzeń, należy dopisać do wyjątków ręcznie.

Inne typowe pomyłki

Formularze potrafią przestać działać, gdy zapisana kopia strony zawiera jednorazowy znacznik bezpieczeństwa, który zdążył stracić ważność. Zdarza się też ocenianie szybkości wyłącznie po zalogowaniu do panelu WordPressa. Zalogowany administrator zwykle omija pamięć całej strony, więc widzi witrynę wolniejszą niż klienci, a jednocześnie nie dostrzega błędów, które dotyczą tylko odwiedzających bez konta.

Jak sprawdzić, czy pamięć podręczna działa

Działanie pamięci podręcznej sprawdza się w trzech miejscach: w nagłówkach odpowiedzi, w narzędziach deweloperskich przeglądarki oraz w pomiarze czasu odpowiedzi serwera. Sama informacja we wtyczce, że pamięć jest włączona, niczego jeszcze nie dowodzi.

Nagłówki odpowiedzi w przeglądarce Chrome

W przeglądarce Chrome należy otworzyć narzędzia deweloperskie klawiszem F12, przejść do panelu Sieć i odświeżyć stronę. Po kliknięciu pierwszego żądania na liście, czyli dokumentu HTML, otwiera się karta Nagłówki z sekcją Nagłówki odpowiedzi. Tam widać wartość Cache-Control, znacznik ETag oraz nagłówki dopisane przez warstwy pośrednie. Wiele wtyczek, serwerów i sieci CDN dodaje własny nagłówek informujący o trafieniu lub chybieniu. Jego nazwa zależy od dostawcy, dlatego warto poszukać jej w dokumentacji używanego rozwiązania. O pochodzeniu odpowiedzi z pamięci wspólnej świadczy też nagłówek Age, który podaje, ile sekund temu kopia została utworzona.

Dokumentacja panelu Sieć w narzędziach Chrome opisuje dwa przydatne elementy. Pole wyboru Wyłącz pamięć podręczną sprawia, że przeglądarka zachowuje się jak przy pierwszej wizycie, co pozwala ocenić stronę oczami nowego klienta. Opcja Wyczyść pamięć podręczną przeglądarki, dostępna po kliknięciu prawym przyciskiem myszy w tabeli żądań, usuwa lokalne kopie. Test najlepiej wykonywać w oknie incognito, bez zalogowania do WordPressa.

Dwa żądania jedno po drugim

Prosty test polega na dwukrotnym pobraniu tej samej podstrony. Pierwsze żądanie po wyczyszczeniu pamięci powinno być chybieniem i trwać dłużej, drugie powinno być trafieniem i przyjść wyraźnie szybciej. Jeśli oba trwają podobnie długo, pamięć całej strony nie działa dla tego adresu albo coś ją omija, na przykład plik cookie lub parametr w adresie. Web.dev zaleca też, aby mieć sposób na celowe ominięcie pamięci, na przykład parametrem w adresie, i dzięki temu zmierzyć rzeczywisty czas pracy serwera.

Czas odpowiedzi serwera

Skutkiem działającej pamięci całej strony jest krótszy czas do pierwszego bajtu, w skrócie TTFB. Według opisu tego wskaźnika na web.dev dobry wynik to 0,8 sekundy lub mniej, a słaby to ponad 1,8 sekundy, przy czym progi te należy traktować jako przybliżone. Wartość dla prawdziwych odwiedzających podaje PageSpeed Insights, a przyczyny długiego czasu odpowiedzi omawiamy we wpisie o TTFB.

• Dokument HTML strony głównej i oferty wraca przy drugim żądaniu jako trafienie.
• Pliki stylów, skryptów i obrazów mają długi max-age oraz wersję w adresie.
• Koszyk, zamówienie i konto klienta mają dyrektywę private lub no-store i nigdy nie są trafieniem.
• Po edycji wpisu nowa treść jest widoczna w oknie incognito bez ręcznego czyszczenia.
• Produkt dodany do koszyka w jednej przeglądarce nie pojawia się w drugiej.
• Formularz kontaktowy wysyła wiadomość także z podstrony podanej z pamięci.
• Linki z parametrami kampanii nie tworzą osobnych kopii tej samej podstrony.

Pamięć podręczna a roboty Google i wskaźniki szybkości

Pamięć podręczna pomaga wyszukiwarce pośrednio: serwer odpowiada szybciej i stabilniej, a poprawne nagłówki pozwalają robotom nie pobierać ponownie niezmienionych zasobów. Nie jest to jednak czynnik, który sam podnosi pozycje, i nie należy tego oczekiwać.

Zgodnie z dokumentacją robotów Google infrastruktura indeksowania obsługuje nagłówki ETag i Last-Modified wraz z odpowiadającymi im nagłówkami żądań, a gdy odpowiedź zawiera oba, roboty korzystają z ETag. Google zaleca ustawianie obu. Pole max-age w nagłówku Cache-Control nie jest wymagane, ale pomaga robotom ustalić, kiedy ponownie odwiedzić dany adres.

Drugi związek dotyczy wskaźników Core Web Vitals. Web.dev podaje, że sieć CDN może skrócić czas do pierwszego bajtu i przyspieszyć dostarczenie dokumentu oraz plików potrzebnych do wyświetlenia największego elementu strony, czyli wpłynąć na LCP. Pamięć podręczna nie naprawi natomiast zbyt ciężkich obrazów, nadmiaru skryptów ani przesunięć układu. Te zagadnienia opisujemy osobno we wpisach o LCP i o Core Web Vitals.

Pomoc specjalisty jest uzasadniona zwłaszcza wtedy, gdy sklep ma własne funkcje zależne od klienta, gdy witryna działa w kilku językach lub walutach, gdy po włączeniu pamięci pojawiają się błędy trudne do odtworzenia albo gdy mimo wszystkich warstw czas odpowiedzi pozostaje długi. Konfigurację pamięci podręcznej sprawdzamy w ramach SEO technicznego, a jej stan opisujemy także w audycie SEO.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl