Fastest Cache : przyspiesz swoją stronę dzięki Varnish i NGINX

Procédure

Dlaczego warto przyspieszyć czas ładowania Twojej strony? 

Warto wiedzieć, że czas ładowania Twojej strony ma kluczowe znaczenie dla zapewnienia jej sukcesu. Na przykład dla firmy daje to pierwsze wrażenie odwiedzającym. Ponadto, zbyt długie ładowanie jej zawartości może mieć wpływ na pozycjonowanie Twojej strony w głównych wyszukiwarkach i nie pozwoli na wystarczającą ekspozycję, aby mogła ona funkcjonować.

Nie istnieje żaden próg, którego nie należy przekraczać w odniesieniu do czasu ładowania stron internetowych. Jednak czas ładowania większości stron internetowych jest krótszy niż trzy sekundy.

Czym jest Fastest Cache i do czego służy?

Narzędzie Fastest Cache to system zaprojektowany i opracowany przez LWS, umożliwiający optymalizację wydajności ładowania Twojej strony internetowej dzięki zastosowaniu mechanizmów cachowania stron, skonfigurowanych na poziomie serwera WWW. Narzędzie łączy technologie oferowane przez NGINX i Varnish.

NGINX to serwer WWW nastawiony na wydajność, pozwalający obsłużyć znacznie większą liczbę żądań w porównaniu z tradycyjnym serwerem WWW Apache HTTPd Server (zobacz nasz wpis na blogu zatytułowany “Apache VS Nginx : Test de performance”). LWS wykorzystuje NGINX, aby móc odbierać z góry dużą liczbę żądań HTTP bez utraty wydajności. Następnie może on zostać skutecznie przefiltrowany, aby wyeliminować złośliwe żądania (zob. LWS Protect) oraz przekierować żądania HTTP do serwera cache Varnish lub LiteSpeed, zależnie od wyboru klienta w jego panelu hostingowym.

Varnish to usługa HTTP implementująca mechanizm cachowania stron, umożliwiający zapisanie wyniku żądania HTTP w pamięci RAM.

Przy odpowiedniej konfiguracji NGINX umożliwia obsługę większej liczby żądań na Twojej stronie internetowej, a Varnish pozwala jednocześnie przyspieszyć czas ładowania strony oraz zmniejszyć zużycie CPU i pamięci RAM.

Jak działa usługa Fastest Cache?

Działanie bez cache

Aby lepiej zrozumieć działanie, najpierw zobaczymy, jak wygląda to bez systemu cache, aby odwiedzający mógł zobaczyć Twoją stronę.

1. Odwiedzający żąda strony od serwera WWW. Przykład: index.php
2. Serwer WWW wykonuje niezbędne skrypty (PHP, Python, Node.js …)
3. Serwer WWW otrzymuje wynik wykonania
4. Serwer WWW wysyła stronę HTML wynikającą z wykonania skryptu

Działanie z modułem Fastest Cache

Gdy Fastest Cache jest aktywowany, serwer cache zostaje wprowadzony pomiędzy odwiedzającego a serwer WWW.

Celem jest zmniejszenie liczby koniecznych wykonań skryptów poprzez zachowanie wyniku wykonania w pamięci dla kolejnych żądań wymagających tej samej odpowiedzi. Pozwala to uniknąć wielokrotnego uruchamiania tego samego skryptu w celu uzyskania tego samego wyniku.

W ten sposób eliminujemy czas oczekiwania na wykonanie skryptu z czasu ładowania strony, a przy okazji oszczędzamy zasoby zużywane podczas wykonywania skryptu.

11. Odwiedzający żąda strony od serwera WWW. Przykład: index.php
2. Fastest Cache sprawdza, czy odpowiedź może zostać pobrana z cache:

• Jeśli tak, strona jest zwracana bezpośrednio odwiedzającemu bez konieczności dostępu do usługi WWW i bez wykonywania skryptu
• Jeśli nie, strona jest generowana przez serwer WWW, co powoduje wykonanie skryptu (PHP, Node.js, Perl, Ruby, …). Po wygenerowaniu strony Fastest Cache określa, czy odpowiedź może zostać zachowana w cache.
  • Jeśli tak, strona jest zapisywana w pamięci cache i zwracana odwiedzającemu
  • Jeśli nie, strona jest zwracana odwiedzającemu bez zapisywania w pamięci cache

Widać, że gdy strona jest zapisana w pamięci cache, przetwarzanie przez serwer WWW oraz wykonanie skryptu zostają pominięte, co znacząco skraca czas wykonania i zużycie zasobów.

Zachowanie systemu cachowania

Fastest Cache opiera się na wielu sygnałach, aby zdecydować o przyjętym zachowaniu cachowania:

• Rozszerzenie pliku w adresie URL
• Obecność i zawartość parametrów URL (query strings)
• Nagłówek odpowiedzi Cache-Control
• Ciasteczka

Fastest Cache wykrywa również niektóre CMS-y oraz rozszerzenia / moduły i implementuje specyficzne zachowania cachowania związane z tymi narzędziami.

Zachowanie przy odbiorze żądania

Fastest Cache cache'uje tylko metody HTTP GET i HEAD.

Gdy odwiedzający wchodzi na URL, Fastest Cache normalizuje żądanie, usuwając ciasteczka i parametry URL, które nie wpływają na końcowy rendering skryptu po stronie serwera (parametry URL Google Analytics, ciasteczka związane ze skryptami Javascript ...).

Po normalizacji żądanie jest sprawdzane pod kątem uwierzytelniania HTTP (nagłówek żądania HTTP Authorization) lub obecności pozostałych ciasteczek (nagłówek żądania HTTP Cookie). Jeśli tak, żądanie zostanie odesłane do serwera WWW bez przechodzenia przez system cache.

Zachowanie przy wysyłaniu odpowiedzi

Jeśli żądanie nie ominęło cache w momencie jego odbioru, Fastest Cache ponownie analizuje dostarczoną odpowiedź HTTP od serwera WWW i sprawdza, czy można ją zachować w cache do przyszłego użycia.

Jeśli odpowiedź HTTP zawiera nagłówek odpowiedzi HTTP Cdn-Cache-Control, Fastest Cache natychmiast respektuje to, co zostało w nim określone:

• Jeśli ustawiono tam no-store, no-cache lub private, Fastest Cache zwraca odpowiedź odwiedzającemu bez zachowywania jej w cache.
• Jeśli ustawiono tam s-maxage lub max-age, Fastest Cache natychmiast używa tej wartości jako czasu przechowywania strony w cache.

Jeśli Cdn-Cache-Control jest ustawiony z Set-Cookie, Cdn-Cache-Control zostanie zignorowany, a odpowiedź nie zostanie zachowana w cache.

Pliki statyczne odpowiadające motywom, wtyczkom, uploads i core WordPress są automatycznie przechowywane w cache przez 30 dni.

Jeśli odpowiedź HTTP pochodzi z systemu cache stron LWS Optimize, WP Fastest Cache, Airlift, W3 Total Cache, WP Rocket, WP Optimize lub FastPixel, jest ona przechowywana w cache przez 7 dni. Te wtyczki WordPress same przeprowadzą czyszczenie cache Varnish, gdy usuwają cache strony.

Jeśli odpowiedź HTTP pochodzi z katalogu /_next/static, jest ona również przechowywana w cache przez 7 dni.

Jeśli odpowiedź HTTP zwraca kod HTTP 404, jest ona przechowywana w cache przez 900 sekund. Pozwala to ograniczyć liczbę niepotrzebnych zapytań do bazy danych MySQL, zwłaszcza w przypadku WordPressa.

Jeśli odpowiedź HTTP zwraca kod HTTP 500, odpowiedź nigdy nie jest przechowywana w cache.

Jeśli odpowiedź HTTP zawiera ciasteczko (nagłówek odpowiedzi HTTP Set-Cookie), odpowiedź nigdy nie jest przechowywana w cache.

Jeśli odpowiedź HTTP zawiera nagłówek odpowiedzi HTTP Cache-Control lub Surrogate-Control, Fastest Cache stosuje oczekiwane zachowanie cache dla przeglądarek. Jeśli te nagłówki są dostarczone wraz z Cdn-Cache-Control, Fastest Cache ignoruje Cache-Control i Surrogate-Control na rzecz Cdn-Cache-Control. Pozwala to na przykład wymusić na przeglądarce wysłanie żądania HTTP przy każdej wizycie w celu wyświetlenia listy artykułów, bez konieczności usuwania listy artykułów z cache serwera.

Prezentacja interfejsu i aktywacja usługi

Fastest Cache jest dostępny jako ikona w cPanelu w sekcji “Performance”.

Po wejściu do interfejsu na liście wyświetlają się domena główna, dodatkowe domeny i subdomeny.

• Kolumna “Statut cache” pokazuje stan aktywacji cache. Jeśli widnieje tam “Aktywny”, cache jest włączony.
• Przycisk “Wyczyść cache” pozwala usunąć wszystkie dane z cache dla tej konkretnej nazwy domeny.
• Przycisk “Wyłącz cache” pozwala wyłączyć cachowanie.
• Przycisk “Włącz cache” pozwala włączyć cachowanie.
• Przycisk “Zmień tryb działania” pozwala zmodyfikować zachowanie systemu cache. Tryby te zostaną wyjaśnione poniżej.

Różne tryby cache

Domyślnie system cache wybiera tryb « Użycie ogólne », który nadaje się do zastosowań ogólnych. Istnieją jednak inne tryby:

Tryb deweloperski : identyczny z wyłączeniem cache, pozwala to ominąć system cache w okresie prac rozwojowych.
WordPress : tryb cache bardziej dostosowany do WordPressa, w którym zarządzanie katalogami (wp-content, wp-admin, …) oraz specyficznymi ciasteczkami WordPressa jest ulepszone.
Prestashop : tryb cache bardziej dostosowany do Prestashop, w którym zarządzanie katalogami i ciasteczkami jest ulepszone.

Czyszczenie cache

Poza interfejsem cPanel umożliwiającym czyszczenie cache, możliwe jest ręczne wyczyszczenie cache z terminala SSH konta cPanel lub ze skryptu hostowanego na serwerze.

Uruchamiane z Twojego hostingu (skrypt PHP Twojej strony, zadanie Cron lub terminal SSH), metody te nie wymagają ani tokena API, ani identyfikatora : Fastest Cache bezpośrednio akceptuje metody HTTP PURGE.

Czyszczenie cache za pomocą cURL

Wyczyszczenie cache strony:

curl -X PURGE https://mon-site-web.com/mapage.php

Pozwoli to wyczyścić cache adresu URL https://mon-site-web.com/mapage.php.

Wyczyszczenie cache katalogu:

curl -X PURGE 'https://mon-site-web.com/wp-content/uploads/.*'

Pozwoli to wyczyścić wszystkie cache adresów URL zaczynających się od 'https://mon-site-web.com/wp-content/uploads/'

Wyczyszczenie cache witryny

curl -X PURGE https://mon-site-web.com/.*

W przypadku wszystkich trzech poleceń możliwe są trzy odpowiedzi:

Kod HTTP 200 : czyszczenie przebiegło pomyślnie, bez błędów.

Kod HTTP 4xx : czyszczenie nie jest dozwolone.

Kod HTTP 5xx : wystąpił błąd.

Automatyczne czyszczenie za pomocą skryptu PHP (zadanie Cron)

Poniższy skrypt czyści cache całej witryny albo tylko niektórych stron. Skopiuj go do pliku purge-cache.php na swoim hostingu, a następnie wpisz swoją domenę w $site. Aby czyścić tylko wybrane strony, wpisz je w $pages.

 'PURGE',
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_CONNECTTIMEOUT => 5,
        CURLOPT_TIMEOUT        => 20,
    ]);
    curl_exec($ch);
    $code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);
    return $code;
}

if (empty($pages)) {
    echo date('Y-m-d H:i:s') . ' purge complete : HTTP ' . purger($site . '/.*') . PHP_EOL;
}
else {
    foreach ($pages as $page) {
        echo date('Y-m-d H:i:s') . ' ' . $page . ' : HTTP ' . purger($site . $page) . PHP_EOL;
    }
}

Aby uruchamiać go automatycznie, na przykład każdej nocy, utwórz zadanie Cron, które wykonuje ten plik za pomocą PHP. Jeśli chcesz po prostu wyczyścić cały cache, zadanie Cron może również bezpośrednio wykonać:

curl -s -o /dev/null -X PURGE 'https://mon-site-web.com/.*'

Czyszczenie za pomocą wtyczki lub modułu

Większość wtyczek/modułów posiadających integrację z Varnish jest zgodna z wewnętrznym mechanizmem czyszczenia Fastest Cache.

Oto kilka przetestowanych i sprawdzonych, zgodnych wtyczek:

• LWS Optimize
• WP Fastest Cache
• WP Rocket
• Proxy Cache Purge

Wykrywanie HTTPS i przekierowania

Stan HTTPS i porty wskazane w Apache są wstrzykiwane do środowiska i zazwyczaj nie wymagają żadnych dodatkowych zmian.

Jeśli jednak wykrywanie HTTPS nie działa z Fastest Cache, może to powodować nieskończone pętle przekierowań. W takim przypadku konieczna będzie modyfikacja danych wykrywania.

Zaufane nagłówki HTTP używane do wykrywania to:

• X-Forwarded-Proto
• X-Forwarded-Port

Zatem jeśli używasz następującego przekierowania HTTPS z .htaccess:

RewriteEngine On 
RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

i jeśli to nie działa, możesz zastąpić zmienną SERVER_PORT przez X-Forwarded-Proto :

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} !on
RewriteRule ^(.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R]

CloudFlare i inne CDN

CDN-y typu CloudFlare mogą filtrować żądania HTTP, które mogłyby blokować żądania “PURGE” używane przez Fastest Cache do czyszczenia cache. Zaleca się wówczas podanie adresu IP serwera podczas czyszczenia za pomocą curl, aby ominąć CDN-y podczas operacji czyszczenia:

curl -X PURGE --resolve mon-site-web.com:443:IP_DU_SERVEUR 'https://mon-site-web.com/.*'

CDN-y mogą również zawierać dodatkową warstwę cache, którą należy obsługiwać niezależnie od cache dostarczanego przez Fastest Cache.