Gdy otworzymy przeglądarkę i uruchomimy w niej naszą witrynę to musi ona załadować ogromne ilości elementów zanim przed naszymi oczyma ukaże się strona w pełnej okazałości. W większości stron mamy przecież logo, pliki CSS czy JavaScript jak i masę innych grafik, dodatków etc.
Wykorzystując pamięć podręczną przeglądarki (tzw. cache) sprawiamy, że w momencie gdy użytkownik wejdzie na naszą stronę i załaduje wszystkie, potrzebne do jej wyświetlenia elementy to przechodząc na inną podstronę nie będzie już musiał tego robić ponownie, chodzi przede wszystkim o CSS’y i zdjęcia (jak logo), które powtarzają się na każdej podstronie bądź te, które zostały już raz załadowane. Oczywiście nie użytkownik je „ładuje”, a przeglądarka, ale dzięki temu odwiedzający każdą kolejną podstronę dostaje znacznie szybciej niż poprzednie.
[showmyads]
Jeśli więc testowaliście Wasze strony pod kątem prędkości ładowania i otrzymaliście sugestie mówiącą o wykorzystaniu pamięci podręcznej przeglądarki to poniżej znajdziecie sposoby na wdrożenie takowych zmian.
Jak wykorzystywać pamięć podręczną przeglądarki?
W większości przypadków wystarczy dodać odrobinę kody do pliku na serwerze, który nazywa się .httaccess. Użytkownicy WordPressa po zainstalowaniu wtyczki Yoast WordPress SEO mają sprawę ułatwioną, gdyż z poziomu panelu administracyjnego mogą edytować wspomniany plik. Cała reszta musi zalogować się przez ssh bądź ftp i samodzielnie go wyedytować.
Plik .htaccess pełni rolę kontrolą, pozwala nam zarządzać wieloma rzeczami związanymi z naszą witryną i wbrew pozorom nie służy tworzeniu „jedynie” przekierowań.
[sociallocker]
Teraz wystarczy wkleić do pliku .htaccess (dla serwerów na Apache) poniższy kod, zróbcie to na końcu, ale nie pozostawiajcie żadnych białych znaków tuż po nim, zero spacji czy enterów.
## EXPIRES CACHING ## <IfModule mod_expires.c> ExpiresActive On ExpiresByType image/jpg "access 1 year" ExpiresByType image/jpeg "access 1 year" ExpiresByType image/gif "access 1 year" ExpiresByType image/png "access 1 year" ExpiresByType text/css "access 1 month" ExpiresByType text/html "access 1 month" ExpiresByType application/pdf "access 1 month" ExpiresByType text/x-javascript "access 1 month" ExpiresByType application/x-shockwave-flash "access 1 month" ExpiresByType image/x-icon "access 1 year" ExpiresDefault "access 1 month" </IfModule>
Zapisujemy edytowany plik i przechodzimy do naszej strony. Używając kombinacji CTRL+F5 odświeżamy witrynę i sprawdzamy uzyskane rezultaty.
[/sociallocker]
Jeśli powyższy kod nie odniósł pożądanego efektu to warto spróbować dokleić kod, który znajduje się poniżej:
<filesMatch ".(ico|pdf|flv|jpg|svg|jpeg|png|gif|js|css|swf)$"> Header set Cache-Control "max-age=846000, public" </filesMatch>
Wartość max-age to liczba sekund, więc możecie to modyfikować jak tylko to się wam podoba.
Dla serwerów na Nginx:
location ~* \.(js|css|png|jpg|svg|jpeg|gif|ico)$ {
expires 2d;
add_header Cache-Control "public, no-transform";
}
Powyższe regułki zadziałają jedynie na pliki znajdujące się fizycznie na serwerze, wszelkie zewnętrzne zasoby nie zostaną objęte.
Ale o co chodzi z tymi datami?
W kodzie widzicie zapiski takie jak „1 year” czy „1 month” przy konkretnych rozszerzeniach plików. Oznacza to, że przykładowo pliki .jpg powinny być pamiętane przez przeglądarkę przez jeden rok od czasu pierwszej odsłony. Wszystko się zmienia jeśli ręcznie wyczyścimy cache przeglądarki, wtedy po ponownym wejściu na witrynę przeglądarka zapisze je w swojej pamięci na nowo.
[showmyads]
Oczywiście daty „trwałości” – tak sobie je nazwę – możecie zmieniać dowolnie i „1 year” śmiało możecie zastąpić „1 month” i odwrotnie.
Czy nie będzie żadnych problemów?
Oczywiście, że będą, ale zmiany te wpłyną w większości wypadków na plus aniżeli na minus. Pamiętajmy że gdy ustawimy pliki html bądź zdjęcia z okresem „trwałości” jednego roku to jeśli przed jego upłynięciem naniesiemy na witrynę jakieś zmiany to mogą one nie być widoczne dla wszystkich użytkowników, zwłaszcza dla tych, którzy przykładowo dzień wcześniej odwiedzili daną podstronę.
Przy częstych zmianach w stylach na stronie możemy skorzystać z pewnego triku, który pozwoli zaprezentować każdą zmianę powracającym użytkownikom bez potrzeby czyszczenia cachu przeglądarki po ich stronie. Zamiast tworzyć plik style.css warto nazwać go style_1.css i po kolejnych zmianach zmienić mu nazwę na style_2.css. I tak dalej…
Na koniec pamiętajmy, aby używać nagłówków Expires LUB Cache-Control: max-age. Tak samo używamy nagłówka ETag albo Last-Modified. W obu przypadkach nie korzystajcie z dwóch metod jednocześnie, gdyż to nie ma najmniejszego sensu.
U mnie ten wpis nic nie zmienia.
Bo nie zrobiłeś tego pewnie tak jak trzeba, widać że nie działa cachowanie, więc coś sknociłeś przy wklejaniu do htacces
Nie sknociłem, po prostu testuje różne wtyczki. Włączam, wyłączam i ustawiam chyba od 2 godzin.
Z tym że głównie walczę o optymalizację na komórki.
A na co Ci tutaj wtyczki, wklejasz kod do htacces i po sprawie 😉
Testuje nie tylko szybkość. Nna zachodnich guglach znalazłem, że ten kod trzeba go wkleić na początku htaccess no i mam 2 punkty w górę. Ale to tyle co nic.
Jeśli strona stoi na WordPressie można skorzystać z wtyczki w3 total cache. Mnóstwo opcji cachowania. Do tego środowisko testowe, gdzie każdą opcję możemy bezpiecznie przetestować na naszej stronie przed wprowadzeniem danych zmian.
Wziąłeś pod uwagę jak duże obciążenie generuje wspomniana przez Ciebie wtyczka? Dodatkowo jej implementacja na wielu stronach kończy się niepowodzeniem, zwłaszcza jeśli użytkownik nie wie dokładnie co robi i po co zaznacza kolejne opcje.
A mi pomogło wg danych z google’owego PageSpeed Insights + 8 punktów. To chyba nie jest zły wynik? Kwestia dostosowania długości czasu ważności – zobaczymy w praktyce. Dziękuję tak czy siak. 🙂
U mnie wklejenie pierwszej części kodu pogorszyło wyniki. Natomiast doklejenie drugiej części polepszyło.
Bardzo rzeczowo, dzięki za informacje
Dla serwerów Apache ten kod w .htaccess dobrze działa. A powiedz mi, co sądzisz o cachowaniu w sklepach internetowych?
Nie widzę problemu, cachowanie można zastosować wszędzie, ale trzeba to robić z głową.
Czyli dodając regułkę:
#Expire headers START
ExpiresActive On
ExpiresDefault „access plus 1 month”
ExpiresByType image/jpg „access plus 1 month”
ExpiresByType image/jpeg „access plus 1 month”
ExpiresByType image/png „access plus 1 month”
ExpiresByType image/gif „access plus 1 month”
AddType image/x-icon .ico
ExpiresByType image/ico „access plus 1 month”
ExpiresByType image/icon „access plus 1 month”
ExpiresByType image/x-icon „access plus 1 month”
ExpiresByType text/css „access plus 1 month”
ExpiresByType text/javascript „access plus 1 month”
ExpiresByType text/html „access plus 1 month”
ExpiresByType application/xhtml+xml „access plus 1 month”
ExpiresByType application/javascript „access plus 1 month”
ExpiresByType application/x-javascript „access plus 1 month”
ExpiresByType application/x-shockwave-flash „access plus 1 month”
#Expire headers STOP
Przyspieszymy nieco sklep?
Wszystko zależy od serwera, czy to Apache czy nginx
Moim zdaniem pamięć podręczna przeglądarki, to dobre rozwiązanie dla stron wizytówek. Jeśli często zmieniają się treści strony, odbiorca będzie miał dostęp do nieaktualnych danych.
Pamięć działa na zdjęcia, skrypty etc. a nie na treści. Jedno nie ma nic wspólnego z drugim, proszę zapoznać się najpierw z działaniem tego rodzaju cache.
Ustawiłem sobie coś takiego u siebie na stronie, faktycznie przeglądarka zaczęła pamiętać obrazki. Bo jak zmieniłem to nadal wyświetlał się dawniejszy. To bardzo dobre że nie ma ponownego wczytywania szybciej niż w określonym czasie. Szybkość strony nie wzrosła ale obciążenie wydaje się że może zmaleć.