Jak przyspieszyć stronę internetową: praktyczna lista kontrolna

Aby przyspieszyć stronę internetową, najpierw zmierz ją w PageSpeed Insights, a potem napraw największą przyczynę, jaką wskaże — zwykle zbyt duże obrazy, zbyt dużo JavaScriptu, ciężkie czcionki lub skrypty zewnętrzne. Celuj w wartości „dobre” Core Web Vitals Google: główna treść widoczna w ciągu 2,5 sekundy, reakcja na dotknięcie w ciągu 200 milisekund i prawie żadnych przeskoków układu. Większość stron osiąga to kilkoma zmianami, a nie przepisywaniem od nowa.

Zmierz, zanim cokolwiek zmienisz

Zgadywanie marnuje czas. Dwa darmowe narzędzia wystarczą prawie każdemu:

• PageSpeed Insights (pagespeed.web.dev) — wklej działający adres URL. Pokazuje dane terenowe od prawdziwych użytkowników Chrome (jeśli strona ma wystarczający ruch) i dane laboratoryjne z symulowanego ładowania, a także listę konkretnych problemów.
• Lighthouse w narzędziach dla deweloperów Chrome — ten sam test laboratoryjny, uruchamiany na dowolnej stronie, którą możesz otworzyć, również na podglądzie. Testuj w trybie mobilnym; problemy ujawniają się na telefonach przy wolniejszych sieciach.

Liczby, które mają znaczenie, to Core Web Vitals Google. Od września 2026 roku dokumentacja Google na web.dev podaje następujące progi „dobre”, mierzone na 75. percentylu ładowań strony:

INP zastąpił starszą metrykę First Input Delay w 2024 roku. Jeśli jakieś narzędzie wciąż pokazuje FID, jest nieaktualne.

Zapisz swoje wyjściowe wartości. Po każdej poprawce testuj ponownie, by wiedzieć, co pomogło.

Gdzie uciekają sekundy: opcje i kompromisy

Każda typowa przyczyna ma poprawkę, a każda poprawka ma koszt. Zacznij od tych na górze — są najtańsze i najczęstsze.

Obrazy

Obrazy to najczęstszy problem i najłatwiejszy do naprawienia. Zdjęcie o szerokości 4000 pikseli wyświetlane w 800 pikselach zmusza każdego odwiedzającego do pobrania pięciokrotnie więcej, niż widzi.

• Serwuj obrazy w rozmiarze, w jakim są wyświetlane, z responsywnymi rozmiarami srcset dla telefonów i komputerów.
• Używaj nowoczesnych formatów (WebP lub AVIF) i rozsądnej kompresji.
• Ustaw width i height przy każdym obrazie, by przeglądarka zarezerwowała miejsce. Samo to usuwa większość przeskoków układu.
• Ładuj leniwie obrazy poniżej linii przewinięcia za pomocą loading="lazy".
• Nigdy nie ładuj leniwie głównego obrazu na górze strony. Wytyczne Google dotyczące LCP są w tym kategoryczne: leniwe ładowanie obrazu LCP zawsze go opóźnia. Zamiast tego daj mu fetchpriority="high".

JavaScript

Wiele stron budowanych przez AI to aplikacje jednostronicowe (SPA): przeglądarka pobiera paczkę JavaScript, a dopiero potem rysuje stronę. Im większa paczka, tym dłuższy pusty ekran. Poprawki, od najmniej do najbardziej pracochłonnej:

1. Usuń to, czego nie używasz. Poproś o listę zależności i wytnij biblioteki dodane kiedyś i zapomniane — bibliotekę dat do jednej daty, pełny pakiet ikon do pięciu ikon.
2. Dziel według tras. Ładuj kod panelu administracyjnego dopiero wtedy, gdy ktoś go otworzy, a nie na stronie głównej.
3. Prerenderuj publiczne strony. Strona marketingowa dostarczana jako prawdziwy HTML pojawia się, zanim uruchomi się jakikolwiek JavaScript. To też pomaga wyszukiwarkom; zobacz SEO dla stron tworzonych przez AI.

Wolny INP zwykle oznacza jedno długie zadanie blokujące stronę — filtrowanie ogromnej listy przy każdym naciśnięciu klawisza albo ponowne renderowanie całej tabeli, gdy zmienia się jedna komórka. Panel Performance w narzędziach dla deweloperów Chrome pokazuje, które.

Czcionki

Każda rodzina czcionek i każda waga to kolejny plik. Zwykle wystarczą dwie rodziny i trzy lub cztery wagi. Preładuj czcionkę używaną nad linią przewinięcia, użyj font-display: swap, aby tekst pokazał się od razu, i hostuj czcionki samodzielnie, jeśli zewnętrzna usługa czcionek jest wolna dla twoich odwiedzających.

Skrypty zewnętrzne

Widżety czatu, analityka, mapy cieplne, piksele reklamowe, osadzone filmy i kanały społecznościowe ładują kod z innych serwerów. Każdy z nich wygląda na mały; razem często stanowią najwolniejszą część strony. Zostaw te, których faktycznie używasz. Resztę ładuj po tym, jak strona stanie się interaktywna, a ciężkie osadzenia (odtwarzacz YouTube, mapa) zamień na lekki podgląd, który ładuje właściwą treść po kliknięciu.

Odpowiedź serwera

