Google PageSpeed Insights to świetny sposób, aby uzyskać szybki przegląd potencjału optymalizacji witryny. Dzisiaj pokażę Ci jak wykorzystać ten potencjał i zwiększyć wynik PageSpeed. Nie powinieneś jednak niewolniczo podążać za wynikami Google. Ponieważ komunikaty o błędach PageSpeed nie zawsze są użyteczne.

Jakiś czas temu kolega Caspar Hübinger, w jednym ze swoich wpisów na blogu, napisał, powiedzmy, bardzo jasne słowa na temat swojego wyniku Google PageSpeed Insights. Krytykuje nie tylko samo narzędzie, ale także jego wykorzystanie przez użytkowników.  Ponieważ jeśli nie wiesz, jak interpretować i naprawiać poszczególne sugestie optymalizacyjne, możesz szybko zgubić się w bezsensownym polowaniu na 100 punktów. Byłoby to jednak nierozsądne. W końcu utopijne wyniki Google PageSpeed to zwykle strata czasu. Ważniejsza jest optymalizacja czasu ładowania strony.

W pełni responsywna, ładuje się w 500 ms, a lśniące narzędzie Google'a mówi mi, że moja wydajność na urządzeniach mobilnych jest „dobra”, ponieważ renderuje się przez pieprzony CSS.

- Caspar Hübinger (Glueckpress)

Dziś pokażę Ci, jak interpretować najważniejsze komunikaty o błędach z Google PageSpeed Insights i odpowiednio zoptymalizować swoją stronę.

Zanim jednak pokażę, jak interpretować poszczególne komunikaty o błędach i je naprawiać, chciałbym przejść do tego, jak poprawnie korzystać z Google PageSpeed Insights . Ponieważ często spotykaliśmy się z tym, że użytkownicy byli mocno zafiksowani na swoim wyniku PageSpeed, nie zwracając uwagi na czas ładowania strony.

Jeśli ta sekcja Cię nie interesuje, pomiń ją i dowiedz się bezpośrednio jak naprawić błąd "Kompresuj CSS".

Komunikaty o błędach Google PageSpeed nie zawsze są poprawne i ważne

Nigdy nie należy polegać wyłącznie na wynikach lub komunikatach o błędach z Google PageSpeed Insights. Ponieważ narzędzie Google nie mierzy najważniejszego parametru Twojej witryny: czasu ładowania strony. Aby zmierzyć to poprawnie, polecam Webpagetest.org.

Tylko wtedy, gdy podczas optymalizacji witryny od samego początku będziesz miał na uwadze czas ładowania strony, będziesz mógł sensownie wypowiedzieć się na temat sukcesu optymalizacji. Ponieważ celem każdej optymalizacji powinna być zawsze poprawa doświadczenia użytkownika. W przypadku optymalizacji wydajności jest to oczywiście czas ładowania strony oraz postrzegany czas ładowania strony.

Z punktu widzenia użytkownika, szybszy czas ładowania strony i mniejszy rozmiar strony są zawsze korzystne. Cierpliwość i uwaga przeciętnego użytkownika stale się zmniejsza (jak pokazują badania przeprowadzone przez Microsoft) - jest to szczególnie istotne w przypadku e-commerce - a coraz więcej odwiedzających trafia na strony za pośrednictwem urządzeń mobilnych. Już w 2016 roku 56 proc. Niemców regularnie korzystało z internetu za pośrednictwem smartfonów lub tabletów. Tutaj prędkość połączenia i ilość danych nie zawsze są nieograniczone. W związku z tym odpowiednie są chude, szybkie strony.

Google PageSpeed daje jednak tylko wskazówki dotyczące potencjału optymalizacyjnego strony i pozwala wyciągnąć tylko kilka wniosków na temat doświadczeń użytkownika. Niskie znaczenie komunikatów o błędach Google PageSpeed wzmacnia fakt, że narzędzia tego nie da się wyciszyć w niektórych obszarach, lub tylko przy znacznym dodatkowym wysiłku.

Na przykład odniesienie do buforowania przeglądarki będzie się zawsze pojawiać, gdy dołączone zostaną zasoby zewnętrzne - w tym własne usługi Google. Zasoby te nie mogą być jednak objęte buforowaniem strony przez przeglądarkę. Tak więc komunikat o błędzie nie ma znaczenia dla doświadczenia użytkownika witryny, ale jest produkowany przez logikę samego narzędzia. W najgorszym przypadku komunikat jest interpretowany tak, jakby nie było aktywnego buforowania przeglądarki.

Dlatego nie skupiaj się przede wszystkim na ocenie Google, ale na czasie ładowania. Jest to jedyny naprawdę ważny parametr.

Ale co z moim rankingiem w Google?

Przykład braku cachowania przeglądarki bardzo dobrze pokazuje, dlaczego nie należy dać się zniechęcić rzekomo złym wynikiem PageSpeed.

Na przykład, jeśli masz Google Maps lub Google Analytics osadzone na swojej stronie, będą one generować następujący komunikat o błędzie:

To samo dotyczy innych usług zewnętrznych. Na przykład na naszym czacie wsparcia.

Dlatego za każdym razem, kiedy testujemy naszą stronę w PageSpeed Insights, ten punkt jest wykreślany. Oznacza to, że wiemy, iż ten czynnik zawsze negatywnie zniekształca nasze wyniki i dlatego po prostu go ignorujemy.

Dla SEO Twojej witryny oznacza to, że czas ładowania i doświadczenie użytkownika są również o wiele ważniejsze dla rankingów Google niż konkretny wynik PageSpeed.

Ponieważ jeśli zoptymalizujesz czas ładowania się strony, automatycznie będziesz pracować nad wieloma obszarami, które są ważne dla Google. Poprawa czasu ładowania i wynik Google PageSpeed są więc w pewien sposób powiązane.

Moim zdaniem jednak nie daj się zgubić w polowaniu na wynik 100.

A teraz przejdźmy do optymalizacji!

Komunikat o błędzie 1: Kompresja CSS

Z naszego doświadczenia wynika, że jest to jeden z najbardziej denerwujących komunikatów o błędach z Google PageSpeed Insights.

Znaczenie: Ten komunikat o błędzie wskazuje, że pliki CSS Twojej strony mogą być jeszcze skompresowane (lub w powyższym przypadku, że zostało to już wykonane z powodzeniem). Taka redukcja zmniejsza liczbę znaków w dokumentach. Dzięki temu zmniejsza się rozmiar pliku. Usuwane są na przykład komentarze, spacje i formatowanie.

Realizacja: Nawet jeśli ta wskazówka wydaje się zniechęcająca, to realizacja jest bardzo prosta. W zasadzie istnieją dwa możliwe rozwiązania tego przypadku: Jeśli sam znasz się na CSS, możesz zmniejszyć liczbę plików CSS ręcznie i używać skrótów podczas ich tworzenia. Możesz także samodzielnie zmniejszyć rozmiar plików CSS, korzystając z narzędzi internetowych, takich jak CSS Compressor lub CSS Minifier.

Oczywiście istnieje również wygodne rozwiązanie, jakim są wtyczki do minifikacji CSS w WordPress. Niektóre wtyczki wykonują wszechstronną pracę i mogą kompresować i optymalizować nie tylko CSS, ale także JavaScript i HTML.

W przypadku HTTP/2, łączenie CSS niekoniecznie ma sens.

Szeroko stosowane są właśnie wspomniane Minify-Plugins . Dzieje się tak, ponieważ są one wygodne i zajmują się kompresją i łączeniem CSS (i nie tylko) w pełni automatycznie. Do niedawna łączenie plików CSS również miało wiele sensu. Teraz jest inaczej: ponieważ od kiedy istnieje standard HTTP/2, przeglądarki są w stanie ładować wiele plików z serwera WWW w tym samym czasie.

Oznacza to, że dane nie muszą być już koniecznie łączone, ponieważ dzięki HTTP/2 można jednocześnie wymieniać kilka pakietów danych. HTTP/2 musi być np. skonfigurowany przez hostingodawcę i może być używany tylko z certyfikatem SSL.

Zanim więc zdecydujesz się na Plugin z kilkudziesięcioma funkcjami i możliwościami konfiguracji, dobrze się zastanów, czy w ogóle jest Ci to potrzebne. Zwłaszcza jeśli jesteś pewien, że potrafisz samodzielnie zoptymalizować CSS.

Ponieważ dodatkowy Plugin może sprawić, że strona będzie wolniejsza w pewnych okolicznościach. Zwłaszcza jeśli pozostałe funkcje wszechstronnegoPlugins nie mogą rozwinąć swojego pełnego potencjału.

Komunikat o błędzie 2: Usuń zasoby, które blokują renderowanie

Ta wiadomość również wywołuje pot na czole wielu użytkowników, ponieważ nie jest łatwa do wdrożenia i jest jednym z odwiecznych punktów krytyki Google PageSpeed.

Znaczenie: Strona internetowa jest tworzona w określonej kolejności. Ta kolejność ładowania może być zoptymalizowana. PageSpeed prawie zawsze skarży się, że pliki CSS blokują ten optymalny porządek ładowania. Dotyczy to nawet stron, które zostały już bardzo dobrze zoptymalizowane (jak pokazuje przypadek Caspara Hübingera). Mimo to podpowiedź ta może być bardzo cenna dla optymalizacji czasu ładowania. Zasadniczo podpowiedź ta informuje, że kod JavaScript lub CSS, który jest ważny dla załadowania elementu - na przykład kolor tła - nie jest jeszcze dostępny w momencie ładowania elementu. W rezultacie nie jest on wyświetlany, dopóki nie zostanie załadowane odpowiednie polecenie CSS. To wydłuża czas ładowania strony, ale przede wszystkim wpływa na wrażenia użytkownika, który ma wrażenie, że strona ładuje się dłużej.

Umsetzung: Eine gängige Lösung ist die Umsetzung einer Daumenregel: CSS in den Header. Das bedeutet, dass du CSS-Code vom Hauptteil des HTML Dokuments, dem <body>, an den Anfang des Dokuments, den <head>, verschiebst und dort als <style> einbindest.

An diesem Beispiel wird deutlich, was ich meine. Der Codeschnipsel unten definiert unsere spezifische Hintergrundfarbe für den Blog. Das <style>-Element wird im head des HTML-Dokuments geladen. So lädt der Seitenhintergrund nicht erst am Ende des Dokuments und erzeugt einen unschönen Farbsprung oder blockiert gar das Rendering.

