[dev] Walka z Google PageSpeed w 2021

Standardy i wymagania Google w kwestii wydajności stron zmieniają się co kilka miesięcy. Strona główna mojego bloga jeszcze kilka miesięcy temu w PageSpeed osiągała wyniki w granicach 95, by ostatnio pokazać mi ~70 na urządzeniach mobilnych. Przeanalizowałam więc wszystkie błedy, które pojawiły się w narzędziu. O co więc każe nam dbać Google w 2021?

Przygotujcie się psychicznie na sporo angielskiego, bo nie będzie mi się chciało znajdywać tłumaczeń dla każdego hasła. Będzie też trochę łatwiej dla wszystkich, jeśli będę operować tymi samymi określeniami co Google. Tam, gdzie to ma sens oczywiście.

Teoria: czym jest PageSpeed?

Jeśli są tacy, co nie wiedzą, to trochę nie wiem, czemu się tu znajdują. Ale dobrze, już tłumaczę.

PageSpeed to narzędzie przygotowane przez Google, którego celem jest sprawdzenie, jak szybka jest nasza strona na urządzeniach mobilnych oraz desktopach. Wynik wyświetlony jest na wykresie kołowym, używając liczb od 0 do 100.

Rozkład punktów zmienia się co jakiś czas, kładąc nacisk na różnych czynnikach wpływających na zachowanie strony. Na stronie wyjaśniającej przyznawanie punktów są tabelki, które pokazują, jak się to niedawno zmieniło.

Lighthouse 5 pojawił się w maju 2019, wersja 6 zawitała rok później (maj 2020), a najnowsza wersja, 7, ujrzała światło dzienne w grudniu 2020.

W 6 wersji (w porównaniu z v5) szybkość samej strony jest mniej ważna od tego, jak bardzo strona zmienia się po wejściu. Cumulative Layout Shift przedstawiony w najnowszej aktualizacji skupia się na tym, ile procent ekranu wygląda inaczej w pierwszej sekundzie, niż po pełnym załadowaniu strony. Largest Contentful Paint skupia się na mediach lub dużych blokach tekstów, które potrzebują najdłużej, by się załadować. Dobry czas to do 2.5 sekundy.

Jeśli chcecie pobawić się suwaczkami z rozkładów punktowych wyników PageSpeed w wersji 5 oraz 6/7, Google udostępniło oficjalne narzędzie. Zmieniając wartości kolejnych elementów, od razu widzimy, jaki wpływ mają one na całokształt.

Praktyka: mój przypadek

Mój blog ogólnie rzecz biorąc z założenia jest… prosty. Kierunek w designie nazywa się Brutalizm i jego cechami charakterystycznymi są twarde przejścia między elementami, wszechobecne ramki i prostokąty. Nie ma gradientów, tylko zamiast tego bardzo płaskie i kontrastujące kolory. Oprócz zdjęć we wpisach nie ma tu więc elementów graficznych. Poza najnowszymi postami, reszta zdjęć jest nawet zniekształcona przez kolorową jaskrawą nakładkę.

To koncept, przy którym uzyskanie maksymalnego wyniku nie brzmiało bardzo trudno, choć faktycznie wymagało poświęceń.

Optymalizacja zdjęć

Jedna z podstawowych praktyk, które trzeba „uprawiać”, chcąc dbać o szybkość swojej strony. Najłatwiejszym sposobem (moim zdaniem) jest przerzucenie ich przez stronę tinyJPG.com.

Na przykładzie pierwszego lepszego zdjęcia pobranego z Unsplash mamy obrazek o wielkości 62.7 kB zamiast 109.6 kB. To oszczędność o aż 43%. Widzicie różnicę? Ja nie.

To jednak nie było u mnie problemem. Największe zdjęcie na mojej stronie ma 90 kB, a wszystkie (te, które ładują się na starcie) mają łącznie niecałe 160 kB. To malutko!

Wtyczki i skrypty

I tutaj znów, nie korzystam ze zbyt wielu dodatków. Mam wtyczkę, która dodaje wsparcie do wgrywania plików .svg oraz kilka własnych, dodających głównie statystyki. Mam Autoptimize (o którym opowiem za chwilę), Advanced Custom Fields (które nie dotyka frontendu w ogóle), wtyczkę do ankiet i lightboxa.

Oprócz tego swój kawałeczek kodu jQuery, który odpowiada za menu, animację liczenia liczby stron na podstronach z książkami czy lazy-loading do zdjęć. Na stronie korzystam też z Font Awesome 5 Pro.

Klasycznie, mam też Google Analytics. A raczej… miałam!

Google Analytics

