Cache przyspieszył stronę 4x, a PageSpeed dalej był czerwony

Dwie strony naszych klientek odpowiadały wolno: 300-400 milisekund na każdej podstronie, zanim serwer w ogóle zaczął wysyłać HTML. Oczekiwanie było proste: „włączcie cache, PageSpeed zrobi się zielony”. Włączyliśmy. Czas odpowiedzi serwera spadł do 80-130 ms, czyli mniej więcej czterokrotnie. A PageSpeed na telefonie dalej pokazywał pomarańczowy wynik i czerwony czas wyświetlenia głównej treści. Jeśli zastanawiasz się, jak działa wtyczka cache a PageSpeed i czy jedno naprawdę przekłada się na drugie, ta historia pokaże Ci, co cache poprawia, a czego w ogóle nie dotyka.

Kontekst: dwie strony, jedna obietnica, której nie da się dotrzymać

Obie strony stały na serwerze LiteSpeed. Pierwsza to sklep na WooCommerce, druga to platforma kursowa ze sklepem i kokpitem kursanta. Na obu każda podstrona generowała się od zera przy każdym wejściu: PHP, zapytania do bazy, wtyczki, motyw. Stąd 300-400 ms do pierwszego bajtu odpowiedzi.

Mieliśmy też twarde założenie z naszej praktyki: wtyczki „przyspieszające” często pogarszają stronę. Minifikacja psuje skrypty, łączenie plików rozwala kolejność ładowania, wymuszony WebP podmienia obrazki, a dwie wtyczki cache naraz walczą ze sobą. Dlatego cache miał zostać na stronie tylko wtedy, gdy pomiar pokaże realny zysk. Bez pomiaru nie da się odróżnić „pomogło” od „zepsuło”.

Jak włączaliśmy cache: tylko z pomiarem przed i po

Zamiast klikać w ustawieniach wtyczki, napisaliśmy jeden skrypt, który robi całość i sam podejmuje decyzję:

1. mierzy czas odpowiedzi serwera (TTFB) na kilku podstronach, po trzy razy, i uruchamia Lighthouse,
2. wybiera mechanizm cache po nagłówku serwera: na LiteSpeed jest to LiteSpeed Cache, bo serwer oddaje stronę z pamięci, zanim w ogóle ruszy PHP, i żadna wtyczka zapisująca pliki tego nie przebije,
3. włącza cache z wykluczeniami: koszyk, zamówienie, moje konto, kokpit kursanta, logowanie, rejestracja, REST API, a do tego ciasteczka zalogowanych użytkowników i koszyka,
4. jawnie wyłącza wszystko, co psuje strony: minifikację, łączenie plików, leniwe ładowanie, konwersję do WebP, CDN, osobny cache dla telefonów i cache obiektów,
5. sprawdza, że strona główna idzie z cache, a koszyk i konto nie,
6. mierzy ponownie i wydaje werdykt: cache zostaje tylko przy co najmniej 30 procentach poprawy na co najmniej połowie mierzonych stron. W przeciwnym razie skrypt sam go wyłącza.

Ślepe uliczki, na które wpadliśmy po drodze

Na papierze plan był prosty. W praktyce pięć rzeczy wyglądało jak błąd, a było czymś innym.

1. Druga wtyczka cache już tam była

Na jednej ze stron działała wcześniej wtyczka WP-Optimize, z własnym plikiem obsługującym cache. Dwie wtyczki cache na jednej stronie to konflikt: każda chce decydować, co i kiedy zapamiętać. Zbędną skasowaliśmy, a nie tylko wyłączyliśmy, razem z jej ustawieniami w bazie. Od tej pory skrypt odmawia startu, jeśli wykryje aktywną obcą wtyczkę cache.

2. Komunikat o konflikcie świecił mimo usunięcia wtyczki

Po skasowaniu WP-Optimize w kokpicie dalej wisiał komunikat LiteSpeed „wyłącz następujące wtyczki”. Wyglądało to na starą stronę z pamięci przeglądarki. Nie było: LiteSpeed Cache trzyma taki komunikat przypięty w opcji w bazie danych, a przycisk „Odrzuć” go nie usuwa. Pomogło dopiero usunięcie tej opcji:

wp option delete litespeed.admin_display.msg_pin

3. Walidator twierdził, że wykluczenia się nie zapisały

Skrypt po włączeniu sprawdzał, czy lista wykluczonych adresów jest zapisana. Zgłaszał błąd i sam wyłączał cache, który działał poprawnie. Przyczyna: LiteSpeed Cache trzyma takie ustawienia w bazie jako tekst w formacie JSON, a nie jako tablicę. Porównanie tablicy z tekstem zawsze dawało „różne”. Po dekodowaniu JSON-u walidator przestał kłamać.

4. Brak kompresji, który był kompresją

Sprawdzaliśmy kompresję HTML komendą curl -I, czyli zapytaniem typu HEAD. Na LiteSpeed takie zapytanie nie zwraca nagłówka Content-Encoding, więc wyglądało to na brak kompresji. Zwykłe zapytanie GET pokazało, że kompresja działa. Sprawdzaj więc tak:

curl -s -o /dev/null -D - -A "Mozilla/5.0" -H "Accept: text/html" https://twojadomena.pl/ | grep -i -E "content-encoding|litespeed"

5. Drugi pomiar „przed” był już z cache

Gdy skrypt uruchomiliśmy drugi raz na stronie z działającym cache, pomiar „przed” mierzył stronę już przyspieszoną. Porównanie wychodziło „nie szybciej” i skrypt chciał wyłączyć cache. Teraz zachowuje pierwszy pomiar i potrafi przeliczyć werdykt bez mierzenia od nowa.

Efekt: serwer około 4 razy szybszy

Werdykt na obu stronach: szybciej, cache zostaje. Oto pomiary czasu do pierwszego bajtu z naszego skryptu:

I teraz najważniejsze. PageSpeed Insights po włączeniu cache pokazał na telefonie 77 punktów na pierwszej stronie i 73 na drugiej. Na komputerze 96 i 92. Czas wyświetlenia największego elementu (LCP) na telefonie: 5,0 sekundy na pierwszej stronie i 8,0 sekundy na drugiej. Obie wartości są w czerwonej strefie, bo Google za dobry wynik uznaje do 2,5 sekundy.

Dlaczego cache nie poprawia wyniku PageSpeed na telefonie?

Bo PageSpeed mierzy głównie to, co dzieje się w przeglądarce, a cache przyspiesza tylko serwer. Odpowiedź serwera to w raporcie jedna pozycja, u nas po włączeniu cache rzędu 50-70 ms. Reszta wyniku to praca telefonu: pobranie i wyświetlenie obrazów, czcionek, skryptów, styli.

Raporty pokazały u obu klientek tych samych winowajców:

• ciężki element na pierwszym ekranie, czyli duże zdjęcie, wideo albo czcionka w sekcji powitalnej. To on wyznacza LCP,
• nieużywany JavaScript w motywie, około 200 KiB kodu ładowanego na każdej podstronie, choć większość z niego na danej podstronie nic nie robi.

Cache poprawia czas odpowiedzi serwera i nic poza nim. Czerwony wynik na telefonie robią ciężkie elementy pierwszego ekranu i nadmiar skryptów w motywie. Obietnica „zazielenimy PageSpeed wtyczką cache” to obietnica, której nie da się dotrzymać.

Czy w takim razie cache nie ma sensu? Ma, i to duży. Szybszy serwer to szybsze przechodzenie między podstronami, mniejsze obciążenie hostingu przy większym ruchu i lepsze odczucia osób, które klikają po sklepie. To po prostu inny problem niż wynik PageSpeed na telefonie.

Jak sprawdzić to u siebie

