Czy PageSpeed Insights zawsze “mówi” prawdę?

PageSpeed Insights a rzeczywista szybkość strony

Jednym z większych problemów z narzędziem PageSpeed Insights jest odejmowanie zbyt wielu punktów, gdy cokolwiek na stronie wymaga, żeby przeglądarka pobrała z serwera duży plik, np. wysokiej jakości zdjęcie. Narzędzie to, chociaż nie informuje w wyraźny sposób o tym, na czas testu wersji mobilnej, ogranicza prędkość łącza internetowego do 1,6 Mbit/s. Więcej informacji można znaleźć tutaj:

– informacji, że PageSpeed Insights używa Lighthouse: 

– informacji, że Lighthouse używa takich parametrów

Z danych dostępnych w  Wikipedii jasno wynika, że większość użytkowników ma znacznie szybsze łącze internetowe niż ograniczenie w PageSpeed Insights. Jedynym wyjątkiem jest Paragwaj oraz Irak. W tych krajach średnia prędkość jest niższa lub równa średniej wartości wskazanej przez PageSpeed Insights. A jak to wygląda w naszym kraju? Średnia szybkość w Polsce, według danych z 2019 roku, jest prawie 11-krotnie wyższa, co oznacza że jeżeli PageSpeed Insights pokazuje, że np. mocniejsze skompresowanie jakiegoś zdjęcia spowoduje skrócenie czasu ładowania o 5 sekund, w rzeczywistości spowoduje skrócenie czasu o tylko 0,45 sekundy.   Co więcej – wiele stron ładuje się szybko, choć z raportu PageSpeed Insights wynika coś zupełnie przeciwnego. Dobrym tego przykładem jest witryna edition.cnn.com. Aktualny wynik to 2/100 w przypadku telefonu, 11/100 w przypadku komputera. Z czego mogą wynikać tego typu rozbieżności? Przede wszystkim, nawet jeśli najwolniejszy element, np.np. asynchroniczny skrypt marketingowy  długo się ładuje, użytkownik może już normalnie korzystać ze strony. Jedyna różnica to informacja na pasku u dołu strony. Tego aspektu PageSpeed Insights już niestety nie uwzględnia. 

Wpływ na pozycję w Google’u

Często właściciele sklepów poruszają temat wpływu wyniku PageSpeed Insights na pozycję strony w wynikach wyszukiwania. Warto w tym miejscu odwołać się do źródła, czyli Wskazówek dla webmasterów odnośnie szybkości strony jako jednego z czynników rankingowych Google, Informującego o wdrożeniu szybkości strony jako czynnika rankingowego w wersji mobilnej. Możemy przeczytąć tam, że  kwestia ta dotyczy tylko najwolniejszych stron („will only affect pages that deliver the slowest experience to users”), a nie większości i że wpływa tylko na niewielki procent wyszukiwań („will only affect a small percentage of queries”). Co więcej, gdy Google po raz pierwszy wprowadził uwzględnianie szybkości stron przy ustalaniu pozycj, wtedy jeszcze tylko dla stron desktopowych, w komunikacie widocznym na napisał, że czynnik ten ma mniejszy wpływ niż trafność strony („it doesn’t carry as much weight as the relevance of a page”) i że w momencie ogłoszenia tego dotyczył mniej niż 1% wyszukiwań („Currently, fewer than 1% of search queries are affected by the site speed signal”), co, jako że Google w 2018 roku dalej wspominał o obniżaniu pozycji tylko najwolniejszych stron, a nie ogólnym traktowaniu szybszych jak zawsze lepszych, może być dalej aktualne.

Google nigdy nie sprecyzował, w jaki sposób jego wyszukiwarka wylicza szybkość i wcale nie musi być to wynik PageSpeeda.   Z badań opisanych na jednym z popularniejszych blogów na temat SEO – moz.com wynika, że tam, gdzie szybkość ma znacznie, liczy się głównie czas odpowiedzi serwera („there is a correlation between lower time-to-first-byte (TTFB) metrics and higher search engine rankings”), zależny od parametrów sprzętowych serwera, jego obciążenia i optymalizacji backendu, a nie całkowity czas ładowania strony wraz ze skryptami, zdjęciami itp. („there is no correlation between „page load time” (either document complete or fully rendered) and ranking on Google’s search results page”), który badają narzędzia takie jak PageSpeed Insights i GTmetrix.

Częste problemy z konkretnymi sugestiami narzędzia Google’a

„Wyświetlaj obrazy w formatach nowej generacji”

Google proponuje, żeby trzymać na serwerze dwie wersje każdego zdjęcia – w normalnym formacie np. JPEG albo PNG i w formacie nowej generacji, np. WebP. A później, przy każdym wyświetleniu rozpoznawać przeglądarkę i w zależności od tego, czy obsługuje WebP wysyłać WebP albo zwykłe zdjęcie. Nie można tego  zrobić. Po  prostu zawsze wysyłany jest  WebP, bo Internet Explorer i Safari wcale nie obsługują tego formatu.

Wdrożenie tego dla samych zdjęć produktów wymagałoby w przeciętnym sklepie około 40 godzin pracy ze względu na konieczność przerobienia kodu backendowego związanego z generowaniem miniatur, jak i w przypadku wielu sklepów wszystkich miejsc w szablonie, w których jest widoczne zdjęcie. Dodatkowo, podwoiłoby to ilość miejsca na dysku potrzebną do przechowywania zdjęć, w tym miniatur.

Z każdym innym, niż zdjęcia produktów, rodzajem grafiki w sklepie problem jest taki sam lub jeszcze większy, bo obsługa innych standardowych zdjęć np. kategorii w PrestaShopie używa innego kodu.  Ponadto, większość modułów nie korzysta z wbudowanego w PrestaShopa mechanizmu generowania miniatur, tylko ma własny lub wcale ich nie generuje, tylko używa zawsze oryginalnych zdjęć, które administrator sklepu wrzucił. Konieczne byłoby przerabianie w odpowiedni sposób po kolei każdego modułu, jaki jest w sklepie i robi cokolwiek związanego z grafiką.

Jest inny, prostszy sposób na uzyskanie zdjęć w WebP.  Można zainstalowaći moduł mod_pagespeed geerującego te zdjęcia i przepisującego kod HTML automatycznie, ale trzeba pamiętać o tym, że: 

•  wymaga serwera dedykowanego lub VPS-a z dostępem do roota,
• może spowodować niekompatybilności z niektórymi szablonami – chociaż raczej rzadziej niż dostępne w PrestaShopie optymalizacje wydajności,
• zwiększa obciążenie serwera, zmniejszając liczbę żądań na sekundę, jakie ten może obsłużyć,
•  nie obsługuje zdjęć wstawianych JavaScriptem, jakie istnieją w np. niektórych modułach menu, pozostawia je bez optymalizacji.

Wpływ tej optymalizacji na prawdziwy czas ładowania strony jest raczej niski, ale PageSpeed Insights wyolbrzymia w tym przypadku znaczenie tej optymalizacji, ponieważ::

•  w wersji mobilnej sprawdza czas na słabym łączu, więcej o tym jest w początkowej części dokumentu,
• w wersji desktopowej nie uwzględnia faktu, że przeglądarki ładują zdjęcia asynchronicznie, nie blokując niczego innego na czas ich ładowania, więc nie jest prawdą że można używać strony dopiero po pełnym załadowaniu ostatniego ze zdjęć.  To, że przeglądarka jeszcze ładuje jakieś zdjęcia w dolnej części nie oznacza, że użytkownik nie może przeglądać górnej części strony, gdzie przeglądarka zdążyła już wszystko załadować.

„Użyj efektywnego kodowania obrazów”

Google proponuje, żeby skompresować grafikę nie tak, jak robią to popularne programy graficzne, w sposób optymalizujący przede wszystkim czas zapisywania. Chodzi o to, aby za wszelką cenę osiągnąć maksymalną kompresję. Służą do tego narzędzia konsolowe więc rozwiązuje to problem rzadko zmieniających się plików.  Dzięki temu możesz pobrać pliki z serwera, skompresować je i wrzucić na serwer. Problem w tym, że dużą część zdjęć, np. miniatury zdjęć produktów, PrestaShop generuje automatycznie, używając biblioteki GD. Biblioteka ta, podobnie jak wszystkie inne dostępne dla skryptów PHP, tworzy nieoptymalne pliki. Oznacza to, że  ręczna kompresja poza serwerem zdjęć miniatur wszystkich produktów nie ma większego sensu. Powód jes jeden – po wprowadzeniu zmian w back office PrestaShop wygeneruje nowe, nieoptymalne miniatury, które zastąpią wcześniej ręcznie wrzucone optymalne. Teoretycznie,można wykorzystać do tego dedykowany moduł, np. Image Compressor With TinyPNG, ale:

• w ostatnich latach nikt z nas ich nie używał, więc trudno powiedzieć jak wygląda sytuacja z np. kompatybilnością,
•  używają zewnętrznych usług kompresujących grafikę, które mają limit zdjęć, powyżej którego korzystanie z nich staje się płatne,
• w związku z używaniem zewnętrznych usług internetowych jeżeli kompresują od razu, a nie okresowo w tle, mogą mieć negatywny wpływ na czas dodawania np. importerem większej liczby produktów.

Gdy na serwerze jest dostęp do SSH, powinna istnieć  możliwość instalacji odpowiednich narzędzi i napisania skryptów shellowych okresowo automatycznie kompresujących to, co trzeba, ale to także wymaga większej ilości pracy.

W większości przypadków wpływ tej optymalizacji na realny czas działania strony jest dość niski, dodatkowo narzędzie Google’a trochę (a w wersji mobilnej bardzo) zawyża w raporcie znaczenie tej optymalizacji.  Podobnie jak w przypadku punktu „wyświetlaj obrazy w formatach nowej generacji”.

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

W większości sklepów nie ma problemu z wdrożeniem, pomijając zewnętrzne skrypty np. Facebooka, ale gdy serwer ze sklepem jest za reverse proxy, pojawia się problem uniemożliwiający dodanie nagłówków Expires. Na stronie w niektórych przypadkach może być widoczna, pochodząca z proxy, nieaktualna zawartość, bez żadnej możliwości odświeżenia. Przykładowo, mamy  jedno zdjęcie kategorii, które użytkownicy już widzieli. znajduje się ono w cache’u przeglądarek i w cache’u reverse proxy, administrator sklepu zmienia to zdjęcie na inne, ale po stronie front office’u widać cały czas złe pochodzące z cache’u, normalnie pomogłoby odświeżenie, bo stara wersja byłaby tylko w cache’u przeglądarki, ale większość reverse proxy nie odświeża zawartości w momencie użycia przycisku Odśwież w przeglądarce, tylko po pewnym dłuższym czasie, w wyniku czego przez ten czas na stronie byłoby widoczne nieaktualne zdjęcie, bez możliwości odświeżenia bez kontaktu z administratorem reverse proxy, który prawdopodobnie ma możliwość ręcznego opróżnienia cache’u.

Tutaj wpływ w przypadku użytkowników, którzy wchodzą na stronę po raz pierwszy jest zerowy.  A w przypadku powracających może być względnie duży. Dotyczy to sytuacji, w której dodanie nagłówków cache’u nie jest bezpieczne.  Nie można ich po prostu dodać, bo spowodowałoby to utratę możliwości wprowadzania zmian na stronie bez długiego oczekiwania po wprowadzeniu każdej z nich. Można najwyżej ręcznie dodać w .htaccess nagłówki do tego, o czym wiadomo że się nie zmieni, czyli głównie zdjęć produktów. Tych nie można wyedytować pozostawiając stary adres. Edycja zawsze powoduje zmianę adresu, przez co nie ma ryzyka wystąpienia sytuacji z zapisaniem w cache’u na stałe czegoś nieaktualnego.

„Unikaj bardzo dużych ładunków sieciowych”

W tym punkcie Google prawie zawsze proponuje zrobienie czegoś z rozmiarem zdjęć albo JavaScriptu. Przeważnie zdjęć nie można już bardziej zmniejszyć bez pogarszania ich jakości.  Jeżeli mają złe rozmiary lub problemy z kompresją, Istnieją osobne punkty w narzędziu, które dotyczą tej kwstii. Podobnie sprawa wygląda w przypadku JavaScriptu, nie można znacznie zmniejszyć  zdjęć, bez usuwania funkcji ze sklepu.

„Unikaj zbyt dużego DOM”. „Zminimalizuj aktywność głównego wątku”. 

 W wersji mobilnej komunikat ten, często półączony jest z innym: „Skróć czas wykonywania JavaScriptu”. Rozwiązanie tego problemu prawie zawsze wymaga uproszczenia strony. Pozbycia się wszelkiego rodzaju sliderów, skomplikowanych warstw wyświetlanych po najechaniu kursorem na element itp. Nie ma tu za bardzo możliwych optymalizacji innych niż uproszczenie strony.

„Wyeliminuj zasoby blokujące renderowanie”

Jeden z zasobów blokujących renderowanie, arkusz CSS, jest w PrestaShopie prawie niemożliwy do wyeliminowania. Google oczekuje,że CSS zostanie podzielony na część krytyczną, tzn. dotyczącą górnej części strony i niekrytyczną orazcałą resztę.  A następnie,  będzie ładować te części w różnych momentach. Trzeba jednak wziąć pod uwagę że w przypadku domyślnego szablonu (i każdego innego) wszystko jest ze sobą “wymieszane”, że wdrożenie tej małej optymalizacji wymagałoby stworzenia szablonu od nowa. Oprócz tego, z dużym prawdopodobieństwem trzeba byłoby zablokować modułom możliwość dołączania własnego kodu CSS i stworzyć szablon, który będzie działał tylko z kilkoma wybranymi podczas jego tworzenia modułami.

Wpływ blokującego CSS-a jest prawie zawsze bardzo niski, np. 0,05 sekundy.  Większym problemem jest blokujący JavaScript, ale można go często przenieść do dolnej części kodu, aby tego uniknąć. Oczywiście po przetestowaniu kompatybilności takiej konfiguracji ze wszystkim używanym na stronie. Raczej rzadko zdarza się, żeby blokujący JS musiał pozostać na górze, w przeciwieństwie do CSS-a.

„Zmień rozmiar obrazów”

W większości sklepów nie ma szczególnych problemów z wdrożeniem tej sugestii, ale w niektórych znajdują się zdjęcia pełnoekranowe, o szerokości dostosowującej się do ekranu użytkownika. A to oznacza, że pliki graficzne muszą być wielkie. Ich zmniejszenie tak, jak proponuje Google, spowodowałoby, że na 1366-pikselowym ekranie, na którym Google testuje stronę faktycznie nie byłoby utraty jakości. Niestety, w przypadku większego ekranu nastąpi utrata jakości, czego Google już  nie uwzględnił. 

„Odłóż ładowanie obrazów poza ekranem”

Google proponuje ładowanie zdjęć dopiero wtedy, gdy pasek przewijania będzie w takiej pozycji, że powinny stać się widoczne, tzw. lazy loading. Początkowo należy wyświetlać coś innego, np. symbol ładowania, w ostateczności białą przestrzeń odpowiedniego rozmiaru.  A następnie, trzeba wykryć że stało się to widoczne i rozpocząć ładowanie zdjęcia, zastępując początkowy element zdjęciem. Element zastępujący zdjęcie powinien mieć takie same rozmiary jak ładujące się później zdjęcie. Chodzi o to, żeby nie występowała sytuacja, w której pozycja paska przewijania sama się zmienia w niewłaściwy sposób w momencie pokazania zdjęcia. Zagwarantowanie tego w przypadku większości szablonów, w połączeniu z responsywnością, z powodu ograniczeń CSS-a związanych z zachowywaniem współczynników proporcji jest dość trudne i wymaga przerabiania kodu każdego bloku, w którym trzeba taki mechanizm zaimplementować.  Wynika to z responsywności oraz z ograniczeń samego CSS-a i związanym z tym zachowywaniem współczynnikiem proporcji. Dla list produktów na stronach kategorii i podobnych do niej np. stronach producentów, czas wdrożenia zmian był do tej pory w różnych sklepach wynosił średnio 5-7 godzin.

Dodatkowo, gdy obrazy te są częścią slidera, trzeba wdrożyć kod ukrywający cały slider do momentu  gdy faktycznie powinien się wyświetlić. To  stanowi dodatkową trudnosć. A w przypadku niektórych bibliotek do obsługi sliderów, może być nawet niemożliwe bez przepisywania całego slidera tak, aby używał innej biblioteki.Takietrudności pojawiają się przy wdrażaniu lazy loadingu pojedynczych zdjęć. W szczególności problem ten dotyczy ustaleniem wysokości zdjęcia przed jego pobraniem i dodatkowo – z bibliotekami JS sliderów.

Ponieważ przeglądarka i tak ładuje zdjęcia asynchronicznie, ładowanie ws2zystkich od razu nie ma raczej szczególnie negatywnego wpływu na szybkość, którą odczuwa użytkownik. W przypadku powolnego łącza lazy loading może natomiast  jeszcze  bardziej wydłużyć czas potrzebny na załadowanie się zdjęcia podczas przewijania strony. Bez lazy loadingu przeglądarka mogłaby załadować zdnięcia, zanim użytkownik rozpoczął przewijanie, więc nie zawsze lazy loading jest korzystny z punktu widzenia szybkości. Za to lazy loading bardzo zmniejsza transfer sieciowy, co może być istotne w przypadku użytkowników telefonów niepodłączonych do Wi-Fi lub gdy ruch sieciowy wychodzący z serwera jest drogi.

