Jak rozgrzać cache strony na Macu — pomiar czasu odpowiedzi

Jeśli prowadzisz stronę internetową — na WordPressie, TYPO3, Drupalu, Shopify czy dowolnym innym CMS-ie — pewnie zauważyłeś, że pierwsza wizyta po wyczyszczeniu cache lub wdrożeniu jest boleśnie wolna, a każda kolejna szybka. To twój cache robi swoje. Pytanie brzmi: co z odwiedzającym, który przychodzi pierwszy?

W większości konfiguracji to on płaci pełną cenę. Czeka, aż serwer wyrenderuje stronę od zera, odpyta bazę danych, uruchomi każdą wtyczkę — i dopiero wtedy dostaje odpowiedź. Drugi odwiedzający, obsłużony już z cache, dostaje szybką wersję. Rozgrzewanie cache zamyka tę lukę, udając pierwszego odwiedzającego — na każdej stronie — żeby prawdziwi użytkownicy nie musieli nim być.

Ten wpis wyjaśnia, co tak naprawdę robi rozgrzewanie cache, dlaczego naiwne podejścia w rodzaju wget --recursive nie wystarczają i jak zmierzyć, czy twój cache działa. Na koniec przedstawimy natywne narzędzie na macOS stworzone specjalnie do tego celu.

Czym tak naprawdę jest rozgrzewanie cache?

Cache warmer to crawler o wąskim zadaniu: odwiedzić każdy adres URL twojej strony, aby serwer zapisał wygenerowaną odpowiedź w cache. Gdy prawdziwy użytkownik następnym razem poprosi o tę stronę, zostanie ona podana z cache — z Nginx FastCGI, Varnisha, LiteSpeeda, Redisa, wtyczki WordPressa takiej jak WP Rocket czy W3 Total Cache albo z węzła brzegowego CDN, np. Cloudflare czy Fastly.

Dobry cache warmer robi trzy rzeczy:

1. Wywołuje zapis w cache na każdej stronie (przebieg zimny).
2. Sprawdza, czy cache faktycznie się zapełnia i jest serwowany (przebieg ciepły).
3. Mierzy różnicę, żebyś wiedział, że twoja konfiguracja cache działa.

Na trzecim punkcie poległa większość narzędzi. Mnóstwo skryptów potrafi przejść po stronie. Bardzo niewiele mówi ci, czy to przejście dało cokolwiek użytecznego.

Kiedy rozgrzewanie cache ma znaczenie

Nie zawsze musisz rozgrzewać cache. Na małym blogu ze stabilnym ruchem i długimi czasami TTL pierwszy odwiedzający danego dnia rozgrzewa stronę w naturalny sposób. Są jednak sytuacje, w których rozgrzewanie nie jest opcjonalne:

• Po wdrożeniu. Większość mechanizmów cache unieważnia wpisy, gdy zmienia się aplikacja. Pierwsza wizyta na każdej stronie po wdrożeniu to zimne renderowanie. Jeśli masz 500 stron produktów i wdrażasz dwa razy dziennie, daje to 1000 wolnych pierwszych wizyt dziennie — wiele z nich od botów, crawlerów albo z linków marketingowych.
• Po wyczyszczeniu cache. Zaplanowane czyszczenia (nocne, przeładowania konfiguracji, importy treści) wymazują cały cache. Bez rozgrzewania najbliższa godzina ruchu to szturm na twój serwer źródłowy.
• Przy krótkich czasach TTL. Jeśli twój cache wygasa co 15 minut, każda strona jest 96 razy dziennie poza cache. Rozgrzewanie utrzymuje ją stale gorącą.
• Ze względu na SEO i Core Web Vitals. Googlebot karze wolne pierwsze odpowiedzi. Jeśli Googlebot akurat trafi na zimną stronę, cierpią twoje wyniki LCP i TTFB — a bot nie wróci pięć minut później, żeby zobaczyć szybką wersję.
• Przy kampaniach reklamowych i masowych wysyłkach e-maili. Gdy wysyłasz 50 000 odbiorców newslettera jednocześnie na stronę docelową, nie chcesz, żeby pierwszych 500 odwiedzających rzuciło serwer na kolana, zanim cache się zapełni.

Dlaczego wget --mirror nie wystarczy

Klasyczny odruch programisty to sięgnięcie po wget lub curl w pętli:

wget --recursive --no-directories --delete-after https://example.com

