Hosting i wydajność
Jak przyspieszamy WordPress: LiteSpeed Enterprise, LSCache oraz Redis dla każdej strony
Najszybsze żądanie WordPress to takie, które się nigdy nie wykonuje — oto jak nasz stos obsługuje większość wizyt z pamięci podręcznej, zanim PHP lub MySQL zostaną wywołane, i co to oznacza dla Core Web Vitals.
Najszybsze żądanie to takie, które nigdy się nie wykonuje
Standardowe żądanie WordPress jest zasobochłonne. Serwer WWW przekazuje zadanie do PHP, PHP uruchamia WordPress, wykonuje skrypty wtyczek, odpytuje bazę danych MySQL kilkadziesiąt razy, składa kod HTML i dopiero wtedy odsyła dane. W przypadku ruchliwej strony ten cały proces odbywa się dla każdego odwiedzającego i to właśnie na niego przypada prawie cały czas do pierwszego bajtu (time-to-first-byte).
Naszym rozwiązaniem jest upewnienie się, że w przypadku większości wizyt nic z tego w ogóle się nie dzieje. Na obsługiwanych przez nas stronach — ponad 100 000 witryn PBN oraz standardowym zarządzanym WordPress — zdecydowana większość wyświetleń stron front-endu jest obsługiwana jako wyrenderowana wcześniej pełna strona bezpośrednio z pamięci podręcznej, bez wywoływania PHP ani dotykania bazy danych. Reszta tego wpisu dotyczy tego, jak warstwy, które to umożliwiają, pasują do siebie i gdzie każda z nich znajduje swoje miejsce.
Ważne jest zrozumienie, że nie są to konkurujące ze sobą pamięci podręczne, spośród których musisz wybrać jedną. Pamięć podręczna całej strony, pamięć podręczna obiektów i brzeg sieci CDN obsługują różne klasy żądań, a ich wartość tkwi w tym, jak przekazują ruch między sobą.
LiteSpeed Enterprise + LSCache: warstwa całej strony
Każda strona działa na LiteSpeed Enterprise z serwerowym LSCache. Gdy odpowiedź front-endu jest podatna na buforowanie, serwer WWW opatruje ją nagłówkami sterującymi i tagami pamięci podręcznej LiteSpeed, a LiteSpeed serwuje całą stronę bezpośrednio przy kolejnym zapytaniu – bez uruchamiania procesu PHP i bez wykonywania zapytań MySQL. To najważniejszy czynnik wpływający na TTFB WordPress, ponieważ eliminuje całe uruchamianie aplikacji z krytycznej ścieżki.
Ponieważ LSCache działa wewnątrz serwera WWW, a nie w wtyczce PHP, zaczyna działać wcześniej w cyklu życia żądania i przechowuje strony w formie, którą serwer może natychmiast przesłać. Robot indeksujący pamięć podręczną utrzymuje popularne strony w stanie gotowości, dzięki czemu pierwszy odwiedzający po wyczyszczeniu pamięci nie musi płacić za ponowne wygenerowanie strony. Rezultatem jest zauważalnie niższy i bardziej stabilny wskaźnik TTFB niż w przypadku pamięci podręcznej opartej wyłącznie na wtyczce, dołączonej do ogólnego stosu, gdzie pamięć podręczna nadal znajduje się za PHP.
Nasza autorska wtyczka pamięci podręcznej klasy repozytorialnej jest instalowana fabrycznie i automatycznie aktualizowana na każdej stronie, poprawnie integrując WordPress z LSCache od razu po wyjęciu z pudełka. Na serwerze źródłowym spoza LiteSpeed po prostu nie generuje nagłówków dla całej strony i schodzi z drogi, podczas gdy pamięć podręczna obiektów i reguły wykluczeń nadal wykonują swoje zadanie – dzięki czemu zmigrowana strona nigdy nie pozostaje w uszkodzonym, częściowo skonfigurowanym stanie.
Jak zachować szybkość bez serwowania nieświeżych danych: ESI i inteligentne automatyczne czyszczenie pamięci podręcznej
Agresywne cachowanie całej strony ma dwa klasyczne tryby awarii: zaserwowanie zalogowanemu użytkownikowi cudzej strony oraz zaserwowanie komukolwiek strony, która powinna się zmienić. Oba te problemy są rozwiązywane na warstwie cache'owania, a nie poprzez cache'owanie w mniejszym stopniu.
ESI (Edge Side Includes) pozwala nam buforować stronę, pozostawiając otwory na elementy, które muszą pozostać dynamiczne. W sklepie opartym na WooCommerce strony katalogu, produktów i kategorii są serwowane z pamięci podręcznej całej strony w celu uzyskania jak najszybszego wskaźnika TTFB, podczas gdy ESI renderuje fragment koszyka, sumy mini-koszyka i stan konta dla każdego żądania. Koszyk, kasa, moje konto oraz wszelkie strony z tokenami nonce lub sesjami są domyślnie wykluczone. Klienci zawsze widzą swój własny koszyk i działającą kasę, a wszyscy inni otrzymują witrynę sklepu z pamięci podręcznej.
Świeżością zarządza inteligentne auto-czyszczenie. Haki czyszczenia uruchamiają się automatycznie po zmianie treści, produktów, cen lub zamówień, dzięki czemu odpowiednie strony w pamięci podręcznej odświeżają się od razu, a nie według harmonogramu. Możesz też wyczyścić pamięć podręczną na żądanie z poziomu pulpitu lub wewnątrz WordPress. Czyszczenie oparte na tagach oznacza, że edycja jednego wpisu czyści ten wpis oraz jego archiwum — a nie całą pamięć podręczną — więc pojedyncza edycja nie powoduje ponownego uruchamiania całej witryny na zimno.
Pamięć podręczna obiektów Redis dla każdej witryny: do tego, co nie może być całą stroną
Nie każde zapytanie może być statyczną stroną pełnostronicową. Zalogowane sesje, panel administracyjny WordPress, koszyki WooCommerce, wyszukiwanie oraz dynamiczne fragmenty pozostawione przez ESI – wszystko to musi przetwarzać kod PHP. W tych przypadkach celem staje się przejście od „pomijania aplikacji” do „pomijania bazy danych”.
Każda witryna otrzymuje własną, dedykowaną pamięć podręczną obiektów Redis. WordPress buforuje wyniki powtarzających się odczytów z bazy danych — opcje, transjenty, wyszukiwania wpisów i taksonomii, dane produktów oraz sesji WooCommerce — w pamięci, dzięki czemu to samo zapytanie nie jest wykonywane w MySQL przy każdym żądaniu. Efekt jest najbardziej widoczny dokładnie tam, gdzie pamięć podręczna całej strony nie może pomóc: szybsze pulpity, szybszy koszyk i znacznie mniejsze obciążenie bazy danych przy dużym ruchu.
Pamięć podręczna obiektów jest przypisana do konkretnej strony, a nie współdzielona, co ma znaczenie zarówno dla wydajności, jak i izolacji. W połączeniu z ograniczaniem bazy danych dla poszczególnych stron, duże lub źle napisane zapytania jednej strony nie mogą pozbawić bazy danych zasobów potrzebnych sąsiednim stronom. Więcej informacji o tym, jak cała wielowarstwowa konfiguracja współpracuje ze sobą, można przeczytać na naszej stronie funkcji buforowania, a o granicach między dzierżawcami w ramach izolacji — w sekcji dotyczącej izolacji.
Brzeg i sieć transportowa pod spodem
Pamięć podręczna znajdująca się na serwerze źródłowym nadal musi przebyć sieć. Przed serwerem znajduje się sieć CDN edge, dzięki czemu zasoby statyczne i strony podlegające buforowaniu są obsługiwane z punktu obecności zlokalizowanego blisko odwiedzającego, a serwer źródłowy pozostaje obciążony w minimalnym stopniu nawet przy dużym ruchu. W przypadku naszej linii hostingu wolnego od footprintu ta sama krawędź to pula złożona z wielu sieci CDN rozproszona pomiędzy kilku dostarczycieli, co służy zarówno celowi związanemu z footprintem, jak i wydajnością; w przypadku standardowego WordPress jest to po prostu szybka, dobrze funkcjonująca warstwa, która utrzymuje serwery źródłowe w stanie bezczynności.
Pod spodem nie oszczędza się na fundamentach. Witryny działają na pamięci masowej NVMe z protokołem HTTP/3, więc bajty wysyłane przez pamięć podręczną docierają przez nowoczesny, zmultiplexowany transport z szybkim dyskiem stojącym za każdym chybieniem pamięci podręcznej. Żadna z tych warstw nie jest dodatkiem: LiteSpeed, LSCache, Redis dla każdej witryny, NVMe i HTTP/3 stanowią bazę w każdym planie, a nie droższy pakiet.
Co tak naprawdę wpływa na Core Web Vitals
Warto być precyzyjnym, ponieważ w przypadku hostingu często nadużywa się kwestii Core Web Vitals. TTFB to ta część równania, za którą odpowiada serwer, a znajdujący się powyżej stos buforowania jest tym, co obniża jego wartość – w całości zacofandowana strona pełna serwowana przez HTTP/3 z węzła brzegowego to niemal najniższy możliwy poziom TTFB. Ponieważ TTFB jest kluczowym elementem wskaźnika Largest Contentful Paint, szybkie źródło zapewnia każdemu kolejnemu wskaźnikowi przewagę startową, jakiej nie mógłby uzyskać w żaden inny sposób.
Ale o LCP, CLS i INP decyduje głównie przeglądarka oraz sama strona: nie zoptymalizowany obraz główny, blokujący renderowanie kod CSS i JavaScript, układ zmieniający się wraz z wczytywaniem czcionek i reklam oraz duże obciążenie głównego wątku przez wtyczki. Żadna ilość pamięci podręcznej serwera nie naprawi obrazu o wielkości 2 MB ani motywu, który ładuje megabajty kodu JavaScript. Uczciwy hosting sprawia, że wkład serwera jest praktycznie darmowy i stabilny, a zadaniem witryny jest zadbanie o lekkość interfejsu.
Ten podział pracy jest pożytecznym modelem myślowym. Gwarantujemy, że żądanie dociera do przeglądarki szybko i pozostaje szybkie przy dużym ruchu; Ty dbasz o to, aby ładunek był mały i stabilny. Tam, gdzie te dwie sfery się spotykają – rozgrzewanie pamięci podręcznej, dostarczanie z brzegu sieci (edge delivery) oraz utrzymywanie responsywności bazy danych, aby strony dynamiczne nie zwalniały – dokładnie tam nasz stos technologiczny jest zoptymalizowany i właśnie to sprawia, że zarządzany WordPress na tej platformie działa szybciej niż ta sama witryna u zwykłego dostawcy hostingu.
Często zadawane pytania
Czy nadal potrzebuję wtyczki do buforowania, takiej jak WP Rocket?
Nie. Buforowanie całej strony jest obsługiwane na poziomie serwera przez LSCache od LiteSpeed, a nasza własna wtyczka pamięci podręcznej – fabrycznie zainstalowana i automatycznie aktualizowana – poprawnie łączy z nim WordPress, wykorzystując dedykowaną dla każdej witryny pamięć obiektową Redis. Instalowanie drugiej wtyczki do buforowania całej strony zazwyczaj koliduje z pamięcią podręczną na poziomie serwera, zami pomagać, dlatego nie jest ono ani wymagane, ani zalecane.
Czy pamięć podręczna (caching) wpłynie negatywnie na działanie koszyka WooCommerce lub stron dla zalogowanych użytkowników?
Koszyk, kasa, moje konto oraz wszelkie strony z jednorazowymi tokenami (nonce) lub sesją są domyślnie wyłączone z pamięci podręcznej, a technologia ESI utrzymuje fragment koszyka oraz sumy w czasie rzeczywistym na stronach, które poza tym są buforowane. Klienci zawsze widzą swój własny koszyk oraz działającą kasę, podczas gdy sklep nadal ładowuje się z pamięci podręcznej.
Jak pamięć podręczna jest aktualizowana podczas publikowania lub edycji?
Inteligentne automatyczne czyszczenie uruchamia się na odpowiednich hookach WordPress, więc publikowanie, edycja treści lub zmiana produktu, ceny albo zamówienia usuwa z pamięci podręcznej tylko dotknięte strony i ich archiwa – a nie całą pamięć podręczną – a crawler rozgrzewa je ponownie. Możesz również wyczyścić pamięć podręczną na żądanie z poziomu panelu sterowania lub z wnętrza WordPress.
Czy sam hosting może zapewnić mi idealne Core Web Vitals?
Zapewnia to najlepszy możliwy wskaźnik TTFB, który jest udziałem serwera i daje przewagę w Largest Contentful Paint. Jednak o LCP, CLS i INP decyduje w dużej mierze sama strona — rozmiary obrazów, zasoby blokujące renderowanie, stabilność układu oraz JavaScript w głównym wątku. Nasz stos technologiczny sprawia, że wkład serwera jest szybki i niezawodny; utrzymanie lekkości ładunku front-endu to sposób na domknięcie pozostałej części.
Powiązane
Wypróbuj bezpłatnie przez 14 dni
Uruchom swoje pierwsze strony za darmo na 14 dni – bez karty. Prnosisz istniejącą sieć? Pierwszą migrację biorymy na siebie.
Rozpocznij za darmo