Time to First Byte (TTFB) — czas, po jakim serwer zaczyna odpowiadać — leży u podstaw każdej innej metryki. Strony statyczne serwowane z CDN (sieci serwerów blisko odwiedzających; zobacz czym jest CDN) są szybkie prawie wszędzie. Strony generowane przez serwer przy każdym żądaniu zależą od tego serwera i jego bazy danych. Cache powtarzanej pracy i indeksy w bazie danych dla wolnych zapytań to typowe poprawki.

Prompty, które działają

Bądź konkretny: nazwij stronę, metrykę i ograniczenie. Wklej wyniki PageSpeed Insights, jeśli je masz.

PageSpeed Insights pokazuje LCP 4,8 s na telefonie dla strony głównej, a elementem LCP jest obraz główny. Zmień rozmiar i przekonwertuj obraz główny do WebP, serwuj responsywne rozmiary, ustaw width i height, daj mu fetchpriority="high" i upewnij się, że nie jest ładowany leniwie. Ładuj leniwie każdy obraz poniżej linii przewinięcia. Nie zmieniaj projektu.

Przeprowadź audyt zależności tej aplikacji. Wypisz każdy pakiet, to, czego używa, i mniej więcej ile dodaje do paczki. Usuń nieużywane i podziel trasy /admin oraz /settings na osobne fragmenty, które ładują się tylko przy wejściu.

Pole wyszukiwania na /products działa z opóźnieniem. Dodaj debounce do filtra, unikaj ponownego renderowania całej listy przy każdym naciśnięciu klawisza i, jeśli lista ma ponad 200 pozycji, podziel ją na strony lub zastosuj wirtualizację.

Krok po kroku

1. Przetestuj działającą stronę w PageSpeed Insights na telefonie. Zanotuj LCP, INP i CLS oraz trzy główne problemy z listy.
2. Najpierw napraw obrazy: rozmiary, formaty, wymiary, leniwe ładowanie poniżej linii przewinięcia, priorytet dla obrazu głównego.
3. Wytnij skrypty zewnętrzne, których nie używasz, a resztę odłóż w czasie.
4. Przytnij czcionki do tego, czego wymaga projekt.
5. Zmniejsz JavaScript: usuń nieużywane pakiety, dziel według tras.
6. Prerenderuj publiczne strony, jeśli nadal są renderowane po stronie klienta, a LCP wciąż jest wolny.
7. Sprawdź serwer: cache, indeksy bazy danych, hosting statyczny dla treści, które rzadko się zmieniają.
8. Opublikuj ponownie i przetestuj. Dane terenowe w PageSpeed Insights aktualizują się w ciągu kolejnych tygodni, w miarę napływu prawdziwych wizyt, więc wczesne wyniki oceniaj po danych laboratoryjnych.

Częste błędy

• Testowanie tylko na szybkim laptopie. Twoi odwiedzający korzystają ze średniej klasy telefonów i niestabilnej mobilnej transmisji danych. Testuj w trybie mobilnym.
• Gonienie za idealnym wynikiem 100. Wynik laboratoryjny to wskazówka. Gdy Core Web Vitals są w dobrym zakresie, treść i użyteczność liczą się bardziej niż ostatnie punkty.
• Ładowanie leniwie wszystkiego, łącznie z obrazem głównym. To pogarsza LCP.
• Dokładanie wtyczki lub biblioteki do przyspieszania. Usuwanie ciężaru prawie zawsze wygrywa z dodawaniem kodu do jego zarządzania.
• Optymalizowanie podglądu, a nie działającej strony. Podglądy deweloperskie działają na nieoptymalizowanych buildach. Mierz opublikowany adres URL.
• Przyspieszanie strony raz. Każdy nowy widżet, obraz i funkcja dokłada ciężaru. Testuj ponownie po większych zmianach.

Lista kontrolna szybkości

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 na telefonie
• Obrazy zmniejszone, skompresowane, w nowoczesnym formacie, z width i height
• Obraz główny nie jest ładowany leniwie; obrazy poniżej linii przewinięcia są ładowane leniwie
• Brak nieużywanych bibliotek JavaScript; ciężkie trasy wydzielone
• Dwie rodziny czcionek lub mniej, główna czcionka preładowana
• Tylko skrypty zewnętrzne, których faktycznie używasz, ładowane późno
• Publiczne strony prerenderowane lub statyczne, gdy to możliwe
• Ponowny test na działającym adresie URL po publikacji

Szybkość i układ mobilny idą ze sobą; zobacz jak zrobić stronę internetową responsywną na telefony. Pełne przejście przed startem, obejmujące resztę, opisuje jak przenieść prototyp AI na produkcję.

Szybkość w Mythex

W Mythex wprowadzasz te zmiany, prosząc w czacie lub w edytorze kodu w planie Pro. Sprawdzaj opublikowany adres URL, a nie Podgląd, ponieważ Podgląd działa na serwerze deweloperskim. Statyczne frontendy są przy publikacji wdrażane jako strony statyczne (strony statyczne), co pasuje do stron z treścią. Aplikacje z serwerem skalują się do zera: po bezczynności usypiają i budzą się przy kolejnej wizycie, więc pierwsze żądanie po ciszy jest wolniejsze, a podłączona baza danych zasypia po 5 minutach bezczynności (limity hostingu). Jeśli publiczna strona jest wolna tylko przy pierwszej wizycie, to prawdopodobna przyczyna. Utrzymywanie stron marketingowych jako statycznych pomaga. Po zmianach opublikuj ponownie i odśwież stronę z wymuszeniem.

Pytania