„Usuń nieużywany kod CSS”

Jeżeli Google pokazuje tutaj faktycznie nieużywany kod, zazwyczaj jest to kod Bootstrapa lub innej popularnej biblioteki CSS, z której korzysta PrestaShop  Usuwanie czegokolwiek w takiej sytuacji jest raczej złym pomysłem. Powód jest prosty. Stwierdzenie, jakie elementy można bezpiecznie wymagałoby ogromnej ilości pracy. Chociażby ze względu na doinstalowanie pewnych elementów w przeszłości. Przykładowo, moduł może potrzebować tego usuniętego kodu CSS. Moduły raczej przyjmują założenie, że w sklepie jest dostępny cały Bootstrap, a nie tylko jego fragmenty.

W większości przypadków jakiś element w sklepie internetowym  stosuje kod, który wg Google’a jest nieużywany. Wynika to z faktu, że znajduje się on na innej niż aktualnie badana podstronie lub pojawia się po jakimś zdarzeniu, np. najechaniu kursorem lub kliknięciu.

Przy pisaniu czegoś od zera, nie na PrestaShopie czy innym gotowym skrypcie, można byłoby osobno stworzyć CSS dotyczący wspólnych części,  takich jak nagłówek, stopka, konfiguracja marginesów, czcionek itp. A także CSS dotyczący elementów konkretnych podstron. A następnie ładować na każdej dwa pliki – wspólny i dotyczący aktualnie widocznej podstrony. W przypadku elementów widocznych nie od razu, tylko po zdarzeniu. Poza tym myślę, że aktualne zachowanie jest optymalne, nawet jeżeli automatyczne narzędzie twierdzi inaczej.  Użytkownik raczej chce widzieć zawartość menu od razu po jego rozwinięciu, a nie czekać na doładowanie plików CSS, graficznych i innych opisujących zawartość menu, kiedy doładowywanie rozpocznie się dopiero po rozwinięciu.

Sytuacja tutaj jest podobna jak w punkcie „Wyeliminuj zasoby blokujące renderowanie”. W PrestaShopie bez wprowadzania ogromnych zmian architekturalnych nie ma za barzdo możliwości rozdzielania kodu CSS na wiele części ze względu na cokolwiek, np. ładowaną przed wyświetleniem treści część krytyczną i ładowaną po wyświetleniu treści część niekrytyczną, część wspólną i dotyczącą konkretnej podstrony czy wydzielenia stylów rozwiniętych elementów np. mega menu, co byłoby konieczne żeby spełnić wymagania PageSpeed Insights.

Bardzo rzadko zdarza się, żeby kod CSS szablonu był tak skomplikowany, żeby wpływ tych trudnych do wdrożenia optymalizacji na czas ładowania strony był na poziomie przekraczającym 0,2 sekundy.

„Zapewnij widoczność tekstu podczas ładowania czcionek internetowych”

Tę wskazówkę warto wdrożyć i w przypadku prawdziwych czcionek, faktycznie gra jest warta świeczki. Jednak w przypadku fontów, które zawierają np.  wektorowe ikony zamiast liter, takich jak Font Awesome, nie warto tego robić. Moim zdaniem, lepiej nic nie widzieć  i w pewnym momencie zobaczyć ikonę niż widzieć na początku symbol nieznalezienia znaku (bo żadna czcionka systemowa nie zawiera ikony), który w pewnym momencie staje się ikoną.

Skrypty marketingowe/śledzące i inne zewnętrzne

Różnego rodzaju zewnętrzne skrypty często używają nieoptymalnych ustawień cache’u, pobierają duże pliki, obciążają w znacznym stopniu procesor i w inny sposób negatywnie wpływają na działanie strony. Rozwiązanie problemów w sposób inny niż usunięcie jest w większosci przypadków niemożliwe. Najczęściej też nie da się wskazać kilku, które przeszkadzałyby najbardziej, bo w większości przypadków jest ich np. 10, z czego każdy pojedynczo generuje względnie małe obciążenie, ale wszystkie razem wzięte już duże, gdzie każdy z nich ma mniej więcej równy udział w obciążeniu.