100 punktów w PageSpeed: co dokładnie zmieniliśmy

Wartość wyjściowa to 58 na 100 na telefonie. To nie jest zła wartość dla strony z efektem 3D w nagłówku, ale wartość, którą Google w wyszukiwaniu mobilnym odczuwalnie karze. Na końcu stanęło 100 punktów na komputerze i 98 na telefonie, przy również 100 za dostępność.

To, co następuje, nie jest ogólną listą kontrolną, lecz faktycznym przebiegiem – łącznie z miejscami, w których się pomyliliśmy.

Punkt wyjścia

Pięć zmian, które naprawdę się liczyły

1. Zastąpić bibliotekę, a nie ją optymalizować

Nagłówek pokazuje chmurę cząstek w 3D. Działała na niej znana biblioteka graficzna – 458 KB po zmniejszeniu. Pomiar wykazał, że 51 KB z tego nigdy w ogóle nie zostało wykonane.

Rozstrzygające było pytanie, ile faktycznie potrzebujemy. Okazało się, że jedenaście elementów: renderer, scena, kamera, geometria, materiał i kilka klas pomocniczych. Wszystko to da się zaprogramować bezpośrednio wobec interfejsu graficznego przeglądarki.

Wynik: z 458 KB zrobiło się 6 KB. Wygląd jest identyczny – przejęliśmy te same shadery.

2. Kompresja była włączona tylko w połowie

W konfiguracji serwera kompresja stała na „włączona” – ale wiersz określający, które typy plików mają być kompresowane, był zakomentowany. To domyślne ustawienie wielu dystrybucji. Skutek: kompresowany był wyłącznie HTML.

Biblioteka graficzna szła więc przez łącze nieskompresowana. Po włączeniu: z 1243 KB zrobiło się 251 KB. Dodatkowo trzymamy teraz obok wersje skompresowane wstępnie, żeby serwer nie liczył od nowa przy każdym wywołaniu.

Nakład: dwa wiersze konfiguracji. Efekt: blisko megabajt na każde pierwsze wywołanie.

3. Usunąć całkowicie bibliotekę animacji

Do wyłaniania się elementów przy przewijaniu działała kolejna biblioteka, 114 KB. Pomiar wskazał ją dodatkowo jako sprawczynię wymuszonych przeliczeń układu – w trakcie przewijania odpytywała geometrię i zmuszała przeglądarkę do przeliczania układu w środku ruchu.

Zastąpiona przez IntersectionObserver, który jedynie ustawia klasę. Właściwy ruch robi CSS. 114 KB mniej, żadnych przeliczeń, około 40 wierszy własnego kodu.

4. Favicon ważył 205 KB

Drobiazg o zaskakującym efekcie, bo ładowany jest bardzo wcześnie. Zastąpiony plikiem SVG o wadze 6 KB, wygenerowanym z istniejącego logo.

5. Odpytywać geometrię w klatce animacji

Pewien skrypt odczytywał przy każdym zdarzeniu przewijania całkowitą wysokość dokumentu. Tej właściwości przeglądarka nie może podać z pamięci – musi w tym celu przeliczyć od nowa układ całej strony, w środku przewijania.

Wynikająca z tego reguła, obowiązująca wszędzie: czytać w zdarzeniu, zapisywać w kolejnej klatce. Nigdy odwrotnie. Od tej pory wysokość strony jest mierzona raz i zapamiętywana, zamiast być odpytywana sześćdziesiąt razy na sekundę.

Błąd, który kosztował 24 punkty

Co dało mało

Dla porządku działania, które stoją w każdym poradniku, a u nas były ledwie mierzalne:

Formaty obrazów. Nasza strona główna prawie nie ma obrazów – logo jest plikiem SVG. Tam, gdzie obrazy występują, przekształcenie oczywiście się opłaca; jako główna dźwignia nadaje się tylko na stronach obciążonych grafiką.

Dalsze zmniejszanie krojów pisma. Hostujemy dwie rodziny krojów samodzielnie i wczytujemy z wyprzedzeniem te potrzebne w widocznym obszarze. Dalsza optymalizacja byłaby możliwa, ale nie rusza wyniku.

Lokalizacja serwera. Wielokrotnie zalecana, w naszym przypadku bez znaczenia: czas do pierwszego bajtu wynosił już 20 milisekund. Kto stoi tam dobrze, nie zyska nic na sieci dystrybucyjnej.

Postępowanie do powtórzenia

1. Zmierzyć, zanim cokolwiek się zmieni. Osobno mobilnie i na komputerze, wartości zanotować.
2. Poszukać największego przesyłanego pliku. Prawie zawsze jest to JavaScript. Pytanie nie brzmi, jak go zmniejszyć, tylko czy jest potrzebny.
3. Sprawdzić kompresję. Nie czy jest włączona, lecz dla jakich typów plików.
4. Policzyć zapytania blokujące. Każdy plik arkusza stylów w nagłówku wstrzymuje pierwsze wyrysowanie.
5. Sprawdzić skoki układu bez spowolnienia. Ten jeden test, którego nam brakowało.
6. Po każdej zmianie mierzyć od nowa. Inaczej na końcu nie wiadomo, co zadziałało.

Pomóż mi przełożyć raport PageSpeed mojej strony na kolejność
działań. Bądź surowy; niczego nie chwal.

Moje wartości:
- Mobilnie: [wynik], komputer: [wynik]
- LCP, TBT, CLS dla każdego urządzenia: [wartości]
- Największe przesyłane pliki wraz z rozmiarem: [lista]
- Zapytania blokujące renderowanie: [lista]
- Komunikaty z raportu: [wklej tekst]

O stronie:
- Jak jest zbudowana: [CMS / statycznie / kreator]
- Czy JavaScript jest potrzebny do widocznej treści? [tak/nie]
- Jak dostarczany jest CSS? [zewnętrznie / wbudowany /
  częściowo wbudowany]

Zadania:
1. Przypisz każdy komunikat do przyczyny i powiedz, na który
   wskaźnik wpływa – LCP, TBT czy CLS.
2. Uszereguj działania według efektu na jednostkę nakładu. Przy
   każdym podaj, ile punktów realistycznie rusza i dlaczego.
3. Wskaż działania z raportu, które przy mojej budowie nie dadzą
   praktycznie nic – i uzasadnij to, zamiast je po prostu
   pomijać.
4. Przy każdym dużym pliku JavaScript zapytaj najpierw, czy jest
   potrzebny, zanim zaproponujesz zmniejszanie.
5. Zwróć uwagę, jeśli CSS jest wbudowany tylko częściowo, i
   wyjaśnij, dlaczego dla CLS może to być gorsze niż
   niewbudowanie go wcale.
6. Podaj, co powinnam mierzyć od nowa po każdej zmianie.

Nie wymyślaj wartości pomiarowych.

Podsumowanie

Sam wynik punktowy nie jest celem – jest wartością pomiarową, nie wynikiem biznesowym. Liczy się doświadczenie za nim: strona czytelna po 1,4 sekundy jest czytana przez więcej osób niż taka, która potrzebuje sześciu. U odwiedzających mobilnie przez sieć komórkową różnica jest większa niż jakakolwiek optymalizacja tekstu.

Droga do tego wiodła w naszym przypadku przez jedno powtarzające się pytanie: czy tego potrzebujemy? Pięć z sześciu zmian polegało na usunięciu czegoś, nie na dodaniu.

Częste pytania