Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
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.
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.
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.
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.
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.
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.
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.
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.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |