PageSpeed

Google PageSpeed, czyli dlaczego Twoja strona działa jak pecet z epoki modemu 56k

Twoja prędkość strony jest kluczowym elementem, który decyduje o jej sukcesie w wyszukiwarkach i zadowoleniu użytkowników. Jeśli zastanawiasz się, dlaczego witryna działa wolno, ten tekst jest dla Ciebie. Zanim zanurkujemy w techniczne aspekty optymalizacji, wyjaśnijmy, czym jest Google PageSpeed – paczka narzędzi od Google, która od 2010 roku pomaga walczyć z „zamulaniem” witryn. Zróbmy szybki `git blame` i zobaczmy, dlaczego ten temat jest tak krytyczny.

Czym jest prędkość strony i szybkość ładowania?

Wyobraź sobie, że użytkownik klika link do Twojej strony. W tym momencie jego przeglądarka wysyła request GET /. Szybkość ładowania to, mówiąc po naszemu, latency – czas od wysłania tego requesta do momentu, aż przeglądarka wyrenderuje cały ten bajzel i user może wreszcie coś kliknąć. Im krótszy ten czas, tym mniejsza szansa, że użytkownik dostanie timeoutu cierpliwości i zamknie taba w cholerę. W dzisiejszych czasach, jeśli Twoja strona nie odpowiada z prędkością światła, to dla usera jesteś jak serwer, który nie odpowiada na ping.

Google w roli admina sieci, czyli jak prędkość strony stała się featurem

Już w 2010 roku spece z Google’a zorientowali się, że userzy nie lubią czekać. Szok, prawda? Zrobili badania (pewnie grepowali logi na potęgę) i wyszło im, że ze stron-ślimaków ludzie uciekają szybciej niż juniorzy na widok zadania z wyrażeniami regularnymi. Wtedy ktoś mądry wpadł na pomysł: „Hej, a może by tak włączyć TTFB (Time To First Byte) do naszego algorytmu sortującego?”. I tak się stało. Prędkość stała się jednym z czynników rankingowych.

Oczywiście, od razu zaznaczyli, że to nie jest najważniejszy commit w historii. Content nadal jest królem, jak root na serwerze. Dobry, merytoryczny tekst zawsze będzie miał wyższy priorytet niż szybka strona z bzdurami. Ale tu jest haczyk: jeśli dwie strony mają równie genialny content, to Google spojrzy na ich wydajność. I ta szybsza, jak kod zoptymalizowany pod O(log n), wygra z tą, która działa w O(n²). Proste.

Pamiętaj też, że nie wszystko jest Twoim bugiem. Na prędkość wpływają też czynniki, na które masz wpływ jak na pogodę – sprzęt usera (może odpala Twoją stronę na smart-tosterze) albo jego sieć z epoki GPRS. To zmienne środowiskowe, których nie zmockujesz. Mimo to, jeśli Twoja strona laguje, pierwsza zasada helpdesku brzmi: „zakładaj, że wina leży po Twojej stronie”. Zanim zaczniesz obwiniać end-usera, zrób porządny audyt SEO własnego backendu i frontendu.

Dlaczego masz się tym przejmować? Bo hajs się musi zgadzać

Google, w przypływie łaski, podzieliło się metrykami. Okazuje się, że wydłużenie czasu ładowania z 1 do 3 sekund podnosi współczynnik odrzuceń (nasz kochany bounce rate) o 32%. W praktyce oznacza to, że co trzeci potencjalny klient zamyka Twoją stronę, zanim zdąży ona w ogóle załadować cookie banner. To jakbyś miał dziurawy firewall, który odrzuca 32% legalnego ruchu.

Wniosek jest prosty: optymalizacja prędkości to nie jest fanaberia dla performance geeków. To twardy biznes. Zadowolony user, któremu strona śmiga, to jedno. Ale boty Google’a, które dzięki temu dają Ci wyższą pozycję, to drugie. Jedno napędza drugie w pętli while (true). Badania mówią, że prawie 70% ludzi przyznaje, że prędkość strony wpływa na ich chęć zakupu. Serio, jeśli Twój e-commerce ładuje się wolniej niż kompiluje się kernel Linuxa, to nie dziw się, że konwersja leży. Zwłaszcza na mobile’u.

A propos mobile’u – żyjemy w erze Mobile-First Indexing. Oznacza to, że dla Google’a Twoja strona wygląda tak, jak widzi ją crawler mobilny. Desktop to teraz legacy view. Jeśli Twoja mobilna wersja to okrojony, niedziałający potworek, to właśnie tak widzi Cię cały świat (a przynajmniej najważniejszy bot na świecie). Chcesz być wysoko w Google i sprzedawać? Twoja strona na telefonie ma działać jak demon, a nie jak aplikacja napisana w Javie na starym Androidzie.

Prędkość strony a SEO – nierozłączny pull request

