Strona lokalnej firmy usługowej miała prosty cel: zdobywać zapytania z telefonu. Problem w tym, że na urządzeniach mobilnych pierwsza treść pojawiała się po ponad 3 sekundach, a podstrony oferty potrafiły ładować się jeszcze dłużej. To case study przyspieszenia WordPressa na LiteSpeed pokazuje, co zmieniliśmy, jakie wyniki uzyskaliśmy i dlaczego sama zmiana hostingu nie jest magicznym przyciskiem „szybciej”.
To nie był rozbudowany sklep ani portal z milionami odsłon. Serwis miał około 35 podstron, formularz kontaktowy, blog, galerię realizacji i popularny kreator stron. Właśnie taki profil witryny jest typowy dla małych firm, freelancerów oraz usług lokalnych. A więc dla stron, na których każde dodatkowe oczekiwanie użytkownika może oznaczać mniej telefonów i formularzy.
Punkt wyjścia: wolny WordPress mimo dobrej treści
Przed optymalizacją witryna działała na standardowej konfiguracji, bez pełnego cache po stronie serwera. Obrazy były dodawane bez konsekwentnej kompresji, a WordPress uruchamiał te same zapytania PHP i do bazy danych przy niemal każdym wejściu użytkownika. W panelu były też aktywne wtyczki, których właściciel strony już nie używał.
Pomiary wykonane kilkukrotnie, z uwzględnieniem urządzeń mobilnych, wskazywały na następujący obraz: czas odpowiedzi serwera przekraczał 1,2 sekundy, największy element treści pojawiał się po 3,8-4,6 sekundy, a pełne wczytanie strony głównej często przekraczało 6 sekund. Wyniki zmieniały się zależnie od pory dnia, co jest normalne, ale problem był powtarzalny.
Właściciel nie potrzebował efektownego raportu pełnego zielonych ikon. Potrzebował strony, która szybko pokaże ofertę, numer telefonu i formularz. Dlatego priorytetem były realne odczucia odwiedzających, szczególnie na smartfonach i przy przeciętnym połączeniu mobilnym.
Co zmieniono na LiteSpeed
Pierwszym krokiem było przeniesienie strony na środowisko z serwerem LiteSpeed i dyskami NVMe. Sam szybki nośnik nie naprawi źle zbudowanej witryny, ale skraca czas operacji na plikach i bazie danych. Znacznie ważniejsze było jednak uruchomienie LiteSpeed Cache dla WordPressa.
Różnica między zwykłym cache w przeglądarce a cache generowanym przez LiteSpeed jest praktyczna. Gdy użytkownik odwiedza publiczną podstronę, serwer może podać gotową wersję HTML zamiast za każdym razem uruchamiać PHP, WordPressa, motyw i zestaw wtyczek. Przy stronie firmowej, gdzie większość treści jest publiczna i rzadko się zmienia, daje to bardzo wyraźny efekt.
Konfiguracja LSCache bez ustawień „na ślepo”
Wtyczkę LiteSpeed Cache skonfigurowano tak, aby cache obejmował stronę główną, ofertę, wpisy blogowe, archiwa i pozostałe publiczne widoki. Z cache wykluczono stronę logowania, panel administracyjny oraz adresy związane z formularzem. To podstawowa zasada: treści wspólne dla wszystkich można przechowywać w pamięci podręcznej, ale widoki zależne od użytkownika wymagają ostrożności.
Włączono również cache przeglądarki dla zasobów statycznych. Logo, arkusze stylów, skrypty i obrazy nie powinny być pobierane od zera przy każdej kolejnej wizycie. Dla powracającego użytkownika oznacza to krótsze ładowanie bez kolejnych kosztownych zapytań.
Nie aktywowaliśmy wszystkich przełączników naraz. Łączenie plików CSS i JavaScript, agresywne opóźnianie skryptów czy automatyczna optymalizacja kodu potrafią pomóc, ale na źle przygotowanym motywie mogą rozbić menu, slider albo formularz. Każdą zmianę testowano osobno na telefonie, komputerze oraz w trybie incognito po wyczyszczeniu cache.
Redis tam, gdzie rzeczywiście ma sens
Kolejnym elementem był Redis jako cache obiektowy. Nie zastępuje on cache całej strony, lecz przechowuje wyniki często wykonywanych operacji WordPressa i zapytań do bazy danych. Ma szczególny sens przy większej liczbie wtyczek, rozbudowanych filtrach, dynamicznych elementach albo stronie administracyjnej, z której korzysta kilka osób.
W tym przypadku Redis poprawił responsywność zaplecza i ograniczył powtarzalne obciążenie bazy. Nie był głównym bohaterem wyniku na stronie głównej - tam największą pracę wykonał cache LiteSpeed - ale uzupełnił konfigurację. To ważne rozróżnienie, bo nie każda technologia daje identyczny rezultat na każdej stronie.
Obrazy, które przestały ważyć tyle co cała oferta
Największy obraz w sekcji startowej miał ponad 1,8 MB. Na ekranie telefonu był wyświetlany w znacznie mniejszym rozmiarze, więc użytkownik pobierał dane, których faktycznie nie potrzebował. Zdjęcia przeskalowano, skompresowano i przygotowano w nowoczesnym formacie. Włączono też lazy load dla grafik umieszczonych niżej na stronie.
Lazy load nie powinien dotyczyć kluczowego obrazu widocznego od razu po wejściu na stronę. Jeśli ukryjemy za ładowaniem odroczonym element, który ma być największą treścią nad linią przewijania, możemy pogorszyć wynik zamiast go poprawić. Optymalizacja to nie zbiór modnych opcji. To decyzje podejmowane według roli konkretnego elementu.
Wyniki po wdrożeniu
Po ustabilizowaniu cache i sprawdzeniu wszystkich podstron czas odpowiedzi serwera spadł z poziomu ponad 1,2 sekundy do około 250-400 ms dla stron obsługiwanych z cache. Największy element treści na stronie głównej pojawiał się zazwyczaj po 1,7-2,2 sekundy na teście mobilnym, a łączna waga strony zmniejszyła się o ponad połowę.
Pełne ładowanie nadal zależało od urządzenia, sieci i zewnętrznych skryptów, lecz użytkownik znacznie szybciej widział ofertę oraz przycisk kontaktu. To jest wynik, który ma znaczenie biznesowe. Osoba szukająca hydraulika, księgowej czy wykonawcy nie analizuje raportu technicznego. Widzi albo nie widzi informacji, której potrzebuje.
W kolejnych tygodniach właściciel zauważył mniej zgłoszeń dotyczących „zacinającej się” strony i większy udział wejść, które przechodziły od razu na podstrony ofertowe. Nie przypisujemy całego wzrostu zapytań wyłącznie wydajności - wpływ mają kampanie, sezonowość, treść i pozycje w wynikach wyszukiwania. Szybsza strona usuwa jednak przeszkodę, która wcześniej odbierała część ruchu już na starcie.
Czego LiteSpeed nie naprawi automatycznie
LiteSpeed i LSCache to bardzo mocne narzędzia, ale nie zwalniają z porządków. Jeśli strona ładuje kilkanaście zewnętrznych skryptów reklamowych, używa ciężkiego filmu w tle i ma motyw zbudowany z przypadkowych dodatków, wynik nie będzie idealny. Cache ograniczy pracę serwera, ale nie zmniejszy samodzielnie każdego pliku wysyłanego do przeglądarki.
Podobnie wygląda sprawa sklepów WooCommerce. Karta produktu może być świetnie cacheowana, ale koszyk, konto klienta, stany magazynowe i ceny indywidualne są dynamiczne. Tu konfiguracja wymaga wykluczeń i testów całego procesu zakupu. W przeciwnym razie można uzyskać dobry wynik testu, ale zły wynik dla klienta.
Warto też pilnować aktualizacji. Po zmianie motywu, wtyczki formularza lub systemu zgód cookie należy sprawdzić stronę ponownie. Nowy dodatek może dodać ciężki skrypt albo wejść w konflikt z optymalizacją JavaScript. Szybkość nie jest jednorazowym projektem wykonanym „na zawsze”.
Jak odtworzyć ten efekt na własnej stronie
Zacznij od pomiaru strony przed zmianami i zapisz wyniki dla strony głównej, oferty oraz kontaktu. Następnie usuń nieużywane wtyczki, sprawdź wagę obrazów i dopiero wtedy uruchom LiteSpeed Cache. Włącz podstawowy cache, przetestuj stronę po wyczyszczeniu pamięci podręcznej, a zaawansowane opcje optymalizacji kodu wdrażaj pojedynczo.
Jeżeli hosting udostępnia Redis, użyj go po upewnieniu się, że Twoje wtyczki i motyw działają poprawnie. Dobrze jest też sprawdzić, czy masz dostęp do aktualnych kopii zapasowych i SSH. Przy zmianach wydajnościowych możliwość szybkiego cofnięcia konfiguracji daje więcej kontroli niż obietnica „jednego kliknięcia”.
W IQHost.pl LiteSpeed, NVMe, Redis, SSL, kopie zapasowe i migracja są elementami usługi, a nie dodatkami ukrytymi za promocyjną ceną na pierwszy okres. To ma znaczenie, gdy zależy Ci na przewidywalnym koszcie, a nie na rachunku, który rośnie przy odnowieniu.
Szybka strona nie musi być projektem dla dużej firmy z osobnym zespołem technicznym. Wystarczy uczciwie sprawdzić punkt wyjścia, uporządkować to, co zbędne, i korzystać z technologii dopasowanej do WordPressa. Użytkownik nie zapamięta nazwy serwera. Zapamięta, że Twoja oferta pojawiła się od razu, gdy jej potrzebował.