Ten blog to moje własne poletko. Nie monetyzuję go w żaden sposób i raczej nie planuję. Mam gdzieś tam reflink do Huela czy Legimi, ale nie uważam, że blog powinien przynosić mi materialne korzyści. Zdecydowanie wystarczy, że mogę się wyżalić czy zrzucić siebie to, co siedzi mi w głowie. Czasem odkryjecie przez to jakiś horror albo serial. I świetnie, dokładnie o to chodziło!

Pozbycie się Google Analytics było więc decyzją, która w ogóle nie bolała i w pierwszej kolejności była podjęta ze względu na cookie, które Google dodaje. Wielka Czwórka śledzi nasz każdy ruch w internecie, więc pomyślałam, że dobrze dać Wam to jedno miejsce, gdzie poczujecie się bezpiecznie. Zaglądając w ciasteczka zobaczycie, że… nie ma żadnych!

Bez Google Analytics nie wiem, ile osób miesięcznie czyta mojego bloga. Ale może nadal zostawicie komentarz? Wystarczy mi to w zupełności do szczęścia.

W kwestii wpływu na PageSpeed, obraz mói więcej, niż tysiąc słów:

Jestem szczerze zaskoczona, jak wielki wpływ na ładowanie strony ma jedno głupie Google Analytics. Aż 9-10 punktów na mobile i znacznie opóźnione „malowanie” strony. Bardzo to dalekie od ideału.

Trochę też śmieszne, że Google tak bardzo obniża wyniki swoim własnym skryptem! Ha-ha.

Optymalizacja poza obrazkami

Poza zdjęciami na stronie, optymalizować można jeszcze całkiem sporo rzeczy. Będzie to między innymi: kod HTML (usuwanie komentarzy, pustych linijek, itp), CSS (usuwanie wszystkich niepotrzebnych znaków) czy JS (dokładnie to samo). Każda spacja (czy spacje zamienione na taby!) to w HTML-u i CSS-ie zaoszczędzone kilobajty. Kilka do kilkunastu procent na przestrzeni całego pliku. Wystarczająco dużo, by warto było o tym pomyśleć.

Nie robię tego jednak ręcznie, korzystam z wspomnianej już wtyczki Autoptimize, którą też z całego serca polecam. Dzięki niej, strona ma wyraźnie lepszy wynik.

Nie ma niestety sensu dzielić się jednak moimi ustawieniami, bo z doświadczenia wiem, że… różnie to bywa. Czasem jest sens wrzucić cały CSS do HTML-a, innym razem wręcz pogorszy to wynik. Czasem będzie sens grupować pliki JavaScripta w jedno, a innym razem jednak lepiej będzie zostawić je osobno. Zabawa w optymalizację w tym aspekcie wymaga testowania metodą prób i błędów, ale na pewno będziecie stanie znaleźć wyraźnie lepszą konfigurację.

Lazy Loading

To punkt, który radzę przeczytać uważnie, bo moje rozwiązanie jest trochę inne niż typowe.

Lazy loading to praktyka, o której już pisałam. W skrócie: obrazki ładujemy na końcu, serwując na początku tekst i całą resztę strony. Dobrze działający lazy loading obrazki znajdujące się poniżej ekranu ładuje dopiero po przesunięciu się bliżej sekcji. Bardzo często zmniejsza to ilość pobieranych danych, jeśli wchodzicie na stronę by kliknąć w pierwszy artykuł.

Rozwiązania do tego stworzone są na JavaScripcie i w większości przypadków będą podmieniać atrybut w obrazku z data-src na src.

To był punkt z którym długo walczyłam. JavaScript odpalający się po załadowaniu reszty strony, wyświetlał te obrazki kilkadziesiąt milisekund za późno. Co by tu zrobić? Wpadłam na pomysł, by pominąć lazy loading w tych kilku pierwszych obrazkach. Konkretnie, w pierwszych dwóch wpisach w głównej linii i pierwszym w dziale Książki, widocznym z prawej strony na desktopie.

I wiecie co? To był strzał w dziesiątkę!

LCP i CLS wzrosły drastycznie po zastosowaniu tego rozwiązania!

desktop z lazy loadingiem dla wszystkich zdjęć
mobile z lazy loadingiem dla wszystkich zdjęć
desktop z lazy loadingiem dla wszystkich zdjęć poza pierwszymi trzema
mobile z lazy loadingiem dla wszystkich zdjęć poza pierwszymi trzema

Byłam w szoku szczerze mówiąc. Jak wielki wpływ ma lazy loading na tę wartość. Zdecydowanie czegoś się nauczyłam. To był ten ostatni magiczny trick, który sprawił, że udało mi się dobić do setki.

Jak uzyskać 100 punktów w PageSpeed?

Walcząc o idealny wynik (gdzie nawet Google mówi, że nie warto próbować) uświadomiłam sobie, że wszystko ma znaczenie. Nawet takie drobnostki jak to, czy zdjęcia na stronie są ciemne, czy jasne. Albo inaczej: czy zdjęcia są podobne do tła w przygotowanym na nie miejscu.