To już chyba jasne: prędkość strony to twardy czynnik rankingowy. Ale wpływa na SEO też w sposób bardziej podstępny, pośredni. Wolna strona = wysoki bounce rate = krótki czas sesji. Dla Google’a to sygnał, że Twoja strona jest bezużyteczna. To jak health check, który ciągle zwraca 503 Service Unavailable. Algorytm stwierdza: „ten serwis jest niestabilny, nie będę go polecał”.

W tym miejscu wchodzi całe to modne User Experience (UX). Wolna strona to po prostu gówniane UX. To jak interfejs, w którym przycisk reaguje po trzech sekundach. Użytkownik zaczyna go klikać jak szalony, wysyłając serię POST requestów i potencjalnie psując sobie sesję. Frustracja rośnie, user ucieka, a Google to notuje. Optymalizując prędkość, tak naprawdę debugujesz doświadczenia użytkownika.

Jaka prędkość strony jest optymalna?

Każda milisekunda jest na wagę złota. Tu nie ma miejsca na garbage collector. Ogólna zasada: strona powinna ładować się poniżej 3 sekund. Wszystko powyżej to proszenie się o kłopoty i rosnący bounce rate. Chcesz być w topce? Badania Backlinko pokazały, że średnia dla pierwszej strony wyników to 1,65 sekundy. To jest Twój benchmark.

Główne bugi spowalniające Twoją stronę – lista wstydu

Okej, czas na przegląd kodu. Co najczęściej psuje wydajność?

• Serwer (czyt. Twój hosting): Jeśli trzymasz stronę na tanim shared hostingu, to jakbyś odpalał produkcyjną bazę danych na Raspberry Pi, które w tle kopie kryptowaluty. Serwer musi odpowiadać szybko. Jego czas reakcji to fundament. Jeśli on muli, to żadne czary na frontendzie nie pomogą.
• Grafiki (nieskompresowane potwory w PNG): To klasyk. Marketing wrzucił zdjęcie w rozdzielczości 4K ważące 10 MB jako tło. Każdy taki plik to gigantyczny payload do pobrania. Optymalizuj obrazy! Kompresuj, skaluj do rozmiaru, w jakim są wyświetlane, i używaj nowoczesnych formatów jak WebP.
• Przeładowany frontend: Strona zawalona setką widgetów, animacji i skryptów śledzących. Każdy element to dodatkowy request HTTP. Przeglądarka musi to wszystko pobrać i wyrenderować. Czasem mniej znaczy szybciej. Zasada KISS (Keep It Simple, Stupid) wciąż działa.
• JavaScript (główny podejrzany): O, stary, tu można książkę napisać. Zbyt dużo JS-a blokuje główny wątek przeglądarki. Strona wygląda na załadowaną, ale jest zamrożona, bo w tle mieli się jakiś framework.
  • Koszt sieci: Wysyłanie gigantycznego bundle.js z bibliotekami, z których używasz 10%.
  • Koszt parsowania i kompilacji: Przeglądarka musi przemielić ten kod, zanim cokolwiek zrobi. Im więcej, tym dłużej.
  • Koszt wykonania: Skrypty wykonujące się w pętli i blokujące UI.
  • Koszt pamięci: Memory leaki w SPA, które po 5 minutach zjadają całego RAM-a i crashują kartę.

  Co z tym zrobić? Używaj code splittingu (wysyłaj tylko kod potrzebny na danym widoku), minifikuj i kompresuj kod, rób tree-shaking (wywalaj nieużywane funkcje) i cache’uj co się da.

• CSS (blokujący renderowanie): Przeglądarka domyślnie nie wyświetli nic, dopóki nie pobierze i nie przetworzy wszystkich plików CSS zadeklarowanych w <head>. Jeśli masz tam megabajty stylów, user będzie gapił się na biały ekran. Krytyczny CSS (dla above the fold) powinien być inline, reszta ładowana asynchronicznie.
• Brak cache’owania: To jak kompilowanie całego projektu od zera przy każdej zmianie jednej linijki kodu. Skonfiguruj cache na serwerze i w przeglądarce. Przy kolejnej wizycie user pobierze zasoby z lokalnego dysku, a nie będzie Ci znowu męczył serwera.
• Brak CDN (Content Delivery Network): Jeśli masz użytkowników z całego świata, a serwer w jednym Pcimiu Dolnym, to latency dla kogoś z Australii będzie kosmiczne. CDN to sieć serwerów proxy, która serwuje Twoje pliki z lokalizacji najbliższej userowi. Must-have.

Narzędzia do diagnozy, czyli Twój nowy ulubiony debugger

Skoro już wiesz, jak bardzo Twój kod może być zepsuty, czas go sprofilować. W sieci jest pełno darmowych narzędzi, które prześwietlą Twoją stronę i wyplują listę problemów, często z linkami do dokumentacji, jak je naprawić. To takie automatyczne code review dla wydajności. Użyj ich, zanim wkurzony klient założy Ci ticketa w Jirze z priorytetem „Highest”.

W następnych rozdziałach pewnie omówimy te narzędzia bardziej szczegółowo. Na razie masz listę potencjalnych bugów do naprawienia. Do roboty!