Otwierasz na telefonie artykuł z pomiarami wzmacniacza. Nagłówek już widać, ale wykres pojawia się dopiero po przewinięciu strony. Czy dane się jeszcze ładują, czy wykresu w ogóle nie ma? Sam czas pobrania dokumentu tego nie wyjaśnia. Liczy się również chwila, w której pojawia się główna treść, reakcja wykresu na dotknięcie i stabilność strony podczas czytania.
W serwisie Hi-Fi duże fotografie urządzeń, skany wykresów, porównania parametrów i osadzone filmy mają swoje miejsce. Kłopot zaczyna się, gdy zasoby niepotrzebne w danej chwili opóźniają tekst, tabelę wyników albo menu. Dlatego szybkość warto oceniać przez pryzmat zadania czytelnika, nie tylko punktów w teście.
Co użytkownik odbiera jako szybką stronę?
Najpierw musi zobaczyć treść, po którą przyszedł. Potem strona powinna reagować bez wyraźnej zwłoki i nie przesuwać akapitów ani przycisków podczas ładowania. Te trzy kwestie opisują wskaźniki Core Web Vitals: LCP, INP i CLS. Pomagają w ocenie, ale nie zastępują sprawdzenia witryny na prawdziwym telefonie.
- LCP, Largest Contentful Paint, określa czas wyświetlenia największego widocznego elementu treści, zwykle obrazu lub dużego bloku tekstu. Za dobry wynik przyjmuje się najwyżej 2,5 sekundy.
- INP, Interaction to Next Paint, opisuje opóźnienie interakcji zarejestrowanych podczas wizyty. Dobry wynik nie przekracza 200 milisekund.
- CLS, Cumulative Layout Shift, mierzy nieoczekiwane przesunięcia układu. Za dobry uznaje się wynik nie większy niż 0,1.
Progi stosuje się do danych z rzeczywistych wizyt, zwykle oceniając 75. percentyl. Jeden dobry test na szybkim komputerze nie wystarczy: odpowiednie warunki powinna mieć także znaczna większość odwiedzających. Same wskaźniki też nie pokażą każdego problemu. Strona może mieścić się w progach, a mimo to utrudniać znalezienie opisu warunków pomiaru schowanego w niewygodnej tabeli.
Obrazy: największy element nie powinien czekać na swoją kolej
Zdjęcie wzmacniacza wysoko w artykule często staje się elementem LCP. Jeśli przeglądarka pozna jego adres dopiero po uruchomieniu skryptu, później rozpocznie pobieranie. Podobnie działa leniwe ładowanie ustawione dla grafiki widocznej od razu na ekranie. Przydaje się przy zdjęciach daleko w tekście, ale tu opóźnia pojawienie się treści.
Adres obrazu głównego powinien być dostępny bezpośrednio w kodzie strony, a jego rozmiar dopasowany do urządzenia. Nowoczesny format nie pomoże wiele, jeśli plik ma rozdzielczość wielokrotnie większą od miejsca, które zajmuje na ekranie. Przy wykresach trzeba też uważać na czytelność osi, legendy i drobnych oznaczeń. Skompresowaną wersję sprawdź w rzeczywistym rozmiarze wyświetlania — wykres nie musi znosić takiej samej kompresji jak fotografia obudowy.
Obrazy położone niżej można ładować później, pod warunkiem że wcześniej zarezerwuje się dla nich miejsce, podając wymiary lub proporcje. Inaczej zdjęcie rozsunie akapity po pobraniu i podniesie CLS. W galerii urządzeń miniatury również nie powinny zmieniać wysokości całego modułu.
Serwer i sieć: opóźnienie przed pierwszym bajtem
Zanim przeglądarka pokaże tekst, musi dostać odpowiedź serwera. Czas do pierwszego bajtu, czyli TTFB, obejmuje między innymi opóźnienie sieci i przygotowanie odpowiedzi. Może rosnąć przez odległość od serwera, przeciążony hosting, wolne zapytania do bazy danych lub generowanie każdej odsłony od nowa. Nie opisuje szybkości całej strony, ale późna odpowiedź opóźnia start pobierania kolejnych zasobów.
Jeśli publiczny artykuł nie zmienia się przy każdym wyświetleniu, buforowanie strony może ograniczyć pracę serwera. Pamięć podręczna przeglądarki pomaga przy kolejnych wizytach, bo nie trzeba ponownie pobierać niezmienionych plików. Sieć dostarczania treści może skrócić drogę obrazów i plików statycznych do osób mieszkających daleko od serwera. Żadne z tych rozwiązań nie naprawi jednak wielomegabajtowego obrazu głównego ani skryptu blokującego interakcję.
Sprawdź też przekierowania: każde dodaje etap przed dotarciem do treści, szczególnie odczuwalny przy połączeniu o większym opóźnieniu. Zanim zapłacisz za droższy hosting, ustal, czy czas ucieka już na odpowiedzi serwera, czy dopiero podczas pobierania i przetwarzania strony.
CSS i JavaScript: kiedy pobrany kod nadal spowalnia stronę
Gdy kluczowe style CSS docierają późno, przeglądarka może wstrzymywać wyświetlanie albo pokazać układ, który zaraz się zmieni. Arkusze potrzebne tylko w jednym formularzu nie muszą obciążać każdej podstrony. Usunięcie nieużywanych reguł i wcześniejsze dostarczenie stylów potrzebnych na pierwszym ekranie zwykle ma większy sens niż kosmetyczne skracanie nazw klas.
JavaScript obciąża nie tylko łącze, lecz także procesor telefonu, który musi kod przeanalizować i wykonać. Jeśli długie zadanie zajmuje główny wątek w chwili dotknięcia przycisku, odpowiedź będzie spóźniona nawet przy szybkim Wi-Fi. Ucierpi na tym INP. Warto sprawdzić zwłaszcza rozbudowane galerie, skrypty analityczne, odtwarzacze wideo, wyskakujące okna i interaktywne wykresy uruchamiane zaraz po otwarciu artykułu.
Nie oznacza to rezygnacji z interakcji. Wykres impedancji może najpierw pojawić się jako czytelna grafika, a kod do przybliżania danych pobrać dopiero wtedy, gdy czytelnik zechce z niego skorzystać. Podstawowe informacje muszą jednak pozostać dostępne bez czekania na skrypt. Odroczenie także niezbędnej nawigacji poprawi czas wyświetlenia kosztem obsługi strony.
Skrypty zewnętrzne wymagają osobnego przeglądu
Kod dodatków od innych dostawców trudniej kontrolować niż własne pliki. Może pobierać następne zasoby, obciążyć procesor w nieoczekiwanym momencie albo opóźnić otwarcie menu. Przy przeglądzie zanotuj, do czego służy każdy dodatek i na których podstronach jest potrzebny. Skrypty formularza kontaktowego nie muszą ładować się w każdym artykule o wzmacniaczach. Podobnie osadzony odtwarzacz nie musi pobierać całego zestawu zasobów, zanim ktoś zdecyduje się włączyć film.
Stabilność układu: szybkość to także brak niespodzianek
Przesunięcie strony przeszkadza szczególnie wtedy, gdy ktoś zaznacza wartość mocy w tabeli albo chce nacisnąć odsyłacz w spisie treści. Winny bywa obraz bez wymiarów, baner dołożony nad artykułem, font zmieniający szerokość tekstu lub moduł wstawiony po chwili. Strona wygląda na gotową, po czym ważny element nagle zmienia położenie.
Najprościej zarezerwować przestrzeń dla treści o przewidywalnym rozmiarze: obrazów, filmów i stałych modułów. Dla elementu o zmiennej wysokości lepiej przewidzieć osobne miejsce, niż wstawiać go ponad czytany akapit. Animacje nie powinny przesuwać otaczającego układu. Ma to również znaczenie dla dostępności — osoba powiększająca tekst lub obsługująca telefon jedną ręką łatwo traci punkt odniesienia po takim skoku.
Fonty, tabele i wersja mobilna
Własny krój pisma może dobrze pasować do witryny, ale kilka rodzin i wiele grubości to kolejne pliki. Font załadowany z opóźnieniem może na chwilę ukryć tekst albo zmienić podział wierszy. Warto ograniczyć liczbę odmian, użyć podzbioru znaków zawierającego polskie litery i sprawdzić wygląd tekstu, zanim właściwy font dotrze do przeglądarki.
Mobilną tabelę z pomiarami przetestuj osobno. Przewijanie w poziomie bywa lepsze niż ściskanie kolumn do nieczytelnego rozmiaru, ale możliwość przesuwania powinna być widoczna. Nagłówki muszą też pozwalać powiązać liczby z parametrami. Dobry LCP nie ujawni tego kłopotu. Podobnie blisko ustawione przyciski mogą reagować szybko, a mimo to prowadzić do pomyłek na małym ekranie.
Jak znaleźć rzeczywiste wąskie gardło
Test pojedynczego adresu pokazuje stronę w określonych warunkach. Dane terenowe obejmują wizyty prawdziwych użytkowników, z różnymi urządzeniami i połączeniami. Pierwsze źródło pomaga odtworzyć przyczynę, drugie pokazuje skalę problemu. Wyniki rozdzielaj dla telefonów i komputerów oraz według typu podstrony. Strona główna z galerią, długi artykuł i podstrona z tabelą nie muszą mieć tego samego wąskiego gardła.
- Wybierz konkretne zadanie. Sprawdź na przykład, kiedy po otwarciu artykułu można odczytać podpis pod pierwszym wykresem i użyć spisu treści.
- Zmierz więcej niż jedno wejście. Porównaj pierwszą wizytę z powtórną, a telefon z komputerem. Pamięć podręczna może ukryć problem, który dotyka nowych czytelników.
- Przejrzyj kolejność pobierania. Ustal, czy pojawienie się treści opóźnia obraz główny, style czy odpowiedź serwera. Oddziel duże pliki od kodu, który długo zajmuje procesor.
- Wprowadź jedną istotną zmianę. Zmniejsz właściwy obraz, usuń zbędny skrypt albo zarezerwuj miejsce na moduł. Potem zmierz stronę ponownie w porównywalnych warunkach.
Drobna różnica między dwoma uruchomieniami nie dowodzi poprawy — sieć i urządzenia mają naturalną zmienność. Szukaj powtarzalnego skrócenia opóźnienia i sprawdzaj skutki uboczne. Odroczenie skryptu może poprawić LCP, ale pogorszyć INP, jeśli kod uruchomi się akurat podczas pierwszego kliknięcia.
Priorytet według szkody dla czytelnika
Nie każdy wolny element wymaga natychmiastowej poprawki. Obraz na końcu długiego artykułu może pobrać się później bez szkody dla osoby czytającej początek. Pilniejsze są wykres otwierający analizę, opóźnione menu czy tabela przesuwająca się podczas odczytu wyników. O kolejności prac niech decyduje liczba osób, których dotyczy problem, jego wpływ na zadanie i to, czy poprawka zachowa czytelność materiału.
W artykule o pomiarach wzmacniacza zacznij od otwarcia strony na telefonie z wyłączoną pamięcią podręczną. Jeśli nagłówek i tekst pojawiają się szybko, a wykres na pierwszym ekranie znacznie później, sprawdź rozmiar właśnie tego pliku, moment, w którym przeglądarka poznaje jego adres, oraz ustawienie leniwego ładowania. Pozostałymi obrazami w galerii zajmij się po tej kontroli.
