Strona firmowa, czysty kod, żadnych ciężkich zdjęć, żadnych wtyczek. Wynik pomiaru szybkości na telefonie: 85. Do poprawy, ale nic dramatycznego.
Ciekawe było co innego. Trzy różne wskaźniki pokazywały dokładnie tę samą wartość: 3,3 sekundy. Czas do pierwszej treści, czas do największego elementu i wskaźnik szybkości wyświetlania. Do tego zero czasu blokowania i praktycznie zerowe przesuwanie układu.
Znaczenie tych wskaźników opisuje dokumentacja podstawowych wskaźników internetowych. Taki układ liczb mówi jedną rzecz i nie trzeba zgadywać: przez 3,3 sekundy nie renderowało się nic, a potem wszystko naraz. To nie jest problem ciężkich skryptów ani układu strony. To zasoby blokujące wyświetlenie.
Co blokowało
Arkusz stylów z krojami pisma pobierany z obcego serwera.
Wygląda niewinnie, jedna linijka w nagłówku. Ale przeglądarka musi po kolei: rozwiązać nazwę obcego serwera, nawiązać z nim połączenie szyfrowane, pobrać arkusz i dopiero z niego dowiedzieć się, gdzie leżą właściwe pliki krojów. Potem powtórzyć część tej drogi dla samych plików. Dopóki to nie skończy się w całości, tekst się nie pokazuje.
Do tego doszedł drugi koszt, który nie widać w żadnym raporcie wydajności: wczytanie kroju z obcego serwera wysyła tam adres IP odwiedzającego, zanim ten zdąży kliknąć cokolwiek w banerze zgód. Jeśli baner deklaruje, że przed zgodą nic nie wychodzi na zewnątrz, to jest dziura w tej deklaracji.
Co zrobiłem
Kroje na własny serwer, w wariantach zmiennych. Zamiast ośmiu plików na osiem grubości jeden plik z całą skalą. Przeglądarka wylicza pośrednie grubości sama.
Przycięcie do znaków, które realnie występują. Zebrałem wszystkie znaki z treści serwisu: wyszło 209 pozycji plus pełny alfabet polski i typografia. Reszta, czyli cyrylica, greka, znaki wietnamskie i cała masa symboli, poszła precz. Cztery pliki zamiast trzynastu, 63 kilobajty zamiast 172.
Zakresy znaków wyliczone z zawartości plików, nie przepisane z arkusza (opis własności unicode-range). To drobiazg, który potrafi zepsuć całość: jeśli zadeklarujesz zakres szerszy, niż plik faktycznie zawiera, przeglądarka pobierze plik i nie znajdzie w nim znaku, więc pokaże znak zastępczy zamiast litery. Zakres musi zgadzać się z tym, co jest w środku.
Deklaracje krojów wprost w kodzie strony, żeby przeglądarka nie musiała czekać na osobny plik z informacją, gdzie szukać krojów.
Wcześniejsze pobranie pod dokładnie tym samym adresem, pod jakim odwołuje się do niego deklaracja kroju. Jeśli adresy różnią się choćby ukośnikiem, przeglądarka pobierze plik dwa razy i wcześniejsze pobranie zamiast pomóc, zaszkodzi.
Wynik
| Wskaźnik | Przed | Po |
|---|---|---|
| Wynik na telefonie | 85 | 99 |
| Wynik na komputerze | 99 | 100 |
| Czas do pierwszej treści | 3,3 s | 1,2 s |
| Czas do największego elementu | 3,3 s | 1,6 s |
| Przesuwanie układu | 0,014 | 0 |
| Czas zasobów blokujących | 2390 ms | 300 ms |
Jeden wskaźnik pogorszył się: czas blokowania głównego wątku wzrósł z zera do 80 milisekund. To koszt przetworzenia wariantu zmiennego, który jest bardziej złożony od zwykłego pliku. Przy progu 200 milisekund, powyżej którego zaczyna to mieć znaczenie, jest to bez wpływu.
Skutek uboczny, którego nie szukałem
Przy okazji wyszło, że jeden z krojów był używany w stylach w grubościach 700 i 800, a ładowany wyłącznie w 400 i 500. Przeglądarka nie miała skąd wziąć pogrubienia, więc pogrubiała litery sama, rozciągając kształty. Wygląda to gorzej niż prawdziwy krój pogrubiony i większość osób nie umie tego nazwać, tylko czuje, że coś jest nie tak.
Wariant zmienny naprawił to przy okazji, bo zawiera całą skalę grubości w jednym pliku.
Czego nie zrobiłem, choć narzędzia to podpowiadają
Każde narzędzie do pomiaru będzie sugerować wstawienie krytycznych stylów wprost w kod strony, żeby zdjąć ostatnie kilkaset milisekund.
Próbowałem tego wcześniej na tej samej witrynie. Skończyło się przesuwaniem treści podczas ładowania na poziomie 0,654, przy progu dobrego wyniku 0,1. Strona dosłownie skakała pod palcem. Cofnąłem i wróciłem do zwykłego arkusza.
Po przeniesieniu krojów na własny serwer zostało 300 milisekund na arkusz stylów z tego samego serwera. Przy wyniku 99 na telefonie ryzyko powtórki skakania jest nieproporcjonalne do zysku. Podpowiedź narzędzia nie jest poleceniem.
Co z tego wynika dla Twojej strony
Trzy rzeczy warte sprawdzenia, każda zajmuje kilka minut.
Czy Twoja strona pobiera kroje z obcego serwera. Otwórz stronę, włącz narzędzia deweloperskie, zakładka Sieć, i zobacz, czy w liście żądań są adresy spoza Twojej domeny odpowiadające za kroje pisma. Jeśli są, masz do zdjęcia i czas ładowania, i przekazywanie danych przed zgodą.
Czy wskaźniki wyglądają podobnie do siebie. Jeśli czas do pierwszej treści, czas do największego elementu i wskaźnik szybkości pokazują niemal to samo, problemem są zasoby blokujące wyświetlenie, a nie skrypty ani obrazy. To zawęża poszukiwania z dziesięciu podpowiedzi do jednej.
Który element jest tym mierzonym jako największy. Raport to pokazuje. Bez tego łatwo przez tydzień optymalizować rzecz, która waży dwa procent, i dziwić się, że wynik stoi.
Pomiar przed i po jest częścią roboty, nie dodatkiem do niej. Bez niego nie wiadomo, czy zmiana pomogła, czy tylko wydawała się słuszna.