Hosting i wydajność
Jak przyspieszamy WordPress: LiteSpeed Enterprise, LSCache i Redis dla każdej witryny
Najszybsze żądanie WordPress to takie, które nigdy się nie wykonuje — oto jak nasz stos technologiczny obsługuje większość wizyt z pamięci podręcznej, zanim PHP lub MySQL zostaną w ogóle wywołane, i co to oznacza dla Core Web Vitals.
Najszybsze żądanie to takie, które nigdy się nie wykonuje
Standardowe żądanie WordPress jest kosztowne. Serwer WWW przekazuje zadanie do PHP, PHP uruchamia WordPress, wykonuje wtyczki, odpytuje MySQL kilkadziesiąt razy, składa HTML i dopiero wtedy odsyła bajty. Na obciążonej witrynie cały ten proces odbywa się dla każdego odwiedzającego i to właśnie tam ucieka niemal cały Państwa time-to-first-byte.
Naszą odpowiedzią jest zadbanie o to, aby w przypadku większości wizyt nic takiego w ogóle nie miało miejsca. W obrębie hostowanych przez nas witryn — ponad 100 000 witryn PBN oraz standardowych zarządzanych witryn WordPress — ogromna większość wyświetleń stron od strony użytkownika jest obsługiwana jako wstępnie wyrenderowana pełna strona bezpośrednio z pamięci podręcznej, bez wywoływania PHP ani odwoływania się do bazy danych. W dalszej części tego wpisu wyjaśniamy, jak współgrają ze sobą warstwy umożliwiające takie działanie i dlaczego każda z nich zasługuje na swoje miejsce.
Ważne jest zrozumienie, że nie są to konkurujące ze sobą pamięci podręczne, między którymi należy dokonać wyboru. Pamięć podręczna całych stron (full-page cache), pamięć obiektowa (object cache) oraz węzeł CDN obsługują różne rodzaje żądań, a ich wartość polega na wzajemnym przekazywaniu zadań.
LiteSpeed Enterprise + LSCache: warstwa pełnej strony
Każda witryna działa na serwerze LiteSpeed Enterprise z LSCache na poziomie serwera. Gdy odpowiedź front-endu kwalifikuje się do buforowania, serwer WWW oznacza ją nagłówkami sterowania pamięcią podręczną i tagami LiteSpeed, a LiteSpeed serwuje kompletną stronę bezpośrednio przy następnym wywołaniu — bez uruchamiania procesu PHP, bez wysyłania zapytań MySQL. Jest to najważniejszy pojedynczy czynnik wpływający na TTFB w WordPress, ponieważ usuwa cały rozruch aplikacji ze ścieżki krytycznej.
Ponieważ LSCache działa wewnątrz serwera WWW, a nie jako wtyczka PHP, rozpoczyna pracę wcześniej w cyklu życia żądania i przechowuje strony w postaci, którą serwer może natychmiast wyczyścić. Robot indeksujący pamięć podręczną utrzymuje popularne strony w stanie gotowości, dzięki czemu pierwszy odwiedzający po wyczyszczeniu nie ponosi kosztu ponownego wygenerowania strony. W rezultacie czas TTFB jest wyraźnie niższy i bardziej spójny niż w przypadku pamięci podręcznej opartej wyłącznie na wtyczce dołączonej do standardowego środowiska, gdzie pamięć podręczna nadal znajduje się za PHP.
Nasza własna wtyczka buforująca klasy repozytorium jest fabrycznie zainstalowana i automatycznie aktualizowana na każdej witrynie, bezproblemowo łącząc WordPress z LSCache od samego początku. Na serwerze źródłowym innym niż LiteSpeed po prostu nie wysyła nagłówków pełnych stron i ustępuje miejsca, podczas gdy pamięć podręczna obiektów oraz reguły wykluczeń nadal działają — dzięki czemu zmigrowana witryna nigdy nie pozostaje w uszkodzonym, na wpół skonfigurowanym stanie.
Utrzymanie szybkości bez serwowania nieaktualnych treści: ESI i inteligentne automatyczne czyszczenie
Agresywne buforowanie całych stron ma dwa klasyczne scenariusze błędów: serwowanie zalogowanemu użytkownikowi strony kogoś innego oraz serwowanie komukolwiek strony, która powinna była ulec zmianie. Oba te problemy rozwiązuje się na poziomie warstwy buforowania, a nie poprzez rzadsze buforowanie.
ESI (Edge Side Includes) pozwala buforować stronę, tworząc jednocześnie luki dla elementów, które muszą pozostać dynamiczne. W sklepie WooCommerce strony katalogu, produktów i kategorii są serwowane z pamięci podręcznej całej strony w celu uzyskania najszybszego możliwego wskaźnika TTFB, podczas gdy ESI renderuje fragment koszyka, sumy minikoszyka oraz stan konta dla każdego żądania. Koszyk, zamówienie, moje konto oraz wszelkie strony z kodami jednorazowymi (nonce) lub sesjami są domyślnie wykluczone. Klienci zawsze widzą swój własny koszyk i działający proces realizacji zakupu; każdy nadal otrzymuje witrynę sklepu z pamięci podręcznej.
Świeżość zapewnia inteligentne automatyczne czyszczenie pamięci podręcznej. Haki czyszczenia uruchamiają się automatycznie w przypadku zmiany treści, produktów, cen lub zamówień, dzięki czemu odpowiednie strony w pamięci podręcznej odświeżają się natychmiast, a nie według harmonogramu czasowego; mogą Państwo również czyścić pamięć podręczną na żądanie z poziomu panelu nawigacyjnego lub wewnątrz WordPress. Czyszczenie oparte na tagach oznacza, że edycja jednego wpisu czyści ten wpis i jego archiwa — a nie całą pamięć podręczną — dzięki czemu pojedyncza edycja nie powoduje ponownego ładowania całej witryny od zera.
Pamięć podręczna obiektów Redis dla każdej witryny: dla tego, co nie może być pełną stroną
Nie każde żądanie może być statyczną, pełną stroną. Zalogowane sesje, panel administracyjny WordPress, koszyki WooCommerce, wyszukiwanie oraz dynamiczne fragmenty pozostawione przez ESI na żywo – wszystkie muszą uruchamiać PHP. W ich przypadku cel zmienia się z „pomiń aplikację” na „pomiń bazę danych”.
Każda witryna otrzymuje własną, dedykowaną pamięć podręczną obiektów Redis. WordPress przechowuje w pamięci podręcznej wyniki powtarzających się odczytów z bazy danych — opcje, dane przejściowe (transients), zapytania o wpisy i taksonomie oraz dane produktów i sesji WooCommerce — dzięki czemu to samo zapytanie nie jest wykonywane w bazie MySQL przy każdym wywołaniu strony. Efekt jest najbardziej widoczny dokładnie tam, gdzie pamięć podręczna całych stron nie zdaje egzaminu: szybsze panele administracyjne, sprawniej działające koszyki oraz znacznie mniejsze obciążenie bazy danych przy dużym natężeniu ruchu.
Pamięć podręczna obiektów jest przypisana do konkretnej witryny, a nie współdzielona, co ma kluczowe znaczenie zarówno dla wydajności, jak i izolacji. W połączeniu z ograniczaniem przepustowości bazy danych dla poszczególnych witryn, ciężkie lub źle napisane zapytania jednej witryny nie pozbawią zasobów bazy danych sąsiadujących witryn. Mogą Państwo przeczytać więcej o tym, jak cała wielowarstwowa konfiguracja współpracuje ze sobą, na naszej stronie funkcji buforowania, a także o granicach między dzierżawcami w ramach izolacji.
Edge i leżący u podstaw transport
Pamięć podręczna znajdująca się na serwerze źródłowym nadal musi pokonać sieć. Przed serwerem znajduje się krawędź CDN, dzięki czemu zasoby statyczne i strony z możliwością buforowania są serwowane z punktu obecności w pobliżu użytkownika, a serwer źródłowy pozostaje nieobciążony nawet przy dużym ruchu. W przypadku naszej linii hostingu wolnej od śladów (footprint-free) ta sama krawędź to pula multi-CDN rozproszona pomiędzy wielu dostawców, co służy zarówno celom związanym z eliminacją śladów SEO (footprint), jak i wydajnością; w standardowym WordPress jest to po prostu szybka, poprawnie działająca warstwa, która odciąża serwery źródłowe.
Od strony technicznej nie oszczędzano na podstawach. Witryny działają na pamięci masowej NVMe z HTTP/3, dzięki czemu bajty wysyłane przez pamięć podręczną docierają za pośrednictwem nowoczesnego, multipleksowanego transportu z szybką pamięcią masową w przypadku każdego chybienia pamięci podręcznej. Żadna z tych warstw nie jest dodatkiem: LiteSpeed, LSCache, dedykowany dla każdej witryny Redis, NVMe oraz HTTP/3 stanowią standard w każdym planie, a nie droższy pakiet.
Co tak naprawdę wpływa na Core Web Vitals
Warto być precyzyjnym, ponieważ hosting jest często przeceniany w kontekście Core Web Vitals. TTFB to ta część równania, za którą odpowiada serwer, a powyższy stos buforowania pozwala ją obniżyć — pełna strona zapisana w pamięci podręcznej i serwowana przez HTTP/3 z krawędzi sieci osiąga niemal najniższy możliwy poziom TTFB. Ponieważ TTFB stanowi początkowy etap Largest Contentful Paint, szybki serwer źródłowy zapewnia każdemu kolejnemu wskaźnikowi przewagę na starcie, której nie dałoby się uzyskać w inny sposób.
Jednak o wskaźnikach LCP, CLS i INP decyduje głównie przeglądarka oraz sama strona: niezoptymalizowany obraz główny (hero), blokujące renderowanie arkusze CSS i kod JavaScript, układ przesuwający się podczas ładowania czcionek i reklam, a także obciążająca praca wątku głównego spowodowana przez wtyczki. Żadna ilość pamięci podręcznej na serwerze nie naprawi 2-megabajtowego obrazu głównego ani motywu dostarczającego megabajty kodu JavaScript. Uczciwy hosting sprawia, że wpływ serwera jest praktycznie pomijalny i spójny, a reszta zależy już od samej witryny, która musi zadbać o lekkość części front-endowej.
Taki podział obowiązków to użyteczny model myślowy. Gwarantujemy, że żądanie dotrze do przeglądarki szybko i zachowa tę szybkość pod obciążeniem; Państwo dbają o to, aby ładunek był niewielki i stabilny. Miejsce, w którym te dwa elementy się spotykają — rozgrzewanie pamięci podręcznej, dostarczanie na brzegu sieci oraz utrzymywanie responsywności bazy danych, aby dynamiczne strony się nie zawieszały — to dokładnie obszar, w którym nasz stos technologiczny jest zoptymalizowany, i to właśnie sprawia, że zarządzany WordPress na tej platformie działa szybciej niż ta sama witryna u zwykłego dostawcy usług hostingowych.
Często zadawane pytania
Czy nadal potrzebuję wtyczki buforującej, takiej jak WP Rocket?
Nie. Buforowanie całych stron jest obsługiwane na poziomie serwera WWW przez LSCache firmy LiteSpeed, a nasza własna wtyczka buforująca — wstępnie zainstalowana i automatycznie aktualizowana — prawidłowo łączy z nim WordPress, wykorzystując w tle pamięć podręczną obiektów Redis dla każdej witryny. Dodanie drugiej wtyczki do buforowania całych stron zazwyczaj koliduje z pamięcią podręczną na poziomie serwera, zamiast pomagać, dlatego nie jest to potrzebne ani zalecane.
Czy buforowanie zakłóci działanie mojego koszyka WooCommerce lub stron dla zalogowanych użytkowników?
Nie. Strony cart, checkout, my-account oraz wszelkie strony nonce lub session są domyślnie wykluczone z pamięci podręcznej, a ESI utrzymuje fragment koszyka i sumy na żywo na stronach w przeciwnym razie buforowanych. Klienci zawsze widzą swój własny koszyk i działający proces kasy, podczas gdy witryna sklepu nadal ładuje się z pamięci podręcznej.
W jaki sposób pamięć podręczna zachowuje świeżość, gdy publikuję lub edytuję?
Inteligentne automatyczne czyszczenie uruchamia się przy odpowiednich hookach WordPress, dzięki czemu publikowanie, edytowanie treści lub zmiana produktu, ceny czy zamówienia czyści tylko strony, których dotyczy zmiana, oraz ich archiwa — a nie całą pamięć podręczną — a robot indeksujący ponownie je rozgrzewa. Mogą Państwo również czyścić pamięć podręczną na żądanie z poziomu panelu nawigacyjnego lub wewnątrz WordPress.
Czy sam hosting może zapewnić mi idealne Core Web Vitals?
Zapewnia to najlepszy możliwy TTFB, co stanowi wkład serwera i daje przewagę w Largest Contentful Paint. Jednak LCP, CLS oraz INP zależą w dużej mierze od samej strony — rozmiarów obrazów, zasobów blokujących renderowanie, stabilności układu oraz kodu JavaScript w wątku głównym. Nasz stos technologiczny sprawia, że wkład serwera jest szybki i spójny; utrzymanie lekkości ładunku front-endu pozwala zniwelować resztę różnicy.
Powiązane
Wypróbuj bezpłatnie przez 14 dni
Uruchom swoje pierwsze witryny za darmo na 14 dni — bez podawania karty. Przenosisz istniejącą sieć? Migracje są bezpłatne i nielimitowane.
Rozpocznij za darmo