Dlaczego strona działa wolno na telefonie? 12 przyczyn i plan naprawy

Najpierw odróżnij wolne ładowanie od wolnej obsługi

Strona może długo pokazywać główną treść, reagować z opóźnieniem po kliknięciu albo przesuwać elementy. To różne problemy. LCP opisuje czas pojawienia się największego elementu, INP reakcję na interakcje, a CLS stabilność układu. Dodatkowo warto sprawdzić TTFB, liczbę żądań i rozmiar transferu.

Testuj konkretny URL co najmniej kilka razy, w trybie prywatnym, bez rozszerzeń i z wyłączonym cache przy analizie sieci. Dane polowe z Chrome UX Report obejmują realnych użytkowników z ostatnich 28 dni i nie zmienią się natychmiast po poprawce.

1-3. Zbyt duże obrazy, niewłaściwy format i brak wymiarów

Zdjęcie z aparatu może mieć kilka megabajtów, choć na ekranie zajmuje 600 pikseli. Serwowanie go bez zmniejszenia jest najczęstszym prostym błędem. Przygotuj responsywne warianty, użyj WebP lub AVIF, dobierz kompresję i nie ładuj od razu grafik znajdujących się daleko poniżej pierwszego ekranu.

Obraz LCP nie powinien korzystać z opóźnionego ładowania. Można nadać mu wysoki priorytet i preload, jeśli rzeczywiście jest najważniejszym zasobem. Każdy img powinien mieć width oraz height albo zarezerwowane proporcje w CSS, aby układ nie skakał po pobraniu pliku.

4-5. Nadmiar JavaScriptu i długa praca głównego wątku

Buildery, slidery, animacje, czaty, piksele i wtyczki mogą wysłać setki kilobajtów kodu. Telefon musi go pobrać, skompilować i wykonać. Nawet skrypt pobrany z cache może blokować reakcję na dotyk. Usuń nieużywany kod, dziel paczki i ładuj funkcje dopiero tam, gdzie są potrzebne.

Duże zadania JavaScript warto dzielić na mniejsze. Obsługa kliknięcia powinna wykonać minimum pracy, a kosztowne obliczenia można odłożyć. Nie każdy efekt wymaga biblioteki. Menu, akordeon i prostą animację da się często zbudować w CSS lub niewielkim skrypcie.

6. Za dużo fontów i odmian kroju

Każdy krój i grubość to dodatkowy plik. Zestaw dwóch rodzin po pięć odmian może dodać setki kilobajtów i opóźnić tekst. Ogranicz liczbę wariantów, użyj WOFF2, podzbioru znaków oraz font-display: swap. Najważniejszą odmianę można preloadować, lecz nie należy preloadować wszystkiego.

Font systemowy jest najszybszy, ale nie zawsze pasuje do marki. Dobry kompromis to jedna rodzina tekstowa i ewentualnie osobny krój nagłówków w dwóch grubościach. Sprawdź także, czy zewnętrzny serwer fontów nie opóźnia połączenia.

7-8. Wolny serwer, brak cache i zbyt wiele zapytań do bazy

Jeżeli dokument HTML zaczyna pobierać się po kilku sekundach, optymalizacja obrazu nie rozwiąże podstawowego problemu. Sprawdź TTFB, obciążenie hostingu, wersję PHP, bazę, cache strony i połączenia z zewnętrznymi API. Na współdzielonym hostingu sąsiednie konta mogą wpływać na dostępne zasoby.

W WordPressie liczbę zapytań zwiększają źle napisane wtyczki, rozbudowane menu, filtry i brak cache. Cache pełnej strony, obiektów oraz opcode może znacząco skrócić odpowiedź. Zmiany trzeba testować po zalogowaniu i bez logowania, bo administrator często omija cache.

9-10. Skrypty zewnętrzne, reklamy i baner cookies

Czat, mapa, film, system rezerwacji i narzędzia marketingowe korzystają z innych domen. Każde połączenie wymaga DNS, TLS i czasu odpowiedzi, którego nie kontrolujesz. Osadzenie filmu z YouTube można zastąpić lekką miniaturą uruchamiającą player po kliknięciu. Mapę warto ładować dopiero po wejściu w sekcję.

Baner cookies również może spowolnić stronę, jeśli jest częścią ciężkiej platformy. Skrypty analityczne i reklamowe powinny uruchamiać się zgodnie ze zgodą, ale sama warstwa zgody musi działać szybko i nie przesuwać zawartości.

11-12. Blokujący CSS, zła kolejność ładowania i brak CDN

Duży arkusz CSS wstrzymuje renderowanie. Usuń nieużywane reguły, minimalizuj pliki i dostarcz krytyczny styl szybko. Nie wstawiaj całego frameworka do każdej podstrony, jeśli projekt używa niewielkiej części. Unikaj importowania CSS z kolejnych plików, bo tworzy to sekwencyjne żądania.

CDN skraca drogę do statycznych zasobów i odciąża serwer, ale nie naprawi wolnej bazy ani ciężkiego JavaScriptu. Włącz kompresję Brotli lub gzip, długie nagłówki cache dla wersjonowanych plików i HTTP/2 lub HTTP/3, jeśli hosting je obsługuje.

Plan naprawy w dobrej kolejności

1. Zapisz wyniki LCP, INP, CLS, TTFB, transfer i liczbę żądań.
2. Znajdź największy element pierwszego ekranu i krytyczne zasoby.
3. Zmniejsz obrazy oraz usuń zasoby nieużywane.
4. Sprawdź odpowiedź serwera i cache.
5. Ogranicz JavaScript, fonty oraz skrypty zewnętrzne.
6. Przetestuj formularze, zgodę cookies i główne interakcje.
7. Wdróż zmianę, porównaj laboratorium i obserwuj dane polowe.

Szczegółowe progi metryk opisuje artykuł Core Web Vitals: LCP, INP i CLS. Audyt przyczyn można wykonać w ramach optymalizacji technicznej SEO.

Jak wykonać użyteczny test na prawdziwym telefonie?

Wyłącz Wi-Fi i otwórz stronę przez sieć komórkową po wyczyszczeniu danych przeglądarki. Nagraj ekran od kliknięcia linku do możliwości wykonania pierwszej akcji. Zwróć uwagę, kiedy pojawia się tytuł, czy obraz blokuje treść, czy menu reaguje i czy coś przesuwa palec tuż przed dotknięciem.

Przetestuj słabsze urządzenie, nie tylko nowy telefon właściciela. Włącz oszczędzanie danych lub procesora, jeśli system je posiada. Przejdź podstronę wejścia z reklamy, usługę, blog i formularz. Każdy szablon może mieć inne zasoby. Panel deweloperski komputera pomaga znaleźć plik, ale realne urządzenie ujawnia ergonomię i opóźnienie dotyku.

Po optymalizacji powtórz tę samą ścieżkę, w podobnych warunkach, i zestaw czas z danymi narzędzi. Zapisuj wagę strony, liczbę żądań, LCP i błędy konsoli przed oraz po zmianie. Dzięki temu można udowodnić, że usunięcie slidera skróciło ładowanie, zamiast opierać się na wrażeniu po wejściu z ciepłym cache.