Kontynuując ostatnie wpisy dotyczące optymalizacji WordPressa pod kątem szybkości wczytywania strony opartej o ten CMS, postanowiłem poświęcić jeden cały wpis wtyczce W3 Total Cache. Większość użytkowników myśli, że wystarczy zainstalować wtyczkę zapomnieć. Jak się za chwilę przekonacie, drobna różnica w standardowej konfiguracji, może przynieść wielkie rezultaty w postaci lepszego wyniku parametru PageSpeed, czyli wzrostu prędkości wczytywania strony, co za tym idzie lepszej optymalizacji pod kątem SEO i pozytywnych wrażeń użytkowników podczas przeglądania naszego serwisu.
W3 Total Cache, nie tylko do cache-owania
Wtyczka W3 Total Cache jak mało która potrafi bardzo dużo, a cały potencjał można wycisnąć dopiero po jej odpowiednim skonfigurowaniu. Wtyczkę polubiłem tak na prawdę od drugiego wrażenia – najpierw ją miałem, ale nie za bardzo zagłębiałem się w jej konfigurację. Gdy okazało się że mój PageSpeed jest bardzo niski uznałem, że wtyczka sobie nie radzi i zacząłem testować inne. Efekt był taki, że miałem wiele wtyczek, nie do końca skonfigurowanych, nie do końca działających, no i dalej nie do końca rozwiązujących mój problem. Postanowiłem wrócić do W3 Total Cache, i poświęcić trochę czasu na konfigurację wtyczki…
W niniejszym artykule skupiam się na darmowej wersji wtyczki W3 Total Cache, oraz na podstawowych ustawieniach (Page Cache | Minify | Database Cache | Browser Cache), które pozwolą na podniesienie SpeedRank-u w Google Insights do przyzwoitego poziomu ~90 punktów.
Sprawdzenie kompatybilności
Pierwszy krok na drodze do zoptymalizowania strony przy użyciu tej wtyczki to Compatibility Test, czyli sprawdzenie kompatybilności wtyczki z serwerem, na którym znajduje się nasza strona.
Aby wywołać test należy przejść do Performance → Dashboard, i na górze wcisnąć guzik Compatibility Test. W nowo-otwartym oknie pod legendą możemy sprawdzić jakie moduły serwera są potrzebne i które obsługuje nasz serwer. U mnie wygląda to następująco:
Server Modules & Resources:
- Plugin Version:
0.9.3 - PHP Version:
5.3.24; - Web Server:
Apache - FTP functions:
Installed(required for Self-hosted (FTP) CDN support) - Multibyte String support:
Installed(required for Rackspace Cloud Files support) - cURL extension:
Installed(required for Amazon S3, Amazon CloudFront, Rackspace CloudFiles support) - zlib extension:
Installed(required for compression support) - Opcode cache:
Not installed - Memcache extension:
Not installed - HTML Tidy extension:
Installed(required for HTML Tidy minifier suppport) - Mime type detection:
Installed (Fileinfo)(required for CDN support) - Hash function:
Installed (hash)(required for NetDNA / MaxCDN CDN purge support) - Safe mode:
Off - Open basedir:
Off - zlib output compression:
Off - set_time_limit:
Available - mod_deflate:
Not detected(required for disk enhanced Page Cache and Browser Cache) - mod_env:
Not detected(required for disk enhanced Page Cache and Browser Cache) - mod_expires:
Not detected(required for disk enhanced Page Cache and Browser Cache) - mod_headers:
Not detected(required for disk enhanced Page Cache and Browser Cache) - mod_mime:
Not detected(required for disk enhanced Page Cache and Browser Cache) - mod_rewrite:
Not detected(required for disk enhanced Page Cache and Browser Cache) - mod_setenvif:
Not detected(required for disk enhanced Page Cache and Browser Cache)
Najważniejsze to zwrócenie uwagi na pozycje, które nie są zainstalowane, bo przy konfiguracji wtyczki nie będziemy mogli skorzystać z opcji wymagających niektórych modułów zainstalowanych na serwerze.
Teraz zamknij okno z testem. Druga przydatna tutaj rzecz, to guziki znajdujące się obok przycisku wywołującego test:
- empty all cache – pamiętaj, aby po każdej zmianie ustawień wtyczki, aby sprawdzić różnicę w testach mierzących wydajność witryny, wyczyścić całą pamięć podręczną
- guziki czyszczące poszczególne rodzaje cache, które będą aktywne w zależności od tego jakie rodzaje cache mamy „uruchomione”
Dostęp do tych opcji jest możliwy również z poziomego, górnego toolbara WordPress – bardzo wygodne przy testowaniu różnych ustawień.
Ustawienia ogólne
W ustawieniach ogólnych (General Settings) znajdziemy 14 sekcji, z poziomu których możemy włączać lub wyłączać poszczególne moduły optymalizujące. Poniżej znajduje się opis najważniejszych, tych na które powinieneś zwrócić uwagę w pierwszej kolejności. Zaczynajmy!
Browser Cache
Po zainstalowaniu pluginu tylko moduł Browser Cache jest aktywny. Browser cache, to pamięć podręczna przeglądarki internetowej. Ten rodzaj cache pomaga przyspieszyć działanie witryny po stronie klienta. Działanie polega na ustawieniu odpowiednich reguł określających typy plików w .htaccess, które powinny być zapisywane w pamięci podręcznej przeglądarki. Zapisanie tych stałych elementów strony po stronie klienta, w pamięci podręcznej przeglądarki sprawia, że witryna pomiędzy przeładowywaniami ładuje jest szybciej, bo część zasobów znajduje się już po stronie klienta.
W zakładce Performance → Browser Cache znajdziemy wiele opcji określających zachowanie plików znajdujących się w pamięci podręcznej. Jeżeli w PageSpeed Insights mamy problemy w sekcji Leverage Browser Caching, to już tutaj znajdziemy przynajmniej część rozwiązań.
W każdej z 4 dostępnych w zakładce sekcji na pewno musimy zaznaczyć opcje:
- Set Last-Modified header – ustawia nagłówek z informacją o ostatniej modyfikacji pliku
- Set expires header – usuwa błędy mówiące o tym, że pliki w pamięci podręcznej nie mają zaznaczonego czasu przedawnienia (expiration not specified)
- Enable HTTP (gzip) compression – usuwa część błędów związanych z sekcją Minify Resources.
Po włączeniu opcji Set Expires header, może okazać się, że problem został rozwiązany połowicznie. PageSpeed Insights często pokazuje błędy mówiące o tym, że czas przechowywania plików w pamięci podręcznej jest za krótki dlatego w większości przypadków należy zwiększyć wartość w Expires header lifetime – rekomendacja Insights, to o ile dobrze pamiętam, jest 60*60*24*7 sekund, czyli dokładnie tydzień, ale w zależności od tego jak popularny jest nasz blog i jak często pojawia się na nim coś nowego trzeba tą wartość dostosować do strony.
Pozostałe opcje należy ustawić według indywidualnych potrzeb .
Page Cache
Inaczej pamięć podręczna dysku twardego – przyspiesza dostęp do wolnej pamięci masowej. Dzięki tej opcji możemy uzyskać najlepsze efekty w poprawianiu prędkości działania strony – dzięki włączeniu tej opcji możemy liczyć nawet na dziesięciokrotny wzrost wydajności!
Na czym polega cache-wanie stron? W skrócie i uproszczeniu mówiąc… gdy strona jest renderowana przez interpreter PHP, do przeglądarki wysyłany jest kod HTML. Plugin cache-ujący zapisuje w pamięci wynik działania skryptu PHP w postaci przetworzonego, gotowego do wyświetlenia użytkownikom, czystego kodu HTML. Dzięki takiej operacji następny użytkownik nie musi już czekać na ponowne wygenerowanie strony przez interpreter PHP, a dostaje gotowy wynik z zapisanego wcześniej pliku HTML.
Aby włączyć moduł, należy zaznaczyć okienko obok napisu Enable, a następnie z poniższej listy wybrać sposób cachowania – w zależności od rodzaju i konfiguracji serwera, mamy więcej lub mniej dostępnych opcji. Ja posiadam serwer współdzielony więc mogę wybrać pomiędzy Disk i Disk Enhanced. Druga opcja jest rekomendowana. Zapisujemy zmiany i przechodzimy do kolejnej strony konfiguracyjnej Performance → Page Cache.
Tutaj trzeba chwilę pomyśleć aby dostosować ustawienia do strony. Generalnie domyślne ustawienia raczej wystarczają.
Minify
Minify, to pozbywanie się białych znaków takich jak spacje, „entery” i tabulatory z kodu HTML, CSS i JavaScript. Usunięcie ich z kodu sprawia, że kod traci na swojej czytelności ale „waży” znacznie mniej. Moduł Minify w W3 Total Cache, pozwala także na łączenie wszystkich dołączanych do dokumentu HTML, skryptów JS i arkuszy z kodem CSS w pojedyncze pliki.
Tutaj sprawę można rozwiązać dwojako, albo możemy sami zdecydować jakie skrypty łączyć jak i gdzie „includować” je do szablonu, albo postawić na automatyczne działanie.
Uwaga, opcja wpływa na kolejność wczytywania skryptów na stronie, toteż istnieje pewne ryzyko, że po nierozważnej konfiguracji, na stronie mogą pojawić się pewne problemy, jak niedziałające pewne funkcjonalności, związane z niedziałającymi skrypty JavaScript na stronie.
Teraz wyjaśnię przykładową konfigurację. Wróć na chwilę do głównej zakładki pluginu Performance → Dashboard, i skocz do sekcji Minify. Włącz moduł, Minify mode ustaw na Auto, a resztę zostaw na domyślnych.
Następnie w zakładce Performance → Minify:
- General – zostaw domyślne ustawienia
- HTML & XML – zaznacz te opcje:
- Enable – włącza moduł minify dla kodu HTML i XML
- Inline CSS minification – usuwa białe znaki z kodu CSS osadzonego bezpośrednio w kodzie HTML
- Inline JS minification – jw. dla JS
- Line break removal – usuwa „entery”
- JS – uruchom moduł i sprawdź zachowanie strony. Jeżeli ustawienie minify sprawia problemy i teraz nie działa JavaScript na stronie, to przełącz opcję na Combine only, która sprawi, że ze skryptów JavaScript nie będą usuwane białe znaki, działanie js na stronie powinno wrócić do normy, a skrypty będą jedynie łączone w jeden plik. Dzięki temu w Insights przynajmniej zmniejszy się ilość błędów mówiących o skryptach blokujących renderowanie strony. W tym samym miejscu znajduje się lista wyboru Embed type, w której możemy określić rodzaj dołączania skryptów JS do strony. W Insights polecane rozwiązanie to asynchroniczne wczytywanie skryptów – dlatego powinieneś w pierwszej kolejności sprawdzić opcję non-blocking using 'async’. Jeżeli wystąpiły jakieś problemy na blogu spróbuj także non-blocking using JS. Przy takich ustawieniach w PageSpeed Insights powinny zniknąć wszystkie błędy mówiące o skryptach blokujących renderowanie strony (przynajmniej te dotyczące skryptów JS).
- CSS – uruchamiamy moduł i sprawdzamy czy na blogu wszystko wygląda poprawnie pod kątem CSS. Jeżeli jest ok zostawiamy, jeżeli wystąpiły jakieś problemy zaznaczamy dodatkowo opcję Combine only, czyli nie chcemy usuwać białych znaków z CSS, a jedynie połączyć je w jeden plik. Po ponownej analizie strony w PageSpeed Insights z sekcji Wyeliminuj blokujący renderowanie kod JavaScript i CSS z części strony widocznej na ekranie powinno zniknąć większość błędów.
I to dzisiaj wszystko, mam nadzieję że artykuł się spodobał i zachęciłem przynajmniej część z Was do przetestowania W3 Total Cache w nieco szerszej perspektywie.
