Przyspiesz swoją witrynę dzięki Fastest Cache - Cache Varnish

Procédure

Dlaczego warto przyspieszyć ładowanie witryny?

Warto wiedzieć, że szybkość ładowania witryny ma kluczowe znaczenie dla jej sukcesu. Na przykład dla firmy, daje ona pierwsze wrażenie odwiedzającym. Co więcej, jeśli ładowanie witryny trwa zbyt długo , może to mieć wpływ na jej ranking w głównych wyszukiwarkach i nie zapewni wystarczającej ekspozycji, aby utrzymać witrynę przy życiu.

Nie ma limitu czasu ładowania stron internetowych. Jednak większość witryn ładuje się w czasie krótszym niż trzy sekundy.

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

Narzędzie Fastest Cache to system zaprojektowany i opracowany przez LWS w celuoptymalizacji wydajności ładowania strony internetowej poprzez wykorzystanie mechanizmów buforowania stron skonfigurowanych na poziomie serwera WWW. Narzędzie łączy w sobie technologie dostarczane przez NGINX i Varnish.

NGINX to zorientowany na wydajność serwer WWW, który może obsłużyć znacznie więcej żądań niż Apache (zobacz nasz wpis na blogu zatytułowany"Apache VS Nginx: Test wydajności"). Jest on używany głównie w Fastest Cache do zarządzania bezpiecznym dostępem do witryny pod adresem https://, eliminowania złośliwych żądań HTTP (patrz LWS Protect) i kierowania żądań HTTP do serwerów pamięci podręcznej Varnish.

Varnish to usługa HTTP, która implementuje mechanizm buforowania stron w celu buforowania wyniku żądania HTTP w pamięci.

Przy odpowiednich konfiguracjach NGINX może obsłużyć więcej żądań do Twojej witryny, a Varnish może przyspieszyć czas ładowania strony, jednocześnie zmniejszając zużycie procesora i pamięci.

Jak działa usługa Fastest Cache?

1. Działanie bez pamięci podręcznej

Aby lepiej zrozumieć, jak to działa, zaczniemy od przyjrzenia się, jak to działa bez wtyczki pamięci podręcznej, aby odwiedzający mogli zobaczyć Twoją witrynę.

1. Odwiedzający żąda strony z serwera WWW. Przykład: index.php

2. Serwer WWW wykonuje niezbędne skrypty (PHP, Perl, NodeJS itp.).

3. Serwer WWW otrzymuje wynik wykonania skryptu

4. Serwer WWW wysyła stronę HTML będącą wynikiem wykonania skryptu.

2. Działanie z modułem Fastest Cache

Gdy włączony jest moduł Fastest Cache, między odwiedzającym a serwerem WWW umieszczany jest serwer pamięci podręcznej.

Celem jest zmniejszenie liczby wymaganych wykonań skryptu poprzez przechowywanie wyniku wykonania w pamięci dla przyszłych żądań wymagających tej samej odpowiedzi. Eliminuje to konieczność wielokrotnego uruchamiania tego samego skryptu w celu osiągnięcia tego samego rezultatu.

Eliminuje to czas oczekiwania na wykonanie skryptu podczas ładowania strony, a jednocześnie oszczędza zasoby wykorzystywane podczas wykonywania skryptu.

1. Odwiedzający żąda strony z serwera WWW. Przykład: index.php
2. Fastest Cache sprawdza, czy strona została już wygenerowana i zapisana w pamięci podręcznej.

• Jeśli tak, strona jest zwracana bezpośrednio do odwiedzającego bez potrzeby uzyskiwania dostępu do usługi sieciowej i bez wykonywania skryptu.
• Jeśli nie, strona jest żądana do wygenerowania w usłudze internetowej, co powoduje wykonanie skryptu (PHP, NodeJS, Perl, Ruby itp.).

3. Po wygenerowaniu strony Fastest Cache określa, czy strona może być buforowana (poprzez nagłówki, adres URL itp.).

• Jeśli tak, strona jest zapisywana w pamięci podręcznej i wysyłana z powrotem do odwiedzającego
• Jeśli nie, strona jest zapisywana w pamięci microcache (pamięć podręczna o krótkim okresie ważności) i wysyłana z powrotem do odwiedzającego.

Widzimy, że gdy strona jest przechowywana w pamięci podręcznej, unika się przetwarzania przez serwer WWW i wykonywania skryptów.

Cacheable, non-cacheable i microcache

Gdy usługa sieciowa dostarcza nową odpowiedź do Fastest Cache, jest ona analizowana w celu określenia, czy powinna być przechowywana w pamięci podręcznej do wykorzystania w przyszłości.

Niektóre treści stron nie powinny być buforowane, takie jak wynik formularza rejestracyjnego, wynik strony płatności itp., ponieważ zawierają one dane, które różnią się w zależności od użytkowników i zdarzeń.

Aby określić, czy strona może być buforowana, czy nie, Fastest Cache wykorzystuje kilka mechanizmów:

