Cache prywatny czy publiczny?
Serwer LiteSpeed, za pośrednictwem wtyczki dla WordPress, pozwala na obsługę zarówno publicznej, jak i prywatnej pamięci cache.
Nie wdając się za bardzo w szczegóły — pamięć publiczna serwowana jest niezalogowanym użytkownikom i ma czas życia liczony w dniach, natomiast pamięć prywatna jest unikatowa dla każdego użytkownika, a jej czas życia jest znacznie krótszy — zazwyczaj wyrażony w sekundach lub minutach.
Czas życia to okres od wygenerowania pamięci podręcznej do momentu, kiedy przestanie być aktualna i niezbędne będzie jej ponowne wygenerowanie (odświeżenie). Ponieważ generowanie pamięci podręcznej zajmuje zasoby serwera, warto, aby odbywało się jak najrzadziej.
Ze względu na długi czas życia, wykorzystanie pamięci publicznej jest znacznie bardziej efektywne — raz wygenerowana strona może być serwowana różnym użytkownikom przez wiele dni i w niewielkim stopniu obciążać serwer.
Niektóre strony, posiadające często zmieniającą się zawartość (w szczególności zależną od interakcji z konkretnym użytkownikiem), nie będą mogły wykorzystać dobrodziejstwa długich czasów życia pamięci publicznej. W takiej sytuacji możliwe jest wygenerowanie pamięci prywatnej i serwowanie jej tylko temu użytkownikowi, dla którego ma ona zastosowanie. Takie podejście zazwyczaj jest korzystniejsze niż brak pamięci podręcznej (kiedy nie można wykorzystać pamięci publicznej) i każdorazowe generowanie zawartości strony przy próbie jej wyświetlenia.
Jednak, dla stron o dużym ruchu, np. sklepów online korzystających z modułu WooCommerce, jednoczesne generowanie i zarządzanie pamięcią prywatną dla wielu użytkowników, choć odczuwalnie szybkie w przeglądarce, może wymagać sporych zasobów serwera (pamiętajmy, że pamięć prywatna jest unikatowa dla każdego użytkownika, więc przy 100 zalogowanych osobach oznacza to generowanie, utrzymywanie i odpowiednie serwowanie 100 unikatowych kopii aktualnie wyświetlanych podstron).
Opłacalność wykorzystania pamięci prywatnej jest tym mniejsza, im mniej obszarów wyświetlających unikatowe treści dynamiczne znajduje się na stronie.
Przykładowo, użytkownik posiadający przedmioty dodane do koszyka, wyświetlający stronę wpisu blogowego lub czytający regulamin, mógłby korzystać z pamięci publicznej z jedynie niewielkim obszarem (widokiem koszyka wyświetlanym w nagłówku) wygenerowanym specjalnie na jego potrzeby, zapisanym w pamięci prywatnej
ESI pozwala na scalanie zawartości pamięci publicznej oraz prywatnej i podawanie tak przygotowanych widoków użytkownikom końcowym. To rozwiązanie hybrydowe, które pozwala efektywnie wykorzystać zarówno bufor publiczny, jak i prywatny, maksymalizując wydajność i minimalizując zużycie zasobów serwera.
ESI w standardzie
Pewien problem z dostępnością ESI polega na tym, że LiteSpeed Cache nie jest w stanie, w pełni automatycznie, dzielić wszystkich obszarów strony na prywatne i publicznie, a następnie montować z wykorzystaniem mechanizmu Edge Side Includes.
W wersji 2.9.5 dostępnej w dniu publikacji tego artykułu LiteSpeed Cache dla WordPress „z automatu” potrafi wykorzystać ESI dla paska administratora, domyślnego modułu komentarzy dostarczonego z WordPress oraz koszyka WooCommerce. Pisząc „z automatu”, mam na myśli — bez konieczności wykonania zaawansowanej konfiguracji polegającej na wskazaniu obszarów strony, które mają korzystać z wybranego rodzaju pamięci, z określonym czasem życia.
ESI w widgetach
LiteSpeed Cache umożliwia definiowanie rodzaju pamięci podręcznej oraz czasu życia dla każdego widgetu z osobna.
Konfiguracja jest bardzo prosta — do okna widgetu widocznego na zapleczu dołączany jest przełącznik ESI pozwalający na spersonalizowanie bloku.
Włączenie ESI dla widgetu może mieć sens w przypadku korzystania z widgetów wyświetlających często zmieniającą się zawartość, np. pobieraną z zewnętrznych źródeł (wydarzenia z kalendarza Google, RSS z zewnętrznych stron itp.).
ESI w shortcode
Od wersji 2.8 wtyczki, dostępny jest krótki kod (shortcode) „esi”, który pozwala na aktywację mechanizmu ESI dla dowolnego shortcode na stronie.
Dzięki temu możemy poinformować serwer LiteSpeed, aby dla wybranej części strony (generowanej z wykorzystaniem shortcode), korzystał z określonego rodzaju pamięci podręcznej (domyślnie — prywatnej). Możemy także zdefiniować czas życia takiego bloku.
Przykładowo, jeżeli posiadamy shortcode:
[ myeventlist month="December" year="2018" ]
Możemy go zmodyfikować do postaci:
[ esi myeventlist month="December" year="2018" cache="private" ttl="300" ]
Co sprawi, że shortcode wywołujący listę wydarzeń będzie serwowany z pamięci prywatnej z czasem życia wynoszącym 300 sekund. Pozostała część strony (zakładając, że nie posiada innych bloków ESI) będzie ładowana z publicznego bufora o długim czasie życia.
Shortcode ESI posiada formułę:
[ esi + oryginalny shortcode wraz ze swoimi parametrami + opcjonalne parametry esi ]
Jednocześnie należy pamiętać, że po dezaktywacji LiteSpeed Cache, shortcody zaczynające się od „esi” przestaną być rozumiane i przetwarzane przez WordPress, więc konieczna będzie ich zmiana do postaci pierwotnej.
Co więcej, LiteSpeed Cache nie wie, w wyniku jakich wydarzeń powinno nastąpić wyczyszczenie bloku oznaczonego shortcodem ESI. Należy o tym pamiętać, definiując czas życia shortcodu (powinien być odpowiednio krótki, aby wdrożenie ESI miało sens i nie powodowało wyświetlania nieaktualnych danych).
ESI z obsługą nonce
Nonce to mechanizm bezpieczeństwa, jednorazowy identyfikator stosowany w WordPress, aby chronić adresy URL oraz formularze. Wbrew nazwie, której rozwinięcie to „number used once”, czyli „liczba wykorzystywana jednorazowo”, w WordPress nonce mają swój czas życia, po którym wygasają.
Nonce używane są w funkcjach wtyczek oraz motywów i ze względu na swój ograniczony czas życia, w określonych sytuacjach mogą uniemożliwić generowanie efektywnej publicznej pamięci podręcznej z długim czasem życia.
Przykładowo, jeżeli nonce wykorzystywany w formularzu na stronie ma czas życia wynoszący 12 godzin, a strona ładowana jest z pamięci publicznej wygenerowanej 24 godziny temu, próba przesłania danych (poprawnych, domyślnie akceptowanych przez formularz), zakończy się wyświetleniem błędu, ponieważ nonce stracił swoją ważność.
Począwszy od wersji 2.9.5 wtyczki LiteSpeed Cache dla WordPress, wszystkie nonce są automatycznie zamieniane na obiekty ESI, co znakomicie przyczynia się do wzrostu kompatybilności z szeroką gamą dodatków dla WordPress.
Jeżeli spotkałeś się z błędami związanymi z nonce, uniemożliwiającymi skorzystanie z LiteSpeed Cache lub innych modułów keszujących, przetestuj nową wersję wtyczki od LiteSpeed — jest całkiem prawdopodobne, że umieszczanie nonce w pamięci prywatnej umożliwi wdrożenie wydajnej pamięci podręcznej dla Twojego serwisu.
Skrócenie czasu ładowania strony dzięki ESI i LiteSpeed Cache dla WordPress — jak to zrobić?
Aby skorzystać z Edge Side Includes w LiteSpeed Cache, potrzebujesz:
- Hostingu WWW opartego o komercyjne oprogramowanie LiteSpeed, np. Elastyczny Web Hosting w dhosting. Dowiedz się jak wybrać najlepszy hosting dla WordPress.
- Wtyczki LiteSpeed Cache dla WordPress.
- Aktywnego modułu lscache dla Twojej domeny. Jeżeli wtyczka LiteSpeed Cache po instalacji wyświetla błąd lub masz wrażenie, że Twoja strona wcale nie przyspieszyła, zapytaj helpdesk swojego hostingu czy moduł lscache jest aktywny. Niektóre firmy hostingowe (w tym dhosting) wymagają manualnej aktywacji.
- Włączonej funkcjonalności ESI w ustawieniach wtyczki LiteSpeed Cache.
- Wdrożenia ESI dla wybranych shortcode oraz widgetów lub skorzystanie z wtyczek, dla których autorzy LiteSpeed przewidzieli taką funkcjonalność (np. WooCommerce).
Podsumowanie, czyli ESI nie dla każdego
Zrozumienie, jak działają bufory pamięci publicznej oraz prywatnej, a także sensu mechanizmu ESI jest kluczowe do podjęcia decyzji o uruchomieniu tej funkcjonalności na swojej stronie internetowej.
ESI nie jest magicznym akceleratorem, który automatycznie przyspieszy ładowanie się strony, poprawi wynik w PageSpeed Insights oraz zwiększy ruch z wyszukiwarek.
ESI będzie jednak pomocne dla stron z dużą ilością zmiennej zawartości statycznej i dynamicznej o różnych czasach życia — szczególnie dla stron o dużym ruchu.
W zależności od architektury serwisu konfiguracja ESI może sprowadzać się do aktywacji modułu we wtyczce, ale równie dobrze może wymagać pogłębionej analizy ruchu na stronie w kontekście obciążenia serwera i czasów ładowania serwisu dla różnych grup użytkowników.
Wdrożenie efektywnej pamięci podręcznej jest jednym z lepszych sposobów na skrócenie czasu ładowania strony i dotyczy zarówno niewielkich stron prywatnych czy wizytówek firmowych, jak i rozbudowanych rozwiązań typu e-commerce.
Większa wydajność stron internetowych to wzrost zadowolenia użytkowników i lepsza dostępność treści, dlatego warto pamiętać o optymalizacji serwisu.