Szybka strona na telefonie: jak podniosłem wynik z 61 do 93

Projektuję szybkie strony, więc wypadałoby, żeby moja własna była szybka. Tymczasem pomiar w Google PageSpeed Insights pokazał na telefonie 61–70 punktów, a główna treść pojawiała się dopiero po 5,8 sekundy. Na komputerze było dobrze, ale większość ludzi wchodzi na strony z telefonu.

Poniżej opisuję, co dokładnie spowalniało stronę i jak to naprawiłem. Problemy, które znalazłem, występują na bardzo wielu stronach firmowych, także tych zbudowanych na WordPressie.

Wynik: przed i po

Na komputerze strona ma teraz 100 punktów. Wszystko bez usuwania animacji i bez rezygnowania z interaktywnego edytora na górze strony.

Krok 0: zmierz, zanim zaczniesz poprawiać

PageSpeed Insights symuluje średniej klasy telefon z wolnym internetem mobilnym. To dobre przybliżenie, ale sama liczba punktów niewiele mówi. Kluczowe jest pytanie: który element Google uznaje za główną treść i dlaczego pojawia się tak późno?

Odpowiedź mnie zaskoczyła. Google nie mierzył nagłówka strony, tylko zdjęcie w demonstracji edytora, które pokazywało się po około 6 sekundach. Plik pobierał się błyskawicznie, ale animacja budowania strony odsłaniała go dopiero po dłuższej chwili. Bez szczegółowego pomiaru szukałbym problemu w zupełnie innym miejscu.

1. Animacja, która opóźniała główną treść

Google za główną treść (LCP) uznaje największy element widoczny na ekranie. Jeśli coś dużego pojawia się późno, choćby w ramach efektownej animacji, cały wynik spada.

Na mojej stronie złożyły się na to dwie rzeczy:

• Demo budowania strony ruszało za wcześnie. Na telefonie zaczynało się, gdy 75% edytora było jeszcze pod ekranem. Teraz startuje, gdy edytor wjedzie mniej więcej do połowy ekranu. To lepsze także dla odwiedzającego, bo widzi całe budowanie, a nie jego końcówkę.
• Nagłówek był dla Google kilkoma małymi kawałkami. Każda linia nagłówka była osobnym blokiem, a animacja dzieliła go dodatkowo na pojedyncze słowa. Dla Google to kilkanaście małych elementów zamiast jednego dużego. Po zmianie nagłówek jest jednym blokiem tekstu i liczy się od pierwszej chwili.

Przeniosłem też animację wejścia z JavaScriptu do CSS. Wcześniej treść pojawiała się, znikała po załadowaniu skryptów i wjeżdżała ponownie. Teraz animacja rusza razem z pierwszym wyświetleniem strony, a nagłówek się wyostrza zamiast pojawiać z przezroczystości.

2. Przeskakiwanie przy wczytywaniu czcionek

Strona używa dwóch czcionek: bezszeryfowej Geist i ozdobnej kursywy Cormorant. Zanim się pobiorą, przeglądarka pokazuje tekst czcionką zastępczą, np. Arialem. Kursywa zastępcza była o 17% szersza od właściwej, więc nagłówek łamał się inaczej, a po podmianie czcionki cała treść pod nim podskakiwała.

Rozwiązanie to czcionki zastępcze z dopasowanymi wymiarami. CSS pozwala przeskalować Ariala i Times New Roman tak, żeby zajmowały tyle samo miejsca co właściwe czcionki (właściwości size-adjust, ascent-override i descent-override). Zmierzyłem obie czcionki i różnica szerokości spadła z 17% do 2%. Przeskakiwanie układu spadło do zera.

3. Za dużo plików blokujących wyświetlenie

Zanim przeglądarka pokaże cokolwiek, musi pobrać wszystkie arkusze stylów z nagłówka strony. U mnie było ich pięć: style strony, czcionki, dwa zestawy ikon i style płynnego przewijania. Na wolnym internecie każdy plik to osobne opóźnienie.

Poprawki:

• Jeden plik CSS zamiast pięciu. Łączenie dzieje się automatycznie przy publikacji strony, a w kodzie źródłowym pliki dalej są osobno.
• Skrypty z atrybutem defer. Pobierają się równolegle i wykonują w tej samej kolejności, ale nie wstrzymują pierwszego wyświetlenia.
• Style czatu ładowane w tle. Przycisk czatu i tak pojawia się dopiero po załadowaniu skryptów.

4. Ikony: 1500 w pliku, 135 w użyciu

Ikony na stronie pochodzą z biblioteki Phosphor, ładowanej jako czcionka. Pełne pliki zawierały około 1500 ikon i ważyły razem 280 KB. Używam 135.

Przy publikacji strona sama wyszukuje użyte ikony i przycina do nich pliki stylów oraz czcionki. Zostało 28 KB, czyli dziesięć razy mniej. Ikony wyglądają tak samo, a jeśli dodam nową, przy następnej publikacji trafi do pliku automatycznie.

5. Zdjęcia: właściwy rozmiar i format

To najczęstszy problem stron firmowych i u mnie też był największy:

• Zdjęcia w kartach miały 1440 px szerokości, a wyświetlały się w ramkach o szerokości 285–557 px. Teraz karty dostają wersje WebP o szerokości 800 px. Duże karty dalej mogą sięgnąć po pełne zdjęcie przez atrybut srcset, gdy ekran ma wysoką rozdzielczość. Same zdjęcia realizacji schudły z 2,9 MB do 0,9 MB.
• Leniwe ładowanie nie zawsze działa. Zdjęcia miały loading="lazy", ale przeglądarka i tak pobierała je od razu. Przy pierwszym układzie strony, zanim skrypty dobudowały sekcje wyżej, były blisko początku strony. Rozwiązaniem było zmniejszenie plików i świadome sterowanie tym, kiedy co się ładuje.
• Demo pobierało zdjęcia dla pięciu branż na zapas. Teraz pobiera zdjęcia bieżącej branży tuż przed budowaniem, a pozostałe dopiero wtedy, gdy pokaz faktycznie przełącza branże. Oszczędność: około 1,6 MB na każdym wejściu.

Bonus: strona przewijała się sama przy odświeżaniu

Przy okazji wyszedł drobny, ale irytujący błąd: po odświeżeniu strona otwierała się lekko przewinięta w dół. Przeglądarka zapamiętuje miejsce przewinięcia względem konkretnego elementu. U mnie skrypty po załadowaniu dobudowują połowę strony, więc ten element lądował niżej i strona przeskakiwała o 80–180 px.

Teraz odświeżenie zawsze zaczyna od góry, a przycisk „Wstecz” wraca dokładnie w to samo miejsce, bo strona sama zapamiętuje pozycję.

Co z tego wynika dla Twojej strony

Na stronach firmowych, które badam, najczęściej powtarzają się te same przyczyny:

1. Zdjęcia prosto z aparatu albo stocku, po kilka megabajtów, zamiast plików dopasowanych do miejsca na stronie.
2. Slajder albo wideo na górze strony, które pojawia się z opóźnieniem i staje się główną treścią w oczach Google.
3. Ciężki motyw i kilkanaście wtyczek, z których każda dokłada swoje style i skrypty na każdej podstronie.
4. Kilka rodzajów czcionek bez dopasowanych zamienników, przez co tekst przeskakuje.
5. Brak pomiaru. Bez sprawdzenia, który element jest główną treścią, łatwo poprawiać nie to, co trzeba.

Sprawdzenie zajmuje pół minuty: wpisz adres w narzędziu Zbadaj stronę, a dostaniesz wynik szybkości z Google razem z listą konkretnych przyczyn.

Ile kosztuje przyspieszenie strony

Drobne poprawki, takie jak kompresja zdjęć, porządek we wtyczkach i ustawienia serwera, robię w ramach opieki technicznej od 149 zł miesięcznie. Gdy strona stoi na ciężkim motywie i poprawki kosztowałyby więcej niż nowa wersja, modernizacja strony kosztuje od 2 900 zł. Wszystkie ceny są netto.

Sprawdźmy Twoją stronę

Zbadaj swoją stronę za darmo i wyślij mi raport spod wyniku albo napisz przez formularz. Odpowiem w 24 godziny, co spowalnia stronę i ile kosztuje poprawa. Nowi klienci dostają rabat 20% na pierwsze zlecenie.