• Żądania HTTP używające czasowników HTTP innych niż HEAD i GET będą systematycznie wyklucz ane z pamięci podręcznej.
• Żądania HTTP zawierające pliki cookie również zostaną wykluczone. Pliki cookie używane przez Google Analytics, XiTi, DoubleClick, Quant Capital, AddThis i Cloudflare są usuwane przed wykryciem. Podobnie, pliki cookie powiązane ze znanymi CMS są zarządzane automatycznie, jeśli tryb buforowania odpowiada CMS.
• Żądania HTTP chronione hasłami .htaccess
• Jeśli odpowiedź serwera WWW zawiera instrukcje dotyczące pamięci podręcznej przeglądarki (nagłówek cache-control), zostanie to automatycznie uwzględnione przez Fastest Cache i strona będzie przechowywana w pamięci podręcznej.

Jeśli żądanie HTTP jest typu GET i nie jest chronione przez .htaccess ani nie zawiera plików cookie i nie ma określonych instrukcji pamięci podręcznej przeglądarki, jest przechowywane w pamięci podręcznej przez kilka sekund.

Pamięć podręczna może być zatem wykorzystywana do przezwyciężenia obaw związanych ze szczytowym zapotrzebowaniem na strony, które nie są przechowywane w pamięci podręcznej. Rozwiązuje to na przykład problem przeciążenia i spowolnienia w przypadku fali wyszukiwań tego samego produktu w sklepie internetowym.

Prezentacja interfejsu i aktywacja usługi

Fastest Cache pojawia się jako ikona w cPanelu w sekcji "Wydajność".

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

• Kolumna"Status pamięci podręcznej" pokazuje status aktywacji pamięci podręcznej. Jeśli jest on ustawiony na"Enabled", pamięć podręczna jest aktywna.
• Przycisk "Wyczyść pamięćpodręczną" usuwa wszystkie dane z pamięci podręcznej dla tej konkretnej nazwy domeny.
• Przycisk"Deactivate cache" służy do dezaktywacji buforowania.
• Przycisk"Włącz pamięć podręczną" włącza pamięć podręczną.
• Przycisk"Zmień tryb pracy" służy do zmiany zachowania systemu buforowania. Tryby te zostaną wyjaśnione wkrótce.

Różne tryby pamięci podręcznej

Domyślnie system pamięci podręcznej wybiera tryb "Użycie ogólne ", który jest odpowiedni do ogólnego użytku. Istnieją jednak inne tryby:

Tryb dewelopera: identyczny z dezaktywacją pamięci podręcznej, pozwala zastąpić system pamięci podręcznej w okresach programowania.
WordPress: tryb buforowania lepiej dostosowany do WordPressa, z ulepszonym zarządzaniem folderami (wp-content, wp-admin itp.) i plikami cookie specyficznymi dla WordPressa.
Prestashop : tryb pamięci podręcznej lepiej dostosowany do Prestashop, z ulepszonym zarządzaniem folderami i plikami cookie.

Czyszczenie pamięci podręcznej

Oprócz interfejsu cPanel do czyszczenia pamięci podręcznej, możliwe jest ręczne czyszczenie pamięci podręcznej z terminala SSH konta cPanel lub ze skryptu hostowanego na serwerze.

1. Czyszczenie pamięci podręcznej za pomocą cURL

Czyszczenie pamięci podręcznej strony :

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

Spowoduje to wyczyszczenie pamięci podręcznej adresu URL http://mon-site-web.com/mapage.php.

Czyszczenie pamięci podręcznej folderu :

curl -X 'PURGE -H 'X-Purge-Method:regex' 'http://mon-site-web.com/wp-content/uploads/.*'

Spowoduje to wyczyszczenie wszystkich pamięci podręcznych adresów URL zaczynających się od "http://mon-site-web.com/wp-content/uploads/".

Czyszczenie pamięci podręcznej witryny

curl -X 'FULLPURGE' http://mon-site-web.com

Dla wszystkich trzech poleceń możliwe są dwa zwroty:

Kod HTTP 200: czyszczenie powiodło się, bez błędów.

Kod HTTP 405: czyszczenie nie jest autoryzowane lub nie miało miejsca.

2. Czyszczenie za pomocą wtyczki lub modułu

Większość wtyczek/modułów z integracją Varnish jest kompatybilna z wewnętrznym mechanizmem oczyszczania Fastest Cache.

Oto kilka wtyczek, które zostały przetestowane i zweryfikowane jako kompatybilne:

• WP Rocket: https: //wp-rocket.me
• Proxy Cache Purge: https: //wordpress.org/plugins/varnish-http-purge/

Wykrywanie HTTPS i przekierowania

Status HTTPS i porty wskazane w Apache są modyfikowane przez moduł mod_fastestcache wbudowany w Apache. W związku z tym zasadniczo nie jest konieczne wprowadzanie żadnych zmian.

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

Zaufane nagłówki HTTP do wykrywania to :

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

Tak więc, 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 nie działa, można zastąpić zmienną SERVER_PORT zmienną 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 sieci CDN

Sieci CDN CloudFlare mają filtry żądań HTTP, które mogą blokować żądania "PURGE" i "FULLPURGE" używane przez Fastest Cache do czyszczenia pamięci podręcznej.

Zalecamy korzystanie tylko z jednego poziomu pamięci podręcznej, Cloudflare lub Fastest Cache.

Używanie obu razem może prowadzić do niepożądanego zachowania. Przetestuj oba i użyj tego, który najlepiej odpowiada Twoim potrzebom.