17 stycznia 2018 roku Google zapowiedziało tzw. Speed Update, który wejść w życie ma w lipcu 2018. Nowy algorytm obejmie mobilną wyszukiwarkę. Zgodnie z oświadczeniem po wprowadzeniu aktualizacji w wynikach organicznych dla urządzeń mobilnych gorsze pozycje może odnotować grupa najwolniejszych i najgorzej zoptymalizowanych witryn. Webmasterzy mają zatem czas do wakacji, aby poprawić page speed swoich serwisów. Jednym z podstawowych i najprostszych sposobów na poprawę wydajności jest skorzystanie z optymalizacji, które można wprowadzić do pliku .HTACCESS.
Optymalizacje w .HTACCESS
Poniższe optymalizacje wprowadzać można bezpośrednio do pliku .htaccess. Jest to plik znajdujący się zazwyczaj na serwerze w katalogu głównym witryny. Istotne, aby sprawdzić, czy wspomnianych modułów automatycznie nie wprowadza CMS lub inna aplikacja. Przykładowo WordPress posiada wtyczkę, która sama wdraża do kodu Cache-Control headers. Należy unikać sytuacji, gdy CMS generuje te moduły samodzielne i wprowadzenie ich ręcznie do .htaccess spowoduje ich duplikację.
Cache-control headers i Expire headers – wykorzystanie pamięci podręcznej
Wprowadzenie Cache-Control headers lub Expire headers jest jedną z odpowiedzi na sugerowane przez PageSpeed optymalizacje dotyczące wykorzystania pamięci podręcznej przeglądarki.
Cache-control vs Expire – zastosowanie i różnice
Podstawową kwestią jest czas ich powstania – Expire Headers zostały wprowadzone w HTTP 1.0, a Cache-Control Headers w HTTP 1.1. W związku z powyższym wystarczające jest zastosowanie samych Cache-Control; oferują one więcej możliwości. W wypadku gdy strona korzysta z obu rozwiązań i podają one sprzeczne wartości, przeglądarki i serwery dadzą pierwszeństwo zasadom opisanym w sekcji Cache-Control. Czy zatem jest powód, aby korzystać z Expire Headers równocześnie z Cache-Control?
Możemy założyć, że nie wszystkie przeglądarki i serwery potrafią prawidłowo parsować Cache-Control, dlatego wtedy jako alternatywę do dyspozycji pozostawiamy Expire Headers. Jest to jednakże rozwiązanie opcjonalne i równie dobrze może zawierać zasady korzystania z pamięci podręcznej tylko dla najważniejszych zasobów. O optymalizacji za pomocą Cache-Control przeczytać można także w przewodniku dla deweloperów Google w dziale Buforowanie HTTP.
Cache-control w praktyce
Poniżej przykładowy kod sekcji Cache-Control w .HTACCESS
#początek modułu
<IfModule mod_headers.c>
#rok ważności dla grafik, zasób publiczny
<FilesMatch „.(jpg|jpeg|png|gif|ico)$”>
Header set Cache-Control „max-age=31536000, public”
</FilesMatch>
#miesiąc ważności dla SWF, zasób publiczny
<FilesMatch „.(swf)$”>
Header set Cache-Control „max-age=2628000, public”
</FilesMatch>
#miesiąc ważności dla CSS i JS, zasób prywatny
<FilesMatch „.(css|js)$”>
Header set Cache-Control „max-age=2628000, private”
</FilesMatch>
#opcjonalnie można uwzględnić także inne zasoby
<FilesMatch „.(x?html?|php)$”>
Header set Cache-Control „max-age=2628000, private”
</FilesMatch>
</IfModule>
#zakończenie modułu
FilesMatch – określa, jakich zasobów ma dotyczyć zasada wykorzystania pamięci podręcznej.
Max-age – określa w sekundach, jak długo wybrane zasoby mają być pobierane z pamięci podręcznej:
- Minuta – max-age=60
- Godzina – max-age=3600
- Dzień – max-age=86400
- Tydzień – max-age=604800
- Miesiąc – max-age=2628000
- Rok – max-age=31536000
Dopasowanie okresu wykorzystania pamięci podręcznej do zasobów jest zależne od natury witryny. Webmaster musi określić, jak często dane zasoby są zmieniane i dopasować odpowiednie okresy. Zazwyczaj zasobami, które nie zmieniają się często, to JS (Javascripts) i obrazki. Jeśli nie ma planów na zmiany tych zasobów, można ustawić ich ważność na miesiąc lub nawet rok. Natomiast CSS można bezpiecznie ustawić na tydzień lub miesiąc, gdyż może okazać się, że wprowadzenie nowej zawartości wymaga w nim zmian.
Rozwiązaniem na zasoby o długim okresie ważności, których zawartość jednak musi się zmienić, jest podmiana nazwy pliku. Np. zmiana nazwy nowej grafiki logo.jpg na logo-2.jpg spowoduje, że mimo np. rocznego okresu ważności wszyscy użytkownicy zobaczą nową wersję obrazka bez ingerowania w ogólne zasady Cache-Control.
Private lub Public – ten atrybut określa, czy dany zasób może być zapisywany w pamięci podręcznej wszędzie, czy tylko indywidualnie przez konkretne urządzenie. Większość zasobów można określić jako public, a wyjątkiem będą przede wszystkim zasoby CSS i JS, jako że najczęściej wiążą się np. z indywidualnymi ustawieniami użytkownika na danej witrynie (user specific content) lub wprowadzaniem prywatnych danych do formularzy. Dla bezpieczeństwa zasoby CSS i JS zazwyczaj oznaczamy jako Private. Co więcej, tylko w tym wypadku PageSpeed Insights uzna je za zoptymalizowane. Oczywiście dopasowanie zasobów do Private i Public również jest indywidualne dla każdej witryny i to webmaster powinien podjąć decyzję, jaki podział w danym wypadku będzie najlepszy.
Expire headers w praktyce
Poniżej przykładowy kod sekcji Expire headers w .HTACCESS:
#rozpoczęcie modułu
<IfModule mod_expiers.c>
ExpiresActive on
#zasada ogólna ważności zasobów – używając tej zasady, bardzo ważne jest, żeby w dalszej części modułu uwzględnić WSZYSTKIE zasoby, które mają mieć inny okres ważności. Dlatego zasada ta powinna być używana z wyjątkową ostrożnością
ExpiresDefault „access plus 1 day”
#bezpiecznym ustawieniem jest też
ExpiresDefault „access plus 0 seconds”
#grafiki, wideo, audio dla wybranych formatów
ExpiresByType image/gif „access plus 1 year”
ExpiresByType image/png „access plus 1 year”
ExpiresByType image/jpg „access plus 1 year”
ExpiresByType image/jpeg „access plus 1 year”
ExpiresByType image/x-icon „access plus 1 year”
ExpiresByType video/mp4 „access plus 1 month”
ExpiresByType audio/mp3 „access plus 1 month”
#CSS i JS
ExpiresByType application/javascript „access plus 1 year”
ExpiresByType text/javascript „access plus 1 year”
ExpiresByType text/css „access plus 1 year”
#inne
ExpiresByType text/xml „access plus 1 day”
ExpiresByType text/html „access plus 1 day”
ExpiresByType application/xhtml+xml „access plus 1 day”
</IfModule>
#zakończenie modułu
W kwestii dopasowania zasobów i czasu ich przechowywania obowiązują te same zasady co w wypadku Cache-Control. Wartości te powinny być indywidualnie dopasowane do specyfiki witryny.
Rezultaty wykorzystywania pamięci podręcznej
Rezultaty wprowadzenia Cache-Control są indywidualne dla każdej witryny. Jeśli już wcześniej była dobrze zoptymalizowana, wykorzystanie pamięci podręcznej podniesie wynik optymalizacji o 1-3 pkt, natomiast jeśli optymalizacja była słaba i cache w żaden sposób nie był wykorzystywany, wdrożenie potrafi podnieść wynik nawet o 15-20 punktów jednocześnie wpływając pozytywnie na szybkość działania strony dla powracających użytkowników.
Kompresja GZIP
Kompresja GZIP potrafi znacznie zmniejszyć ilość pobieranych danych. Serwer wysyła do przeglądarki skompresowane pliki, które rozpakowywane są lokalnie. Czy strona korzysta z kompresowania GZIP, można sprawdzić na jednej z darmowych sprawdzarek np. https://checkgzipcompression.com/.