To w pewnym sensie działa. Odwiedza strony, co wywołuje renderowanie, co zapełnia cache. Ale nie daje ci żadnego wglądu w to, co się stało. Nie odpowiesz na żadne z ważnych pytań:

• Czy cache w ogóle zadziałał? Może twój nagłówek Cache-Control: no-cache po cichu niweczy całą konfigurację.
• Czy Cloudflare serwuje z węzła brzegowego, czy za każdym razem przepuszcza żądanie do serwera źródłowego? Nagłówek CF-Cache-Status to wie, ale wget ci go nie pokazuje.
• O ile szybsza jest odpowiedź z cache od zimnej? Czy to 80 ms wobec 2000 ms (świetnie), czy 800 ms wobec 900 ms (twój cache prawie nic nie robi)?
• Których stron brakuje w mapie witryny? Które zwracają 404? Które mają nagłówki cache, przez które nigdy nie trafią do cache?

wget zrzuca HTML i idzie dalej. Musisz ręcznie parsować logi, dodać --server-response, przepuścić wynik przez awk, a zanim dostaniesz użyteczny raport, wymyślisz od nowa pół narzędzia do analizy cache.

Co mierzy dobry cache warmer

Prawdziwym zadaniem nie jest samo odwiedzanie stron. Chodzi o to, by po przebiegu odpowiedzieć na te pytania:

• Współczynnik trafień cache. Ile z N stron zostało w drugim przebiegu podanych z cache?
• Czas odpowiedzi zimny a ciepły. Jakie było dla każdego URL opóźnienie przy pierwszej wizycie w porównaniu z drugą?
• Procent poprawy. O ile średnio szybciej odpowiadały strony z cache?
• Inwentaryzacja nagłówków cache. Które strony wysyłają Cache-Control: public, max-age=..., które no-store, które zwracają X-Cache: HIT albo CF-Cache-Status: DYNAMIC? Jednym spojrzeniem widzisz, gdzie twoja konfiguracja jest zepsuta.
• Błędy. Które adresy URL zwracają 404? Które przekraczają limit czasu? Które zwracają błędy 500 pod obciążeniem crawlera?

Bez tego rozgrzewasz na ślepo. Może co godzinę uruchamiasz zadanie cron, które obciąża twój serwer źródłowy, nie zapełniając ani jednego wpisu w cache — i nawet o tym nie wiesz.

Wykrywanie cache za kulisami

Nowoczesne strony działają na całym stosie warstw cache. Typowa strona na WordPressie u dostawcy hostingu zarządzanego może mieć:

• Cloudflare na brzegu sieci (CF-Cache-Status, Age)
• Cache LiteSpeed lub Nginx FastCGI na serwerze WWW (X-LiteSpeed-Cache, X-Cache)
• Varnish przed aplikacją (X-Varnish, Age)
• WP Rocket lub W3 Total Cache wewnątrz WordPressa (komentarze HTML, własne nagłówki)
• Cache obiektów (Redis, Memcached) dla zapytań do bazy — niewidoczny w nagłówkach HTTP

Gdy strona działa wolno, ważne jest, która warstwa nie trafiła. Jeśli Cloudflare zwraca HIT, a czas odpowiedzi nadal wynosi 800 ms, problem polega na tym, że Cloudflare serwuje nieaktualną i wolną odpowiedź z cache. Jeśli Cloudflare zwraca MISS, a LiteSpeed HIT, błędna jest konfiguracja brzegu sieci. Cache warmer, który analizuje nagłówki odpowiedzi, daje ci widok warstwa po warstwie.

Podobnie ważna jest wiedza o CMS-ie. WordPress, TYPO3, Drupal, Shopify, Magento, Ghost i generatory stron statycznych mają własne konwencje cache. Warmer, który rozpoznaje CMS, może podpowiedzieć odpowiednie ustawienia domyślne i wskazówki dotyczące wtyczek — wp-super-cache zachowuje się inaczej niż Drupal z Varnishem, a ten z kolei inaczej niż statycznie wyeksportowana strona na Hugo.

Odkrywanie mapy witryny — nie pomiń połowy stron

Samo śledzenie linków pomija strony, do których nie prowadzą linki ze strony głównej. Osierocone strony docelowe, zarchiwizowane wpisy na blogu, warianty produktów, archiwa z paginacją, strony tagów — są w mapie witryny, ale nie w głównej nawigacji. Jeśli nie przejdziesz po mapie witryny, te strony pozostaną zimne, a to często właśnie one ściągają ruch z wyszukiwarek.

