Jak uzyskać 100 punktów w PageSpeed Insights?

Uzyskanie maksymalnego wyniku 100% w PageSpeed Insights jest mokrym snem web deweloperów oraz SEOwców. Tajemnicą poliszynela jest fakt, że osiągnięcie wyniku 100/100 nie należy do szczególnie trudnych zadań jeżeli tworzymy stronę od podstaw. Wystarczy tak naprawdę przestrzegać bardzo prostych zasad w tworzeniu stron internetowych i unikać wykorzystywania tanich szablonów z zagranicznych marketów.

W tym artykule podpowiem jak zdobyć 100 procent w teście Page Speed Insights zarówno dla urządzeń mobilnych jak i Desktop. Jeżeli interesuje cię jak działa, co mierzy i jaki wpływ mają na pozycje osiągane wyniki w tym narzedziu zapraszam do artykułu: Wpływ wyniku PageSpeed na pozycjonowanie.

Jakość to doskonałość, której nie da się osiągnąć, lecz do której trzeba uporczywie zdążać.

Lao Tsu

Prawie każdą stronę można przerobić tak, że będzie uzyskiwać powyżej 90 punktów na 100 (desktop i mobile). Problem w tym, że dla jednej strony internetowej będzie to kwestia kilku minut, innej kilku godzin a dla jeszcze innej kilka dni pracy. Jeżeli próbujesz sam poprawić wynik lub szukasz usługi polegającej na poprawieniu wyniku PSI musisz wiedzieć kilka ważnych rzeczy:

• w przypadku typowych stron na których wynik jest ekstremalnie niski wartości w PageSpeed najbardziej zaniżają dodatki z zewnątrz (widget Instagrama, Facebook) i tego typu integracje, które czasem są istotne lub nie wnoszą aż takiej wartości do naszej strony – ich usunięcie lub umieszczenie w taki sposób aby nie blokowały strony to najprostsza metoda na poprawę bardzo niskiego wyniku,
• 100/100 punktów jest możliwe do uzyskania na stronach tworzonych od podstaw pod to wymaganie i na odpowiednim hostingu – przestaje się używać przeładowanych skryptami szablonów i każdy dodatek w postaci skryptu czy stylu jest osobno optymalizowany dla wyniku PageSpeed Insights,
• ostatni punkt ma pozytywny wydźwięk, bo zawsze jest coś co można jeszcze poprawić. Jeszcze nigdy się nie zdarzyło, że po optymalizacji, o której możesz przeczytać w tym artykule, wynik nie drgnął w górę.

Za sukces należy już uważać poprawę o kilka punktów.

Ciekawostką jest też fakt, że sposób ewaluacji stron w tym narzędziu jest co jakiś czas uaktualniany. Niegdyś sprawdzał czas odpowiedzi (oczywiście w postaci TTFB) i tego czy deweloperzy trzymają się starych i sprawdzonych technik optymalizacji stron takich jak:

• minimalizacja kodu HTML, CSS, JS,
• stosowania zoptymalizowanych grafik,
• wykorzystywania pamięci podręcznej.

Obecnie sprawdza także wydajność stron, czyli:

• czas do pełnej interaktywności,
• procesor bezczynny po raz pierwszy,

a także User Experience

• widoczność tekstu podczas ładowania się strony internetowej,
• stabilność wizualna strony internetowej (czy strona nie „skacze” przy ładowaniu),
• używanie pasywnych detektorów do poprawy działania przewijania.

Niektóre wymogi zostały troszkę zmienione np. kiedyś ustawienie nagłówków Expires na 30 dni dawało pełny wynik, dziś trzeba je ustawić na okres pełnego roku ale do tego jeszcze dojdziemy.

Punkty nie są przyznawane liniowo lecz logarytmicznie. Poprawa wyniku z 99 na 100 wiąże się z dużo większym wysiłkiem niż poprawa z 74 na 75.

Szczegółowe metryki wydajności

PageSpeed Insights posługuje się czterema metrykami, których wynik w podsumowaniu badania jest przedstawiony za pomocą punktacji do 100.

Zaś wielkość tych pasków to ilość użytkowników z badań CrUX, dla których dany wskaźnik mieścił się w przedziale.

1. Pierwsze wyrenderowanie treści (FCP ang. First Contentful Paint) – mierzy jak długo zajmuje przeglądarce wygenerowanie pierwszego kawałka DOM po kliknięciu w link do badanej strony lub po wpisaniu jej w pasek adresu. Zalecany wynik to 1.5 sekundy.
2. Opóźnienie od pierwszej interakcji (FID ang. First Inpud Delay) – ponieważ to jak szybko pojawi się strona w wyszukiwarce to tylko część historii, ta metryka sprawdza jak długo po załadowaniu tych pierwszych obiektów DOM użytkownik musi czekać na możliwość interakcji (np. kliknięcie w linki lub wykorzystanie dołączonych do strony skryptów reagujących na inne zdarzenia).
3. Największe wyrenderowanie treści (LCP ang. Largest Contentful Paint) – sprawdza ile czasu zajmuje pojawienie się największego elementu DOM u góry strony (jest to np. slajd, grafika, slogan itd…).
4. Skumulowane przesunięcie układu (CLS ang. Cumulative Layout Shift) – pewnie nie raz kliknąłeś na reklamowy banner tylko dlatego, że pojawił się później niż reszta strony. Ta metryka wykrywa takie sytuacje i sumuje rozmiar przesunięcia – jak można się domyślić – im jest ono mniejsze, tym lepiej.

Czytaj więcej w osobnym artykule: Podstawowe wskaźniki internetowe.

Jak poprawić wynik w PageSpeed Insights?

Poprawa wyniku jest możliwa za pomocą realnego przyspieszania wczytywania i renderowania stron interntowych w przeglądarkach. Poniżej kilka technik optymalizacyjnych, które umożliwiają polepszyć parametry FCP, FID, LCP i CLS i tym samym zwiększyć wynik w PageSpeed Insights.

Wyświetlaj obrazy w formatach nowej generacji

PageSpeed Insights często podpowiada aby stosować formaty graficzne nowej generacji. Mowa oczywiście o otwartym standardzie grafiki internetowej jakim jest WebP, o którym pisałem już jakiś czas temu w artykule o optymalizacji zdjęć na stronach internetowych. Jako, że podmiana wszystkich grafik z PNG i JPG (lub JPEG) na WebP spodoba się użytkownikom Chrome, Opery, Safari, Edge i Firefoxa to użytkownicy nieco gorszych przeglądarek takich jak starsze IE będą troszkę zawiedzeni – dlaczego? – ponieważ nie zobaczą zdjęć. Przeglądarki te nie wspierają formatu WebP.

Jest metoda aby pogodzić potrzeby obu grup użytkowników – należy użyć podejścia progressive enhancement i zdjęcia zamieszczać zarówno w starym jak i nowym formacie. Chociaż PageSpeed tego nie wymaga, warto się pochylić nad nieco mniej zaawansowanymi użytkownikami Internetu i zamieścić alternatywne formaty starszej generacji w następujący sposób:

<picture> 
	<source type="image/webp" srcset="obrazek.webp"> 
	<img src="obrazek.png" alt="opis obrazka"> 
 </picture>

lub wykorzystać możliwość dynamicznego przekierowywania do obrazków WebP na poziomie serwera. Nowe formaty należy zastosować także dla atrybutów poster w klipach video oraz dla tła (background-image) i dynamicznie wykorzystywanych atrybutów typu data-src w efektach parallax itp.

Jeżeli interesuje Cię ten wątek, czytaj więcej o WebP i innych formatach graficznych nowej generacji. Poprawa w tej sferze może poprawić metryki FCP, FID, LCP.

Odłóż ładowanie obrazów poza ekranem

W przypadku obrazów, należy też stosować technikę optymalizacyjną o nazwie lazy-load. Polega to na tym, że grafiki które są położone niżej niż ok. 1600 pikseli mają być ładowane z opóźnieniem, np. po jakimś czasie od pełnego wczytania się strony lub po przewinięciu widoku w dół.

O tym jak działa w praktyce lazy load, jak go zaprogramować (także według najnowszej metody z wykorzystaniem atrybutu loading) napisałem w artykule: Lazy load czyli opóźnione ładowanie zdjęć. Uwaga: lazy-load może poprawiać FCP, FID, LCP ale wdrożony niepoprawnie może to robić kosztem CLS. Aby temu zapobiec, przy dodawaniu zdjęć należy posługiwać się atrybutami width oraz height, które „zarezerwują” miejsce na zdjęcie zapobiegając „skakaniu” strony.

Wyświetlaj zasoby statyczne, stosując efektywne zasady pamięci podręcznej 

Raz pobrany plik z serwera może być wielokrotnie użyty przez przeglądarkę do generowania wyglądu kolejnych podstron witryny. Pamięć podręczna plików statycznych oraz nagłówki sterujące buforowaniem zasobów w kolejnych warstwach infrastruktury to jedna z najbardziej pierwotnych i krytycznych technik optymalizacji witryn internetowych. Czytaj więcej jak ustawić nagłówki Expires i Cache-Control oraz jakie są między nimi różnice.

Włącz kompresję tekstu

Znaczne przyspieszenie pobierania się witryn internetowych jest możliwe dzięki bezstratnej kompresji danych. Kompresja zasobów tekstowych jest dostępna dzięki algorytmom Brotli lub Deflate (GZIP). Kompresję tekstową stosujemy najczęściej dla zasobów HTML, CSS, JS oraz XML. Zmniejsza ona rozmiar sumaryczny całej strony internetowej przyczyniając się do szybszego wczytywania poszczególnych podstron. Czytaj o tym jak włączyć Brotli / GZIP / deflate na standardowym serwerze WWW.

Minifikuj CSS, Minifikuj JavaScript

Dużo mniej efektywna ale niosąca wielowymiarowe korzyści jest minimalizacja kodu CSS i JS. Jest to usunięcie nadmiarowych znaków w kodzie, który nie wpłynie na finalny efekt interpretacji przez silnik przeglądarki. Spacje i tabulatory i znaki nowej linii w kodzie interpretowanym są potrzebne tylko podczas pracy z kodem. W CSS można je usunąć a w JS można dokonać to samo ale dodatkowo zmieniając nazwy zmiennych i funkcji na unikalne i jednoliterowe zamienniki. Jest wiele narzędzi które automatyzują tego typu prace i o nich napisałem osobny artykuł. Czytaj jak poradzić sobie z tym punktem w minimalizacji kodu CSS i JavaScript.

Usuń nieużywany kod CSS

Nowa wersja PageSpeed Insights wymaga nie tylko minimalizacji ale także usunięcia nieużywanych instrukcji CSS. Skąd się biorą taki instrukcje? Obecnie strony są budowane z wykorzystaniem front-endowych frameworków czyli takich szkieletów jak Bootstrap a nawet gotowych szablonów stron WWW które oczywiście mają swoje zalety ale zawierają wiele elementów interfejsu których nie wykorzystujemy. Należy te elementy z arkusza stylu usunąć. Jest to jeden z trudniejszych punktów do zrealizowania bez odpowiednich narzędzi i motywacji ale jest możliwy do wykonania kiedy znamy CSS, ilość plików do optymalizacji jest umiarkowana i znamy zaawansowane funkcje przeglądarki Chrome. Czytaj więcej o tym jak usunąć nieużywany kod CSS. Usuwanie nadmiarowego kodu CSS znacznie poprawia FCP i FID na urządzeniach mobilnych.

Usuń nieużywany JavaScript

To samo co wyżej ale odnosi się do plików ze skryptami JavaScript. Wiele skryptów jest potrzebnych tylko na jednej stronie. Niepotrzebne ładowanie raz użytych skryptów znacznie spowalnia stronę obniżając realną prędkość i wyniki w analizie podstawowych wskaźników internetowych.

Dobrym przykładem są tutaj skrypty ReCaptcha, skrypty do obsługi formularzy czy obsługa pokazu slajdów ze strony głównej. Mimo, że z tych mechanizmów korzystamy tylko na wybranych podstronach np. „kontakt” lub „strona główna” – w wielu systemach CMS pliki te są ładowane do kazdej podstrony. Za pomocą prostych instrukcji if, można spowodować aby kod był ładowany tylko tam gdzie jest to potrzebne.

Kolejnym skutecznym sposobem na usunięcie nieużywanego kodu JavaScript jest pozbycie się zależności od bibliotek i gotowych wtyczek. Przykładem może być całkowite usunięcie jQuery zastępując wykorzystywane metody na natywny kod Vanilla JS. Sprawdź przykłady jak przerobić popularne metody jQuery na czysty JavaScript. Drugim przykładem może być zastosowanie najnowszych bibliotek które tą zależnością nie są ograniczone. Dokonując aktualizacji Bootstrapa 4 i 4.5 na Bootstrap 5 pozbywamy się zależności od jQuery zachowując w miarę dobrą kompatybilność kodu. Biblioteka RequireJS też może wspomóc deweloperów w optymalizacji plików JS.

Wyeliminuj zasoby blokujące renderowanie

Ilość oraz rozmiar zasobów zewnętrznych ma ogromny wpływ na uzyskiwany wynik PSI. Choć nie należy bać się każdej linijki CSS i JavaScript należy podjąć wszelki wysiłek aby zoptymalizować ich ładowanie i sterować kolejnością ich ładowania.

Ten punkt jest połączony z dwoma poprzednimi poprzednim, ale poza zawartością skryptów, ważny jest także sposób ich umieszczenia na stronie internetowej. Najlepszą i zalecaną przez Google praktyką jest wydzielenie krytycznego CSS (potrzebnego do poprawnego wyświetlania się pierwszego ekranu strony), wklejeniu go do nagłówka kodu HTML (in-line) a pozostałe instrukcje dołączyć w postaci plików opóźniając ich załadowanie. Czytaj więcej jak tego dokonać i zoptymalizować krytyczną ścieżkę renderowania w artykule o tym jak wyeliminować zasoby blokujące renderowanie.

Zapewnij widoczność tekstu podczas ładowania czcionek internetowych

To jeden z punktów, który dotyka nie tyle szybkości wczytywania co User Experience witryny. Jeżeli korzystasz w niej z niestandardowych fontów możesz pozwolić przyspieszyć widoczność strony wyświetlając tekst za pomocą standardowej „czcionki” dzięki nowym właściwościom w CSS. Wystarczy dodać do elementów, w których używamy niestandardowych fontów właściwości font-display:

@font-face{
   font-family:Lato;
   font-style:normal;
   font-weight:400;
   font-display:swap;
   src:local('Lato Regular');
}

Właściwość ta steruje jak ma zachowywać się przeglądarka w przypadku stylowania pisma niestandardowymi fontami. Przykładowo wartość „swap” powoduje, że jeśli font nie jest załadowany, każdy element, który próbuje jej użyć musi wyrenderować się przy użyciu fontu rezerwowego (po prostu kolejnego w liście font-family). Jeśli font zostanie pomyślnie i szybko załadowany, jest używany standardowo. Przy wolnym połączeniu internetowym lub w przypadku słabo zoptymalizowanych stron, użytkownik będzie korzystał z fontu rezerwowego np. domyślnego fontu przeglądarki lub font się zauważalnie „podmieni” krótko po pełnym wczytaniu witryny.

Czytaj więcej o innych technikach optymalizowania fontów, które przyspieszają wczytywanie się stron i poprawiają wynik w PageSpeed Insights takich jak preload, unicode range czy usuwanie niepotrzebnych wariantów: Optymalizacja fontów na stronach internetowych. Optymalziacja fontów powinna być przeprowadzona starannie aby nie pogorszyć CLS.

Skróć wstępny czas reakcji serwera (TTFB)

Uwaga „Reduce initial server response time” dotyczy czasu reakcji serwera TTFB (ang. Time To First Byte) to opóźnienie, które jest liczone od wysłania żądania HTTP do serwera WWW do momentu odebrania przez nas pierwszego bajtu odpowiedzi. Im mniejszy czas TTFB tym lepiej – określa on jednocześnie jakość hostingu oraz jakość wdrożenia witryny, sklepu czy aplikacji internetowej. W bardzo dużym stopniu wpływa na ostateczny wynik PSI.

Na długość czasu TTFB składa się ogrom czynników ale najważniejsze z nich to:

• poziom skomplikowania CMSa i złożoności obliczeniowej generowania widoków w back-endzie,
• jego dodatków (modułów, pluginów, rozszerzeń i ich ilości),
• faktycznych parametrów i optymalizacji serwera,
• fizyczna odległość klienta od serwera WWW,
• obciążenie serwera ruchem (obciążenie łącza i CPU),
• usługi zewnętrzne po stronie back-endu.

Czas TTFB można radykalnie skrócić za pomocą skorzystania z technik pamięci podręcznej w warstwie aplikacji, ulepszeniu opcji serwera lub migracji do innej firmy hostingowej. Czytaj w jaki sposób testować i jak skrócić czas TTFB witryny w różnych CMSach w osobnym artykule.

Unikaj zbyt dużego DOM

Co to jest element DOM? Element DOM lub obiekt DOM to nic innego jak dowolny element na danej podstronie witryny. Może to być obrazek, link, div, przycisk, formularz. Niektóre elementy DOM mogą być zagnieżdżane tzn. mogą być elementami podrzędnymi (dziecko) w stosunku do swoich elementów nadrzędnych (rodziców).

Test ten może być oblewany przez wyjątkowo rozbudowane podstrony np. strony główne w sklepie internetowym, portale z reklamami lub długie tzw. strony One-Page. PageSpeed Insights zgłasza ten problem wtedy, kiedy tych elementów jest zbyt dużo lub są zbyt głęboko pozagnieżdżane, według dokumentacji:

• więcej niż 1500 elementów,
• o głębokości większej niż 32 poziomy,
• zawierające więcej niż 60 elementów potomnych.

Dla przykładu karuzela z najnowszymi produktami nie powinna zawierać więcej niż kilkanaście ostatnich produktów. Menu nie powinno być nadmiernie rozbudowane. W sekcji komentarzy napisałem odpowiedź jak można radzić sobie z tym problemem.

Załaduj wstępnie kluczowe żądania

Czym są kluczowe żądania? Kluczowe żądania to zasoby, które są niezbędne do poprawnego renderowania się strony w przeglądarce. Mogą to być style CSS i nieco rzadziej skrypty JS. PageSpeed zgłasza ten problem, kiedy żądania te nie są umieszczone bezpośrednio w kodzie HTML a są zagnieżdżone w innym stylu CSS lub skrypcie JS. Rozwiązanie jest bardzo proste: dodać tag preload przed styl lub skrypt, który będzie chciał je załadować:

<link rel="preload" href="style.css" as="style">

Można też usunąć żądanie w oryginalnym miejscu i załadować je w wyższej partii nagłówka, przykładowo w postaci kawałka stylu inline. To dość częsty problem w przypadku właściwości font-face src dotyczących plików z fontami.

Nie używa pasywnych detektorów do poprawy działania przewijania

Detektory zdarzeń dotyku i przewijania wykorzystujemy po stronie JavaScriptu do tworzenia płynniejszego przewijania strony, tworzenia niestandardowej nawigacji (np. przewijania w bok) oraz do zmiany domyślnego zachowania się niektórych elementów np. linków, które zamiast odsyłać do strony płynnie przewijają widok do elementów położonych na innej wysokości.

Na stronach często stosuje się z takiej instrukcji. Można ją znaleźć w popularnej bibliotece jQuery:

document.addEventListener("touchstart", handleStart, false);

Wadą takich rozwiązań jest to, że funkcje te mogą blokować lub opóźniać interakcję. Na szczęście w nowych przeglądarkach rozwiązano ten problem i wprowadzono argument który pozwala przekształcić je na pasywny detektor. Wystarczy w funkcji addEventListener ustawić flagę passive na wartość true:

document.addEventListener('touchstart', onTouchStart, {passive: true});

Unikaj document.write()

Funkcja document.write() to instrukcja JavaScript pozwalająca dodać treść lub kod JavaScript do strony przy jej ładowaniu. Ładowane w ten sposób mogą być reklamy lub inne dynamiczne funkcjonalności. Niestety, metoda ta sztucznie opóźnia ładowanie się strony, ponieważ zmusza do ponownego parsowania kodu a niektóre przeglądarki (w tym Chrome) mogą zablokować wykonanie się tego skryptu.

Zamiast przestarzałego document.write() można użyć asynchronicznego ładowania zasobów za pomocą instrukcji async:

<script src="skrypt.js" async></script>

Zminimalizuj aktywność głównego wątku 

Każde odświeżenie strony internetowej w przeglądarce przekształca kod HTML, CSS i JS w to co użytkownik widzi w polu roboczym przeglądarki. Główny wątek procesu renderowania analizuje kod HTML, buduje model DOM, analizuje CSS oraz wykonuje kod JavaScript. Główny wątek przetwarza jednocześnie wszelkie zdarzenia użytkownika przeglądarki. Jeżeli wątek jest zajęty analizowaniem strony, przeglądarka może nie reagować na zdarzenia co znacznie obniża jakość doświadczeń użytkownika. Lighthouse wyświetli ten błąd jeżeli główny wątek jest zajęty dłużej niż przez 4 sekundy.

Zajmowanie głównego wątku wykonywaniem nadmiarowego kodu zwiększa wskaźnik TBT (ang. Total Blocking Time), jest to czas, który jest liczony od FCP do TTI. Można skutecznie zminimalizować aktywność głównego wątku poprzez zmniejszenie ładunków sieciowych, opóźnienie ładowania dodatkowych skryptów za pomocą technik lazy-load, uproszczenie kodu CSS wydzielenie kodu krytycznego CSS, usunięcie nieużywanego kodu CSS i JavaScript.

Skróć czas wykonywania JavaScriptu 

Identyczne działania optymalizacyjne można wykonać w przypadku konieczności skrócenia wykonywania JavaScriptu. Kiedy twój kod JavaScript wykonuje się zbyt długo, spowalnia on stronę na kilka sposobów: kod jest obszerny i zabiera pasmo internetowe, spora ilość kodu zajmuje główny wątek i podwyższa opóźnienie TBT a nadmierna konsumpcja pamięci, która może temu towarzyszyć doprowadza do kolejnych opóźnień i zablokowania interaktywności.

PageSpeed zgłasza ostrzeżenie jeżeli samo wykonywanie JavaScriptu zajmuje dłużej niż 2 sekundy a jeżeli wykonywanie przekracza 3.5 sekundy zgłasza błąd.

Zmień rozmiar obrazów

Dodawane do strony zdjęcia i grafiki rastrowe powinny być nie większe niż faktyczny rozmiar wyrenderowanego elementu <img> na stronie internetowej. Pozwala to uzyskać idealną jakość wizualną zdjęcia nie marnując przy tym transferu. Bieżącą wielkość obrazka na stronie wyświetlonej w przeglądarce można sprawdzić za pomocą funkcji „zbadaj element”:

Aby pogodzić odpowiedni rozmiar na urządzeniach desktop wykorzystujących różnej wielkości i rozdzielczości monitory, należy użyć mechanizmu elastycznych zdjęć wykorzystując atrybut srcset z zapytaniami medialnymi:

<img width="486" height="300" src="obrazek-486x300.jpg" srcset="obrazek-486x300.jpg 486w, obrazek-809x500.jpg 809w, obrazek-971x600.jpg 971w, obrazek-1110x686.jpg 1110w" sizes="(max-width: 486px) 100vw, 486px">

Wiele profesjonalnych systemów CMS, optymalizuje w ten sposób zdjęcia automatycznie. O skuteczności działania tego mechanizmu decyduje zgodność konfiguracji rozmiarów w systemie CMS z aktualnie wykorzystywanym szablonem.

Użyj efektywnego kodowania obrazów

Na rozmiar grafiki wpływają też szczegółowe parametry kodowania. Kompresja JPEG o jakości 80% a 100% jest niemal niedostrzegalna dla przeciętnego człowieka a może znacznie obniżyć rozmiar plików.

Dobrze jest też wyrobić sobie intuicję kiedy stosować PNG a kiedy JPG, ponieważ w wielu sytuacjach to PNG zapewni lepszą jakość i mniejszy rozmiar pliku zaś w innych bardziej racjonalne będzie wykorzystanie formatu JPEG. Nie należy zapominać o formacie WebP, który stał się już niemal standardem optymalizacji grafik na stronach internetowych.

Czytaj więcej w obszernym artykule: optymalizacja obrazków, zdjęć, grafik dla stron internetowych.

Elementy graficzne nie mają bezpośrednio określonych atrybutów width ani height

Kiedy przeglądarka zczytuje kod HTML stara się jak najszybciej zaprezentować zawartość strony internetowej. Problem polega na tym, że pobierając obrazek znajdujący się przed treścią nie jest w stanie określić ile będzie on zajmował. Problem jest spotęgowany na stronach, w których korzystamy z technik lazy-load opisywanych w punkcie wyżej. Zdjęcie lub grafika dopiero po załadowaniu do przeglądarki wypełnia dostępne pole a elementy położone niżej – których położenie na osi Y jest zdeterminowane przez wysokość obrazka przyjmują właściwą pozycję.

PageSpeed wykrywa czy obrazki mają określone width i/lub height. Jest to bardzo istotny element optymalizacji, którego spełnienie zmniejsza przewidziane przesunięcia układu i poprawia parametr CLS. Dlaczego to jest takie ważne? Dzięki temu przeglądarka wie gdzie zostanie za chwilę wpisany plik graficzny i przestaje to być problemem bo nie dochodzi do przesunięć.

Unikaj wyświetlania starszych skryptów JavaScript w nowoczesnych przeglądarkach

Tworzenie nowych funkcjonalności w ciągle rozwijanym języku JavaScript było kiedyś źródłem dylematu dla programisty – czy wykorzystywać nowe funkcje i ryzykować wystąpienie potencjalnych problemów w starszych przeglądarkach czy opierać swój kod na starszych instrukcjach wymagających jednak dopisania dodatkowych linii kodu. Z czasem opracowano trzecią drogę: wykorzystanie obejść (ang. shim) lub tzw. Polyfill – czyli kodu lub bibliotek dodających wsteczną kompatybilności dla starszych przeglądarek.

Rozwój Internetu i postęp w implementacji przeglądarek spowodował jednak, że coraz rzadziej mamy do czynienia z tzw. „starszymi przeglądarkami” a interpretacja kodu JavaScript w IE, Google Chrome, Firefox czy Safari nie jest już tak problematyczna jak kilka lat temu. Dlatego obecnie nie jest zalecane dodawanie shim i polyfill.

Ogranicz wpływ kodu spoza witryny

Kod spoza witryny to wszelkie zasoby ładowane z innych domen niż strona, która jest testowana. Kodem spoza witryny często są skrypty analityczne (takie jak Analytics.js, GoogleTagManager, FacebooPixel, HotJar), przyciski społecznościowe, fonty (np. w postaci plików woff2) oraz reklamy. Ich zamieszczenie jest w pełni kontrolowane i są dodawane bezpośrednio do kodu strony lub ładowanie odbywa się za pomocą elementu iframe.

Zasoby takie nie dość, że są problematyczne z punktu widzenia prywatności (i z tego powodu wymagają od nas informowania użytkowników o ich używaniu) potrafią znacznie spowolnić stronę internetową. Od strony deweloperskiej musimy sprawić aby nie blokowały renderowania.

Istnieje wiele technik dzięki którym możemy osiągnąć wymagane opóźnienie wiele z nich poruszono już w punktach dotyczących optymalizacji JavaScript. Najprostszym rozwiązaniem jest przeniesienie zasobów na własny dysk – można tak postąpić z fontami lub niektórymi skryptami np. analytics.js. Ponadto, możemy używać atrybutów defer i async w przypadku plików JavaScript. W niektórych przypadkach skutecznie pomaga funkcja setTimeout. Można też zwyczajnie usunąć integrację jeżeli nie niosą one szczególnej wartości do naszej strony. Jeżeli techniki te będą problematyczne do wykorzystania w ostateczności można wykorzystać <link rel=”preconnect”> oraz <link rel=”dns-prefetch”> aby przyspieszyć ładowanie zewnętrznych zasobów.

Użyj formatów wideo dla animacji

Format GIF, który w przeszłości służył do wstawiania na stronę animowanych obrazków nie jest tak efektywny jak nowoczesne formaty WebP i WebM. Wszelkie pliki w formacie GIF warto przerobić na animacje SVG a tam gdzie mamy do czynienia z krótkimi filmami wykorzystajmy przeznaczone do tego i zużywające dużo mniej transferu formaty wideo. Przewagą formatu wideo jest to, że aby odtworzyć jego początkowe sekundy nie musimy ładować całego pliku. Podczas ładowania możemy wykorzystać natywny statyczny placeholder, do którego link umieszczamy w atrybucie poster. W przypadku formatu GIF nie ma takiej możliwości i w ostateczności trzeba wykorzystać standardowy lazy-loading.

Automatyzacja prac deweloperskich

Część z tych prac można zautomatyzować stosując wtyczki i moduły do konkretnych systemów CMS. Istnieje oficjalny moduł PageSpeed autorstwa Google, który pozwala wykonać automatyczne prace niezależnie od wykorzystywanego CMSa. Minifikacja, ustawienie nagłówków, optymalizacja zdjęć a nawet optymalizacja plików JS i CSS jest możliwa na poziomie serwera. Czytaj więcej o module PageSpeed w specjalnym artykule, który zawiera testy i instrukcję instalacji.

Co utrudnia uzyskanie pełnego wyniku PageSpeed Insights?

• korzystanie z gotowych szablonów i ignorowanie prostych działań optymalizacyjnych przy tworzeniu strony, które z czasem się kumulują czyniąc optymalizację bardzo trudnym zadaniem.
• korzystanie z rozwiązań przeznaczonych dla potrzeb amatorów chcących tworzyć strony za pomocą kreatorów wizualnych, page builderów itp.
• stosowanie wielu web-fontów w dodatku z paroma wersjami grubości i niewykorzystywanymi zestawami znaków (np. wietnamski, cyrylica, alfabet grecki).
• stosowanie fontów ikonowych, podczas kiedy wykorzystujemy kilka znaczków, które spokojnie mogłyby być zastąpione wersjami inline SVG,
• nieprawidłowo dodane skrypty z zewnątrz i wtyczki dodające swój kod do nagłówka (Pixel Facebooka, Feed z Instagrama, dodatkowe skrypty do analizy i śledzenia, z których i tak nie korzystasz) LiveChat, Recaptcha, HotJar,
• nieprawidłowe dołączanie filmów YouTube za pomocą iframe,
• słaby (najczęściej krajowy) hosting typu „LiteSpeed”, w którym nie mamy możliwości instalacji modułów, dostosowania podstawowych ustawień, które są w standardowych hostingach Apache NGINX.
• błędny dobór rozwiązań optymalizacyjnych np. komplikowanie infrastruktury dodatkowymi węzłami w postaci Cloudflare, pamięci na zewnętrznym serwerze (memchached lub Redis), i innych tego typu rozwiązań, które nie są przeznaczone dla zwykłych stron internetowych.

Podsumowanie

Zdobycie 100 punktów w PageSpeed Insights daje pewność, że od strony deweloperskiej poczyniono wszystkie wysiłki aby strona działała szybko i była wygodna dla użytkowników. PSI to jeden z głównych wyznaczników jakości stron internetowych i źródło satysfakcji dla perfekcjonistów.

Zielony wynik w Page Speed Insights z pewnością zostanie doceniony przez klientów, dla których korzystanie ze strony będzie wygodne oraz przez algorytm wyszukiwarki, który wyświetli użytkownikom stronę w pewności, że po kliknięciu w link załaduje się ona szybko i prawidłowo.

Źródła

• https://developers.google.com/web/tools/lighthouse/audits/webp
• https://web.dev/vitals/