Co musiałam zrobić, żeby dotrzeć do takiego wyniku?

1. Porzucić fonty z Adobe Fonts

Korzystam z Typekita od lat i uwielbiam tamtejszy wybór. W porównaniu z fontami dostępnymi w Google Fonts, często widać, że to po prostu lepsza jakość. A dodatkowo, są one znacznie mniej popularne, więc łatwiej uzyskać coś unikatowego.

Nowe rozwiązanie:

Kiedyś kupiłam paczkę fontów, więc ograniczyłam się do nich. Są one teraz serwowane z mojego serwera, ograniczając pobieranie zasobów z zewnętrznych źródeł.

Takie rozwiązanie zdecydowanie bardziej odpowiada PageSpeedowi.

Pamiętajcie, że nie musicie ograniczać się do kupionych fontów: te z Google Fonts też możecie pobrać i ładować od siebie.

2. Pozbyć się Google Analytics

Punkt wyjaśniony wyżej.

Nowe rozwiązanie:

Jeśli brakuje Wam jakichkolwiek statystyk, możecie założyć sobie konto w Google Search Console, które przynajmniej pokaże Wam ruch z wyszukiwarek. W moim przypadku to zawsze było i tak 80%.

3. Ograniczenie skryptów i wtyczek

Znowu, punkt wyjaśniony wyżej.

Nowe rozwiązanie:

Jeśli macie minimum wtyczek, ale wciąż Wasz wynik nie jest idealny, rozważcie zamknięcie wp_head() w ifie sprawdzającym, czy to strona główna. To może i szalony, może dziwny zabieg, ale ma trochę sensu.

Na stronie głównej nie potrzebuję skryptu z lightboxa, czy pełnego Font Awesome. Oznacza to oczywiście, że poza stroną główną wynik będzie trochę gorszy, ale to już mniejszy problem. To wciąż wyniki powyżej 90 w większości przypadków.

4. Font Awesome? Tylko z własnego zestawu

To coś co nie dotyczy wszystkich, ale nie po to płacę za Font Awesome Pro, żeby z niego nie korzystać. W jednej z niedawnych aktualizacji pojawiła się możliwość tworzenia własnych zestawów, dzięki niej nie trzeba ładować całego Font Awesome 5 Pro, żeby wykorzystać kilkanaście ikon z różnych zestawów. Program na komputerze umożliwia wybranie potrzebnych ikon i pobranie ich jako paczka gotowa do wrzucenia na stronę. Nieidealne rozwiązanie, bo dodawanie pojedynczych ikon jest… uciążliwe.

Nowe rozwiązanie:

Zrobić własny zestaw, malusieńki, na stronę główną. Ładowanie kitu JavaScriptem na pojedynczych wpisach jest jak najbardziej w porządku.

Pozostałe kategorie

Poza szybkością ładowania strony, PageSpeed w ramach Lighthouse oferuje również narzędzia, które sprawdzają, jak dobrze nasza strona wypada z dostępnością, dobrymi praktykami i SEO.

Dostępność (Accessibility) będzie odpowiadać za to, jak dobrze nasza strona przystosowana jest do użytkowania przez ludzi ze specjalnymi potrzebami. Oznacza to duży nacisk na kontrast elementów oraz ich wielkość, a także na ułatwienia dostępu przez czytniki (screen readery), pomagające na co dzień osobom niedowidzącym. Wymaga to, by elementy były poprawnie opisane, szczególnie linki, które wyświetlamy w formie ikonek czy zdjęcia do wpisów. W większości przypadków wystarcza dodanie atrybutu title lub aria-label.

Dobre praktyki to jedyny aspekt, który nie wymaga ode mnie zazwyczaj niczego. Znajdziemy tam HTTPS, obrazki o poprawnych proporcjach czy informacje o wygasających API.

SEO to przede wszystkim informacje zawarte w meta strony (opis), obrazki posiadają alternatywny opis, a obszary klikalne są wystarczająco duże (minimum 48 x 48 pikseli na urządzeniach mobilnych!).


Mój blog to edge-case. Mało kto będzie mógł aż tyle zrobić dla głupiego wyniku w PageSpeed. Inne narzędzia, jak GTMetrix są znacznie bardziej łaskawe i łatwiej osiągnąć zielony wynik.

Dobrze jednak raz na jakiś czas przejrzeć tę listę, skonfrontować z tym, co na stronie i coś poprawić. Nawet nie dla Google i PageSpeed, ale dla użytkowników. I choć wiem, że internet jest coraz lepszy, a komputery czy telefony znacznie szybsze, dobrze wziąć pod uwagę użytkowników i ich czas. Prywatność też!

