3 praktyczne poprawki, które przyspieszą stronę

Optymalizację wydajności strony często warto zacząć od pobieranych zasobów, a nie od nowego frameworka. Menu restauracji, lista produktów i strona firmowa mogą zawierać zbędne dane obrazów, kod bibliotek oraz osadzone widżety.

Wybierz jedną ważną stronę i sprawdź ją na telefonie oraz komputerze. Zapisz wynik początkowy, a potem przejdź przez trzy poniższe kroki. Celem jest ograniczenie zbędnej pracy przeglądarki przy zachowaniu użytecznej treści i wyglądu strony.

1. Zmniejsz wagę zwykłych obrazów

Mały obraz też może oznaczać duży transfer. Wycięty produkt w PNG, baner promocyjny lub dekoracja tła mogą zawierać więcej danych, niż wymaga ich rola na stronie. Kilka takich plików potrafi ważyć sporo, choć żaden nie wygląda na szczególnie duży.

Dobrym przykładem jest sekcja menu na stronie głównej Five Guys. Pięć dostępnych do pobrania źródłowych plików PNG powiązanych z tą sekcją waży łącznie 1,29 MB. W lokalnym eksperymencie przekonwertowałem je do WebP o jakości 80, zachowując rozdzielczość i przezroczystość. Wynik to około 194 kB. Five Guys już dostarcza przeglądarce WebP; poniższa redukcja o 84,9% dotyczy porównania plików źródłowych w lokalnym eksperymencie.

Lokalny eksperyment na plikach źródłowych: 1,29 MB PNG → 193,7 kB WebP, czyli 84,9% mniej.

Menu Five Guys, zrzut z 19 października 2026 r. Źródło: Five Guys.

Zobacz pomiary i pliki źródłowe

Pobrane pliki PNG: łącznie 1 286 664 bajty. Sharp 0.35.5, WebP o jakości 80: 193 748 bajtów. Bez zmiany rozdzielczości, z zachowaniem kanału alfa. Same frytki zmniejszyły się z 438 779 do 57 414 bajtów. Porównuj wygląd w rzeczywistym rozmiarze wyświetlania, zwłaszcza krawędzie i drobne szczegóły.

Rozmiary poszczególnych plików; kB w jednostkach dziesiętnych.

Otwórz zoptymalizowany obraz frytek

Znajdź najcięższe żądania i dobierz format

Otwórz DevTools → Network, wyłącz pamięć podręczną, odśwież stronę i wybierz obrazy. Posortuj według wielkości transferu. Sprawdź plik faktycznie pobierany przez przeglądarkę: duży oryginał w bibliotece mediów nie jest problemem, jeśli responsywna strona dostarcza mniejszą wersję.

Żądania obrazów Five Guys, posortowane według rozmiaru. Niektóre adresy .png dostarczają WebP.

Otwórz zrzut Network w pełnym rozmiarze

Przed kompresją dopasuj rozdzielczość zdjęć do rozmiaru wyświetlania i gęstości pikseli. Karta o szerokości 400 pikseli na ekranie 2× może potrzebować obrazu 800-pikselowego zamiast pliku o szerokości 4000 pikseli. Wypróbuj WebP lub AVIF, jeśli są obsługiwane. Sama przezroczystość nie wymaga PNG. Oceniaj wygląd zamiast automatycznie wybierać najniższą jakość.

Dla kilku plików dobrym początkiem jest TinyPNG. Dla całej strony skorzystaj z przetwarzania obrazów w CMS-ie lub CDN. W Next.js next/image tworzy wersje responsywne, a poprawne sizes pomaga wybrać właściwą. Zasada jest taka sama na każdej platformie: dostarczaj wersję potrzebną danemu ekranowi.

Sprawdź rezultat

Porównaj oryginał i wynik w tym samym rozmiarze wyświetlania. Sprawdź żądania mobilne i desktopowe, zachowaj width i height oraz upewnij się, że nie utracono szczegółów ważnych dla treści. Główny obraz ładuj od razu, a te niżej — leniwie. Mniejszy transfer i stabilny układ rozwiązują różne problemy, więc sprawdź oba.

2. Sprawdź koszt starszych zależności

Zależność dodana kilka lat temu może nadal trafiać do przeglądarki, choć pierwotne potrzeby się zmieniły. Warto przeglądać aktualizacje wspieranych pakietów, ale wyższy numer wersji nie gwarantuje szybszej strony. Znaczenie mają też punkty wejścia, pliki językowe, powielone zależności i nieużywane funkcje.

Moment.js pokazuje, dlaczego warto przyjrzeć się wersjom pakietów. 19 października 2026 r. Bundlephobia pokazywała 75,4 kB po minifikacji i gzip dla 2.30.1 oraz 19,8 kB dla 2.31.0 — około 74% mniej w kompilacji tego serwisu. Informacje o wydaniu od twórców potwierdzają nowszą wersję i jej zmiany.

Szacunkowe rozmiary gzip w Bundlephobia: Moment.js 2.30.1 · 2.31.0

Porównaj ten sam punkt wejścia i wymagane języki we własnej wersji produkcyjnej. Rzeczywista oszczędność zależy od kodu wysyłanego przez aplikację.

Aktualizuj świadomie i wysyłaj potrzebny kod

Zacznij od największych skryptów ładowanych przez stronę. Przeczytaj changelog, sprawdź zgodność, zaktualizuj plik blokady zależności i ponownie zbuduj projekt. Potem sprawdź funkcje korzystające z pakietu: formularze, daty, wykresy lub nawigację.

Sprawdź też sposób importowania. Strona formatująca jedną datę nie musi automatycznie wysyłać wszystkich języków. Dokumentacja języków Moment wyjaśnia, jak ograniczyć te pliki. Do prostych etykiet dat może wystarczyć Intl.DateTimeFormat w przeglądarce. W innych bibliotekach stosuj udokumentowane importy modułowe, a ciężki edytor lub wykres ładuj na stronach, które go używają.

W WordPressie i innych kreatorach podobną rolę pełni przegląd wtyczek. Usuń nieużywany slider, kanał społecznościowy lub powieloną integrację analityczną. Wyłączenie widocznej funkcji nie zawsze usuwa jej skrypty, dlatego po zmianie ustawień sprawdź żądania.

Sprawdź rezultat

Porównuj JavaScript pobierany przez zbudowaną stronę przy tych samych ustawieniach kompresji i pamięci podręcznej. Rozmiar node_modules lub archiwum npm nie jest dobrym zamiennikiem. Analizator paczki może ujawnić powielone biblioteki i zbędne języki, a panel Network potwierdzi, co rzeczywiście otrzymują użytkownicy.

3. Ładuj filmy i widżety we właściwym momencie

Odtwarzacz, mapa lub czat mogą pobierać skrypty, style i otwierać dodatkowe połączenia, zanim ktoś z nich skorzysta. Na stronie kontaktowej restauracji odwiedzający może potrzebować tylko adresu i godzin otwarcia. Natychmiastowe uruchamianie pełnej interaktywnej mapy oznacza wtedy zbędną pracę.

Wskazówki Google dotyczące osadzanych treści podają użyteczny punkt odniesienia: leniwe ładowanie YouTube może ograniczyć początkowy transfer o około 500 kB.

Zastosuj leniwe ładowanie lub podgląd uruchamiany kliknięciem

Dla iframe umieszczonego daleko poniżej pierwszego ekranu zacznij od loading="lazy" albo odpowiedniego ustawienia w CMS-ie. Zarezerwuj szerokość i wysokość, aby pojawienie się treści nie przesuwało tekstu. Ta mała zmiana w HTML działa niezależnie od frameworka.

<iframe
  src="https://www.youtube.com/embed/aKydtOXW8mI"
  title="Film w YouTube"
  loading="lazy"
  width="560"
  height="315"
  allowfullscreen
></iframe>

Jeśli odtwarzacz jest blisko góry strony, leniwe ładowanie może pobrać go niemal od razu. Większą kontrolę daje lekki podgląd z prawdziwym przyciskiem odtwarzania, który ładuje film po kliknięciu. Nadaj przyciskowi dostępną nazwę i sprawdź, czy film można uruchomić również z klawiatury.

Podobnie traktuj inne integracje. Przed otwarciem mapy może wystarczyć adres i odnośnik do wskazówek dojazdu. Przycisk czatu może wczytać cały widżet dopiero na żądanie. Kluczowe informacje powinny być dostępne od razu, a dodatkowy interfejs może poczekać.

Sprawdź rezultat

Odśwież stronę bez pamięci podręcznej i sprawdź żądania zewnętrzne przed przewijaniem lub klikaniem. Natywne leniwe ładowanie zaczyna się blisko widocznego obszaru, więc iframe może załadować się przed pojawieniem na ekranie. Wariant uruchamiany kliknięciem powinien czekać na interakcję. Następnie przetestuj film, mapę lub czat: mniej żądań ma sens, gdy funkcja nadal działa.

Zmień jedną rzecz i zmierz ponownie

Przed zmianą i po niej używaj tego samego adresu, profilu urządzenia i warunków testu. Wykonaj kilka pomiarów, aby nie pomylić zwykłej zmienności z poprawą. Porównuj transfer razem z metrykami ładowania: mniejsze obrazy nie dowodzą, że naprawiono wolny serwer lub długi skrypt. Zachowuj zmiany, które poprawiają zmierzoną stronę bez szkody dla treści.

Uruchom darmowy test szybkości NEKTIQA i przejrzyj diagnostykę Lighthouse. Po poprawce porównaj kolejny wynik. Testy cykliczne i historia wydajności pokażą, czy efekt utrzymuje się po następnych wdrożeniach.

Uruchom darmowy test szybkości · Poznaj monitoring Lighthouse