Porządny warmer pobiera robots.txt, analizuje dyrektywy Sitemap: i przechodzi przez całe drzewo map witryny — łącznie z indeksami map, które odwołują się do wielu podrzędnych map. W połączeniu ze śledzeniem linków obejmuje to zarówno strony strukturalne, jak i treści z długiego ogona.

Natywny sposób na macOS: WebCacheWarmer

Jeśli chcesz mieć to wszystko bez samodzielnego składania, właśnie do tego powstał WebCacheWarmer. To natywna aplikacja na macOS, która wykonuje crawl w dwóch przebiegach:

• Przebieg 1 (zimny): odwiedza każdy znaleziony adres URL, wywołuje zapis w cache i mierzy zimny czas odpowiedzi.
• Przebieg 2 (ciepły): odwiedza każdy URL ponownie, mierzy czas odpowiedzi z cache i oblicza poprawę.

Na koniec dostajesz przejrzysty raport: liczba przejrzanych stron, błędy, średni czas zimny, średni czas ciepły, procent poprawy i współczynnik trafień cache. Widzisz dokładnie, które strony trafiają do cache, a które nie — a inspektor nagłówków cache pokazuje dlaczego.

Kilka szczegółów, które liczą się w codziennej pracy:

• Odkrywanie mapy witryny z robots.txt, z wbudowaną przeglądarką i eksportem do XML.
• Rozpoznawanie CMS-a: WordPress, Drupal, Shopify, TYPO3, Magento, Joomla, Wix, Squarespace, Ghost, Hugo, Jekyll i inne.
• Analiza nagłówków cache: Cache-Control, X-Cache, CF-Cache-Status, Age, ETag oraz nagłówki Varnisha i LiteSpeeda.
• Eksport do CSV, Excela lub JSON z pełnymi szczegółami nagłówków, dzięki czemu możesz śledzić kondycję cache w czasie albo przekazać raport dostawcy hostingu.
• Wbudowane pobieranie strony statycznej ze wznawianiem, trybem przyrostowym i lokalnym podglądem — przydatne do zarchiwizowania strony przed migracją.
• Zaplanowane ponowne crawle co 1, 4, 12 lub 24 godziny, by strony o dużym ruchu były stale rozgrzane.
• Przestrzeganie robots.txt z regułą najdłuższego dopasowania ścieżki, więc nie przechodzisz po ścieżkach, po których nie powinieneś.

Wszystko działa lokalnie na twoim Macu. Żadne dane nie są nigdzie wysyłane poza żądaniami HTTP do rozgrzewanej strony — co ma znaczenie, gdy przechodzisz po środowiskach testowych z treściami chronionymi dostępem.

Typowy proces pracy

1. Po wdrożeniu uruchom WebCacheWarmer na produkcyjnym adresie URL. Sprawdź współczynnik trafień cache w przebiegu ciepłym — ponad 90 % to zdrowy wynik, poniżej 50 % oznacza, że coś jest źle skonfigurowane.
2. Przejrzyj nagłówki cache stron, które w przebiegu ciepłym wróciły zimne. Zwykle chodzi o jedną z trzech rzeczy: brakujący nagłówek Cache-Control, ciasteczko blokujące cache albo parametr URL, który cache traktuje jako unikalny.
3. Wyeksportuj wyniki do CSV, jeśli musisz udostępnić je agencji, dostawcy hostingu albo współpracownikowi, który chce surowych liczb.
4. Zaplanuj ponowny crawl co kilka godzin, jeśli twoje czasy TTL są krótkie. Warmer utrzyma gorące strony gorącymi bez ręcznej interwencji.

Podsumowanie

Rozgrzewanie cache to jedna z tych praktyk operacyjnych, które zwracają się natychmiast, a mówi się o nich rzadko. Jeśli czasy odpowiedzi przy pierwszej wizycie są długie, a współczynnik trafień cache przeciętny, rozgrzanie po każdym wdrożeniu zamyka lukę — a prawdziwi użytkownicy dostają szybką wersję, którą twój cache miał dostarczać od samego początku.

To pomiar sprawia, że warto to robić. Cache, którego nie zmierzyłeś, to cache, co do którego tylko zgadujesz. WebCacheWarmer daje ci liczby, na żywo, w natywnej aplikacji na Maca, która szanuje twój czas i twoje dane.

Jeśli cenisz bezproblemowe narzędzia na Maca, które dobrze robią jedną rzecz, artykuł Konwersja CSV do Excela na Macu opisuje tę samą filozofię w pracy z arkuszami kalkulacyjnymi.