Optymalizacja prędkości ładowania strony na urządzeniach mobilnych.

Telefon w słabym zasięgu to norma

Baner wejsciowyParallax

Optymalizacja prędkości ładowania strony na urządzeniach mobilnych.

Telefon w słabym zasięgu to norma

Autor nie posiada zdjęcia
Tomasz Piasecki
29 listopada 2021

Najczęstszy błąd w rozmowie o szybkości strony polega na tym, że testujemy ją na własnym sprzęcie. Laptop z szybkim procesorem, biuro ze światłowodem, przeglądarka z zapełnioną pamięcią podręczną — w takich warunkach prawie każda strona wydaje się w porządku.

Tymczasem znaczna część ruchu przychodzi z telefonów o średnich możliwościach, w zmiennym zasięgu, przy pierwszej wizycie, czyli bez żadnych plików w pamięci. To zupełnie inne warunki i strona, która u mnie ładuje się w sekundę, może tam potrzebować kilkunastu.

Poniżej opisuję, co w praktyce daje największą poprawę na telefonach, w kolejności od rzeczy najprostszych i najbardziej opłacalnych. Piszę o technikach, nie o wskaźnikach — te opisywałem wcześniej osobno.

Najpierw ustal, co i gdzie mierzysz

Bez tego cała reszta jest zgadywaniem, a ryzyko optymalizowania nie tego, co trzeba, jest bardzo duże.

Rozdzielam dwa rodzaje danych. Pomiar laboratoryjny to test wykonany na żądanie, w kontrolowanych warunkach, przy symulowanym słabszym urządzeniu i połączeniu. Nadaje się do diagnozy i do sprawdzania, czy zmiana pomogła. Dane od użytkowników to obserwacje z rzeczywistych wizyt, zebrane z prawdziwych urządzeń. Nadają się do oceny, czy w ogóle jest problem.

Kolejność jest taka: dane od użytkowników mówią, czy i gdzie boli, a test laboratoryjny mówi, dlaczego. Odwrócenie tej kolejności to najczęstsza przyczyna tygodni pracy nad podstroną, której nikt nie odwiedza.

Praktyczna uwaga: testuję zawsze co najmniej trzy typy stron — stronę główną, stronę kategorii lub listy i stronę docelową kampanii. Zwykle są zbudowane inaczej i wynik dla strony głównej nie mówi nic o pozostałych. Do tego mierzę kilka razy, bo pojedynczy pomiar potrafi się mocno różnić od kolejnego.

Obrazy — najprostsze i największe oszczędności

W dziewięciu z dziesięciu serwisów, które sprawdzam, obrazy odpowiadają za największą część przesyłanych danych. To jednocześnie obszar, w którym poprawa wymaga najmniej pracy programistycznej.

  • Rozmiar dopasowany do wyświetlania. Zdjęcie o szerokości trzech tysięcy pikseli wyświetlane w kontenerze o szerokości czterystu to marnowanie danych i czasu procesora telefonu na przeskalowanie.
  • Nowoczesny format kompresji. Przy tej samej jakości wizualnej pliki bywają o kilkadziesiąt procent mniejsze niż w klasycznych formatach. Warto podawać wersję zapasową dla przeglądarek, które nowego formatu nie obsługują.
  • Wersje o różnych rozmiarach z informacją dla przeglądarki, żeby telefon pobierał wariant mniejszy, a komputer większy.
  • Leniwe ładowanie obrazów poniżej pierwszego ekranu — dziś obsługiwane przez przeglądarki bez dodatkowego kodu.
  • Rezerwacja miejsca przez podanie wymiarów. Bez tego treść przeskakuje w trakcie ładowania, co jest jednocześnie irytujące i mierzone jako problem.

Osobno uwaga o obrazie głównym: nie stosuję leniwego ładowania do zdjęcia widocznego od razu. To pozornie sprzeczna z intuicją rada, ale opóźnienie pobrania głównego obrazu bezpośrednio pogarsza odczuwany czas ładowania.

Skrypty i to, co ładuje się z zewnątrz

Drugi wielki obszar i trudniejszy, bo zwykle wymaga decyzji biznesowych, nie tylko technicznych.

Telefon o średnich możliwościach potrzebuje na wykonanie kodu wielokrotnie więcej czasu niż komputer. Dlatego skrypty bolą na urządzeniach mobilnych nieproporcjonalnie mocniej niż obrazy — nie tylko trzeba je pobrać, ale i przetworzyć.

Zaczynam od zrobienia listy wszystkiego, co strona ładuje z domen zewnętrznych: narzędzia analityczne, czaty, mapy, widżety opinii, banery zgód, piksele reklamowe, czcionki. W typowym sklepie takich elementów jest kilkanaście, a połowa została dodana kiedyś do testu i nikt ich nie usunął.