<head>
<style type="text/css" id="custom-background-css">
body.custom-background { background-color: #f5faff; }
</style>
</head>

Ponownie, możesz wdrożyć ten środek optymalizacji na dwa sposoby: Możesz dotknąć kodu samodzielnie i przenieść kody CSS do nagłówka, lub możesz pozwolić, aby Plugin wykonał pracę. Ponownie, Plugins jak Better WordPress Minify pomoże Ci tutaj.

MinifyPlugin pokazuje w opcjach, na przykład, które pliki CSS zostały już przeniesione do nagłówka. Możesz również ręcznie dodać więcej zasobów CSS w tym miejscu.

Z drugiej strony, Plugin Autoptimize idzie na całość: Tutaj wybierasz opcje dla wszystkich plików CSS, które nie są wykluczone z procesu.

Wypisy z opcji strony Plugins pokazują: Nawet wariant z wtyczką nie może być wdrożony bez podstawowego zrozumienia procesu. Dlatego należy również zapoznać się z Plugins .

Komunikat o błędzie 3: Skuteczne kodowanie obrazów

To kolejny punkt, na który PageSpeed Insights często narzeka. Jednak ten przypadek jest prawie zawsze szybki i łatwy do wdrożenia i zazwyczaj przynosi wymierne korzyści w zakresie czasu ładowania.

Znaczenie: Wielu użytkowników nie docenia roli rozmiaru obrazu na czas ładowania strony. Obrazki bardzo często są jednym z największych hamulców czasu ładowania strony. Nawet jeśli dla poszczególnych obrazów zapisywane są tylko niewielkie ilości danych, łączna ilość zapisanych danych może być znaczna.

Ponieważ obraz rzadko jest tylko obrazem. WordPress automatycznie generuje kilka miniaturek obrazu podczas przesyłania. Jeśli więc nie używasz oryginałów na swojej stronie głównej, ale ich mniejsze wersje, np. miniaturki lub wyróżnione obrazy, to oczywiście one również powinny być zoptymalizowane. Jeden obraz szybko staje się kilkoma plikami, które również niosą ze sobą wielokrotny ładunek danych.

Wykonanie: W zasadzie masz dwie możliwości optymalizacji swoich zdjęć. Albo optymalizujesz obrazy przed załadowaniem, albo po lub w trakcie ładowania. Pierwszy można zrobić za pomocą narzędzi online lub offline, drugi można zrobić za pomocą odpowiednich WordPress wtyczek optymalizacji obrazu.

Jeśli możesz zintegrować kompresję w swoim obiegu pracy, sensowne jest zoptymalizowanie zdjęć przed ich wysłaniem. Istnieją do tego narzędzia online, takie jak Kraken.io. Możesz też zredukować jakość, a tym samym rozmiar pliku swoich zdjęć offline, na przykład bezpośrednio w Photoshopie. W ten sposób zaoszczędzisz dodatkowe Plugin i zachowasz smukłość swojej strony.

Wygodniejszym rozwiązaniem jest oczywiście również tutaj Plugin. Dodatki takie jak Optimus czy Smush optymalizują nie tylko główny obraz, ale także wszystkie jego odmiany. Smush jest również w stanie zoptymalizować wszystkie istniejące obrazy.

Plugins działa między innymi w oparciu o tzw. kompresję bezstratną. Oznacza to, że rozmiar pliku obrazów jest zmniejszony, ale ich widoczna jakość nie ulega pogorszeniu.

Komunikat o błędzie 4: Włącz kompresję tekstu

Ten komunikat o błędzie z Google PageSpeed jest bardzo szybki do naprawienia i może znacznie skrócić czas ładowania strony.

Znaczenie: Zmniejszyłeś już obrazki i CSS swojej strony tak bardzo, jak to tylko możliwe. Dobra! Ale to nie koniec. Ponieważ teraz możesz użyć innego mechanizmu kompresji. Prawdopodobnie znasz ten proces z pobierania dużych pakietów danych: Zazwyczaj masz je w formie zzipowanej, czyli skompresowanej. Dzięki temu dane są mniejsze, a pobieranie szybsze. Jednak po pobraniu pakiety danych muszą być jeszcze rozpakowane. Dokładnie to samo dzieje się podczas ładowania strony: Serwer WWW dostarcza pakiety danych skompresowane, serwer WWW je rozpakowuje. Dzięki temu transfer danych jest szybszy i skraca się czas ładowania strony.

Realizacja: Albo kompresja danych jest już ustawiona po stronie serwera, albo musisz ją aktywować samodzielnie. Jeśli jesteś klientem Raidboxes, nie musisz się o nic martwić. Ponieważ domyślnie mamy aktywną szczególnie silną kompresję Brotli.

Dzięki następującemu wpisowi w .htaccess możesz również ręcznie aktywować tzw. kompresję GZIP. Pod warunkiem, że posiadasz serwer Apache.

<ifModule mod_gzip.c>
 mod_gzip_on Yes
 mod_gzip_dechunk Yes
 mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
 mod_gzip_item_include handler ^cgi-script$
 mod_gzip_item_include mime ^text/.*
 mod_gzip_item_include mime ^application/x-javascript.*
 mod_gzip_item_exclude mime ^image/.*
 mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
 </ifModule>
 
 <IfModule mod_deflate.c>
 AddOutputFilterByType DEFLATE text/plain
 AddOutputFilterByType DEFLATE text/html
 AddOutputFilterByType DEFLATE text/xml
 AddOutputFilterByType DEFLATE text/css
 AddOutputFilterByType DEFLATE application/xml
 AddOutputFilterByType DEFLATE application/xhtml+xml
 AddOutputFilterByType DEFLATE application/rss+xml
 AddOutputFilterByType DEFLATE application/javascript
 AddOutputFilterByType DEFLATE application/x-javascript
 </IfModule>

Komunikat o błędzie 5: Dostarczanie treści statycznych z efektywną polityką buforowania 

Moim zdaniem, odniesienie do buforowania przeglądarki jest zdecydowanie najbardziej irytujące w Google PageSpeed Insights. Dzieje się tak, ponieważ możesz ustawić buforowanie przeglądarki tylko dla swoich własnych zasobów. Buforowanie w przeglądarce nie jest możliwe dla zasobów zewnętrznych.

Znaczenie: Buforowanie przeglądarki oznacza, że przeglądarka przechowuje statyczną wersję strony i nie musi żądać strony z serwera internetowego, gdy odwiedzasz ją ponownie. Strona jest już załadowana.

Realizacja: Albo Twój hostingodawca już aktywował buforowanie przeglądarki po stronie serwera, albo możesz je ustawić, manipulując plikiem .htaccess (pamiętaj: to ustawienie działa tylko na serwerach Apache). Na przykład poniższy przykładowy kod ustawia buforowanie przeglądarki na jeden miesiąc, co oznacza, że statyczna wersja twojej strony będzie przechowywana w przeglądarce odwiedzającego przez jeden miesiąc.

<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access 60 seconds"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/ico "access plus 1 month"
ExpiresByType text/css "access 1 month"
ExpiresByType text/javascript "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
</IfModule>

Ponownie, jeśli jesteś klientem Raidboxes, to buforowanie przeglądarki jest już domyślnie aktywne.

Moja opinia: Bez pamięci podręcznej wszystko jest niczym

Dobrze, teraz zoptymalizowałeś obrazy na swojej stronie, zredukowałeś CSS, skompresowałeś je i ułożyłeś w odpowiedniej kolejności, a także sprawiłeś, że przeglądarka Twojego gościa zbuforowała stronę. Wszystkie te działania skracają czas ładowania strony.

Znaczenie: Bez odpowiedniego cache'owania, jednak, oddajesz wiele z tego potencjału. Buforowanie jest i pozostaje zdecydowanie najważniejszym czynnikiem wydajności. Cache tymczasowo przechowuje zawartość strony WordPress i sprawia, że cała strona nie musi być za każdym razem ładowana od nowa. Zamiast tego, statyczna, czyli już wyrenderowana wersja strony jest dostarczana z cache'u. Omija to powolne PHP i bazę danych w szczególności.

Realizacja: Ponownie, albo Twój hosting ma już ustawioną podręczną pamięć podręczną po stronie serwera, albo używasz wtyczki do buforowania. Istnieją bardzo wydajne wtyczki, które buforują duże części strony i prowadzą do znacznego skrócenia czasu ładowania strony dla powracających użytkowników.

Duża moc wtyczek buforujących jest jednocześnie ich największą słabością. Może się zdarzyć, że wtyczka buforująca początkowo spowolni działanie Twojej strony dla osób, które ją po raz pierwszy odwiedzą. Ponieważ im bardziej skomplikowany jest twój blog lub strona, tym bardziej skomplikowany i rozbudowany musi być silnik buforujący, który buforuje twój blog. Jest to szczególnie istotne dla sklepów internetowych.

Jeśli prowadzisz stosunkowo prostą stronę internetową, minimalistyczne rozwiązania mogą być lepsze niż wszechstronne buforowanie. Jedną z takich oszczędnych wtyczek jest na przykład Cache Enabler.

Należy pamiętać, że wtyczki buforujące zwykle przejmują także redukcję i scalanie CSS lub JavaScript. Dlatego należy sprawdzić, czy wtyczka buforująca nie czyni już zbędną wtyczki do optymalizacji CSS.

Jeśli używasz buforowania po stronie serwera, warto wyłączyć funkcje buforowania wtyczek, takich jak Autoptimize, lub sprawdzić, czy w ogóle przynoszą one jakiekolwiek korzyści w zakresie wydajności.

Wniosek: Dużo się dzieje dzięki kilku wtyczkom

Zauważyłeś to już podczas czytania: Do optymalizacji CSS, obrazów i kolejności ładowania istnieją wtyczki, które zdejmują z Ciebie wiele pracy. Ale nie całą pracę. Wtyczki do buforowania również szybko przynoszą zauważalne efekty, ale bywają bardzo rozbudowane i oferują wiele opcji konfiguracyjnych, a czasem zbędnych funkcji.

W każdym razie przyjrzyj się bliżej wtyczkom, których używasz. Tylko wtedy, gdy wiesz, co się dzieje, gdy używasz pewnych funkcji, możesz rozsądnie optymalizować. Przeładowanie strony wtyczkami optymalizacyjnymi raczej niewiele daje.

Podczas optymalizacji powinieneś zadbać o odpowiednie zmierzenie swojego sukcesu. Nie ma znaczenia, czy optymalizujesz ręcznie, czy za pomocą wtyczki. Użyj PageSpeed Insights jako pierwszego punktu odniesienia, aby zidentyfikować słabe punkty swojej strony. Następnie zmierz czas ładowania strony przed optymalizacją. Dopiero po nagraniu sytuacji wyjściowej ma sens optymalizacja strony krok po kroku. Tylko znając czas ładowania strony przed optymalizacją i po każdym kroku optymalizacji, możesz określić, co osiągnęły poszczególne działania optymalizacyjne.