1. Zmierz czas odpowiedzi serwera przed jakąkolwiek zmianą, kilka razy dla kilku podstron: curl -s -o /dev/null -w "%{time_starttransfer}\n" https://twojadomena.pl/. Zapisz wyniki.
2. Sprawdź, czy nie masz już wtyczki cache albo optymalizacji. Dwie naraz to proszenie się o kłopoty.
3. Na serwerze LiteSpeed użyj LiteSpeed Cache. Na innych serwerach wybierz jedną prostą wtyczkę zapisującą strony do plików.
4. Wyklucz z cache koszyk, zamówienie, konto, logowanie, panel kursanta i REST API.
5. Nie włączaj minifikacji, łączenia plików ani wymuszonego WebP tylko dlatego, że są w ustawieniach. Każda z tych opcji potrafi zepsuć stronę.
6. Zmierz ponownie. Brak wyraźnej poprawy oznacza, że wąskie gardło jest gdzie indziej, i cache warto wyłączyć.
7. W PageSpeed Insights otwórz diagnostykę LCP i listę nieużywanego JavaScriptu. Tam jest prawdziwa robota przy wyniku na telefonie.

Czego nauczyła nas ta historia

Narzędzie, które coś zmienia na stronie klienta, musi umieć udowodnić, że pomogło, i samo się wycofać, jeśli nie pomogło. A każdy walidator trzeba sprawdzić na prawdziwym zachowaniu wtyczki, bo trzy z pięciu naszych ślepych uliczek wzięły się z tego, że nasze sprawdzenie źle odczytywało stan, a nie z tego, że coś nie działało. Klientkom mówimy dziś wprost przed włączeniem: cache przyspieszy serwer, a wynik na telefonie to osobna praca w motywie i treści.

FAQ

Czy wtyczka cache poprawi wynik PageSpeed na telefonie?

Zwykle w niewielkim stopniu. Cache skraca czas odpowiedzi serwera, który w raporcie PageSpeed jest jedną z wielu pozycji. Wynik na telefonie zależy głównie od wagi elementów pierwszego ekranu i ilości skryptów.

Co to jest TTFB?

Time To First Byte, czyli czas od wysłania zapytania do otrzymania pierwszego bajtu odpowiedzi. Pokazuje, jak szybko serwer przygotowuje stronę. Cache potrafi go skrócić kilkukrotnie, bo serwer oddaje gotową kopię zamiast generować stronę od nowa.

Czy można mieć dwie wtyczki cache naraz?

Nie warto. Dwie wtyczki zapamiętujące strony albo optymalizujące pliki wchodzą sobie w drogę i trudno potem ustalić, która co zepsuła. Zostaw jedną, drugą usuń razem z jej ustawieniami.

Które strony wykluczyć z cache w WooCommerce?

Koszyk, zamówienie, moje konto, logowanie i rejestrację, a na platformie kursowej także kokpit kursanta. Do tego warto wykluczyć ruch użytkowników zalogowanych i osób z produktami w koszyku, rozpoznawanych po ciasteczkach.

Jak sprawdzić, czy LiteSpeed Cache działa?

Wyślij zwykłe zapytanie GET i spójrz na nagłówek X-LiteSpeed-Cache. Wartość hit oznacza stronę z pamięci, miss to strona właśnie zapisana do pamięci. Po wyczyszczeniu cache pierwsze wejście da miss, drugie hit.

Co realnie poprawia LCP na telefonie?

Lżejszy element na pierwszym ekranie: mniejsze i dobrze skompresowane zdjęcie, rezygnacja z wideo w tle, mniej wariantów czcionek. Do tego ograniczenie skryptów ładowanych na każdej podstronie. To praca w motywie i treści, nie w ustawieniach wtyczki cache.

Chcesz szybszą stronę bez psucia tego, co działa? Napisz do nas

Jeśli Twoja strona na WordPressie lub WooCommerce działa wolno, a kolejne wtyczki „przyspieszające” niewiele zmieniają, zmierzymy, gdzie ucieka czas, i powiemy uczciwie, co da cache, a co wymaga pracy w motywie. Pomagamy też dobrać serwer, jeśli to on jest wąskim gardłem, w ramach hostingu premium. Prowadzisz platformę z kursami? Zajrzyj na platformykursowe.pl.

Napisz do nas – sprawdzimy, co naprawdę spowalnia Twoją stronę