Potem zadaję przy każdym pytanie: czy to jest potrzebne, czy może się ładować później i czy musi być na każdej podstronie. Czat, który ładuje się na stronie potwierdzenia zamówienia, jest zbędny. Mapa, która ładuje się na każdej podstronie, a jest widoczna tylko na stronie kontaktu, to czysta strata.

Techniki, które stosuję najczęściej: odłożenie wykonania skryptów, które nie są potrzebne do wyrenderowania strony, ładowanie ciężkich widżetów po interakcji użytkownika, ograniczenie liczby domen, z którymi przeglądarka musi nawiązać połączenie. Przeniesienie części pomiaru na własny serwer też pomaga, ale to temat na osobny tekst.

Czcionki i styl

Obszar niedoceniany, w którym poprawa jest szybka.

Czcionki zewnętrzne wymagają dodatkowego połączenia i pobrania plików, a do tego blokują wyświetlenie tekstu. Efekt: strona wygląda na pustą, mimo że treść jest już dostępna.

Trzy rzeczy, które robię. Ograniczam liczbę wariantów — dwa kroje po dwie grubości zamiast sześciu. Wskazuję przeglądarce, żeby wyświetliła tekst zastępczą czcionką systemową, zanim pobierze docelową; drobne przeskoczenie kroju jest mniej dotkliwe niż kilka sekund pustego ekranu. I hostuję pliki czcionek u siebie, co usuwa jedno połączenie z domeną zewnętrzną.

Przy arkuszach stylów najważniejsze jest usunięcie tego, co nieużywane. Szablony ogólnego przeznaczenia ładują styl dla dziesiątek elementów, których dany serwis nie używa. Wyczyszczenie tego wymaga uwagi, ale daje wymierny efekt na słabszym urządzeniu.

Serwer i dostarczanie treści

Zanim przeglądarka zacznie cokolwiek robić, musi dostać odpowiedź. Ten pierwszy odcinek jest często pomijany w analizie.

Sprawdzam czas odpowiedzi serwera przy pierwszym żądaniu. Jeśli wynosi kilkaset milisekund, to jest już połowa budżetu czasowego zużyta, zanim cokolwiek się zaczęło. Przyczyny są zwykle po stronie zapytań do bazy danych, braku pamięci podręcznej albo współdzielonego hostingu z przeciążeniem.

Elementy, które zawsze weryfikuję: kompresja treści włączona, nagłówki pamięci podręcznej ustawione sensownie dla plików, które się nie zmieniają, protokół pozwalający na jednoczesne pobieranie wielu plików, a przy ruchu z różnych regionów — sieć dostarczania treści.

Warto też pamiętać, że każde przekierowanie to dodatkowa podróż do serwera. Na telefonie w słabym zasięgu jeden zbędny skok potrafi kosztować kilkaset milisekund. Łańcuch trzech przekierowań na stronie docelowej kampanii to najbardziej niepotrzebna strata, jaką znam, i widuję ją regularnie.

Kolejność prac i realne oczekiwania

Zamykam tym, bo lista możliwych działań jest długa, a czas ograniczony.

Kolejność, którą stosuję: najpierw obrazy, bo najtaniej i najszybciej. Potem przegląd skryptów zewnętrznych i usunięcie zbędnych. Potem czas odpowiedzi serwera i pamięć podręczna. Na końcu praca nad kodem szablonu, bo jest najdroższa i wymaga programisty.

Zmiany wprowadzam pojedynczo i mierzę po każdej. Wdrożenie pięciu poprawek naraz oznacza, że nie dowiesz się, która pomogła, a która pogorszyła sytuację — a pogorszenie też się zdarza.

Oczekiwania warto ustawić uczciwie. Serwis zbudowany na ciężkim szablonie z kilkoma wtyczkami nie zamieni się w stronę wzorcową dzięki optymalizacji obrazów. Da się poprawić wynik zauważalnie, ale przeskok do zupełnie innej ligi wymaga zwykle przebudowy, i lepiej powiedzieć to na początku niż po trzech miesiącach drobnych poprawek.

Ostatnia rzecz, o której łatwo zapomnieć: szybkość jest stanem, nie projektem. Serwis zoptymalizowany w listopadzie po pół roku dokładania wtyczek i banerów wraca do punktu wyjścia. Warto włączyć pomiar do rutyny — jeden test miesięcznie na trzech typach stron wystarcza, żeby zauważyć pogorszenie, zanim stanie się problemem.

Podziel się tym artykułem z innymi!

Twitter Facebook Linke.din
Autor nie posiada zdjęcia
Tomasz Piasecki
Specjalista Google Ads / SEM
Zajmuję się kampaniami Google Ads i widocznością stron w wyszukiwarce. Na blogu UDI Group piszę o tym, jak ustawienia kampanii i decyzje techniczne przekładają się na realne wyniki. Staram się tłumaczyć mechanizmy, a nie tylko podawać gotowe przepisy.