Mój przypadek najeżony jest kompromisami i „trickami”, które nie przejdą w przypadku gotowych motywów czy serwisów z większą liczbą wpisów potrzebnych na stronie głównej. Ten wynik to mój prywatny kamień milowy, chciałam sama sobie udowodnić, że się da. Na WordPressie. Z jQuery. Z obrazkami i customowymi fontami.

Ile Wam się uda „odzyskać”?

Illustration by Stories by Freepik

sobota
06.03.2021
9
1

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Dzięki za inspirujący wpis, pewnie wykluje się coś i u mnie w temacie. Będę musiał nieco pogrzebać, choć w moim przypadku to już raczej sztuka dla sztuki, jeśli chodzi o webperf. Czemu? Bo mam 99 lub 100, a jedyną rzeczą, którą mógłbym poprawić jest… czas początkowej odpowiedzi serwera. Mam i na to pomysł, ale nie wiem, czy chcę go stosować. Oczywiście chodzi o coś innego niż rzut monetą i zmiana VPS na szybszy. Co pewnie też by pomogło.

Do wyłączenia lazy loadingu (w ogóle!) doszedłem sam. To fajne rozwiązanie, gdy zdjęć jest wiele. Jeśli jest powiedzmy jedno do wpisu lub mniej – więcej szkody niż pożytku. Nie jest to niestety jasno komunikowane.

Zdecydowanie muszę się przyjrzeć serwowaniu fontów Google od siebie. Póki co zrezygnowałem z nich zupełnie, bez wielkiego żalu.

Najbardziej jednak zdziwił mnie wynik tinyjpg. Używam pluginu do bezstratnej optymalizacji (EWWW image optimizer), który też robi robotę, tj. zmniejsza rozmiar ale… tinyjpg jest stratny i daje znacznie większe zyski, nawet w stosunku do już zoptymalizowanych bezstratnie grafik. Muszę obadać, bo mój plugin robił jeszcze lazy loading (wyłączone) oraz konwersję do webp.

I jedną rzecz podpowiem: ze statystyk nie musisz rezygnować. Matomo (dawniej: Piwik) serwowany z tej samej domeny co blog nie wpływa zauważalnie na statystyki webperf.

jQuery ładuję, bo go faktycznie potrzebuję do swoich własnych skryptów (obsługa menu, szukajki + lazy loading). Żadnych innych skryptów nie ma ;) A kody z wtyczek potrzebuję i ładuję je wszędzie poza stroną główną, co jest wytłumaczone w jednym z paragrafów.

U mnie jest tak, że JQuery potrzebuję w pojedynczych wpisach, ale już na głównej – nie. No ale tu już każdy po swojemu.

Nie ma szans, przejrzałam sobie o co mi krzyczy i musiałabym w ogóle nie mieć obrazków, albo zrezygnować z fontów ;)

„A high WebBS usually indicates unused stuff on the page: JavaScript, CSS, oversized images, etc. Maybe you have a valid reason for that content. But more often than not, it means you can optimize it more.”

Nie ma na mojej stronie ani „unused JavaScript”… ani CSS-a ani obrazków ;)

A nie, czekaj, jeszcze śmieszniej :D

bo współczynnik mówi: rozmiar strony / rozmiar obrazków.
Czyli co, jak bym miała więcej javascriptów, fontów i CSS-ów, to bym miała lepszy wynik 🤣 sorry, ale, lol, debilizm :D i nie ma nic wspólnego z „bloated”. Bo jak ja przeglądam internet to znacznie bardziej przeszkadza mi ilość skryptów na stronach, niż samych obrazków.

Przeczytaj jeszcze raz, uważnie. Nie „obrazków” , tylko „graficznej vs tekstowej reprezentacji strony”. Jeżeli jakiś skrypt nie wpływa na układ graficzny strony, to jest uznawany za „bloat” , no chyba że jest absolutnie niezbędny do czegoś innego.

Oboje nie macie racji.

To rozwiązanie w ogóle nie patrzy, czy JS czy CSS jest potrzebny, czy nie. Wystarczy, że jest i już się wlicza do rozmiaru. Ogólnie rozwiązanie pobiera całość strony (obrazki, html, css, JS, wszystko) w wersji tradycyjnej, renderuje wynik i robi png z renderu. Następnie porównuje stosunek ilości bajtów pobranych tradycyjnie i w png z renderu.

To oczywiście nie jest żadna sensowna miara, a jedynie ciekawostka. Czemu? Bo i rozmiar ekranu wynikowego, i możliwość kompresji w wynikowym png będą drastycznie wpływać na wynik. Zwłaszcza to ostatnie może być mylące. Strona ze szczegółowymi czy kolorowymi obrazkami w jpg/webp, które słabo się nadają do png automatycznie zyska. Podobnie jak strona, która ma proste wizualnie fonty lub unika gradientów.