Jak przyspieszyć stronę? 7 napraw, pomiary i Core Web Vitals

Strona może otwierać się szybko, a mimo to reagować z opóźnieniem na kliknięcia. Może też wyświetlać treść późno albo przesuwać elementy podczas ładowania. Dlatego przed optymalizacją sprawdzam, czy problem dotyczy LCP, INP, CLS, czy jeszcze innego fragmentu działania witryny. Siedem opisanych dalej napraw obejmuje obrazy, serwer, JavaScript, CSS, fonty i ładowanie zasobów. Przy każdej podaję, kiedy warto ją rozważyć i jak zmierzyć rezultat.

Zanim zaczniesz: zmierz Core Web Vitals na właściwej stronie

Core Web Vitals to trzy metryki Google: szybkość pojawienia się głównej treści, reakcja na interakcję i stabilność układu. Według strony Google o page experience są używane w systemach rankingowych, ale dobre wyniki nie gwarantują pozycji. Wydajność poprawiam więc dla ludzi i nie obiecuję po niej konkretnego wzrostu ruchu ani sprzedaży.

Zacznij od reprezentatywnych adresów, po jednym z każdego ważnego typu strony:

• strona wejściowa,
• kategoria,
• produkt,
• artykuł,
• ważny formularz albo koszyk.

Pierwszą wizytę i powrót badaj osobno, tak jak anonimowy test strony głównej i zakup zalogowanego klienta.

Core Web Vitals: trzy różne cele

W danych terenowych porównuj 75. percentyl, osobno dla telefonu i komputera, bo średnia i najlepszy przebieg wprowadzą cię w błąd. Docelowo wszystkie trzy metryki mają mieścić się w dobrym zakresie (web.dev).

TTFB, czyli czas do pierwszego bajtu odpowiedzi, pomaga szukać przyczyn i stoi poza trzema metrykami Core Web Vitals.

Brak INP to brak danych. Według dokumentacji PageSpeed Insights narzędzie potrafi dać pozytywną ocenę CWV na samych dobrych LCP i CLS, gdy danych INP jest za mało, a o obsłudze kliknięć taka etykieta nic nie mówi.

Lighthouse, CrUX i własne pomiary użytkowników

Prawdziwe wizyty odbywają się na innych urządzeniach i łączach, więc wynik terenowy może wyglądać inaczej (web.dev). Do własnego pomiaru nie wysyłaj treści formularzy, identyfikatorów klientów ani parametrów URL z danymi osobowymi.

CrUX w PageSpeed i w bieżącym API liczy ruchome okno 28 dni i aktualizuje się codziennie. Po wdrożeniu nowe wizyty stopniowo zastępują stare (dokumentacja CrUX API), a po 28 dniach okno obejmuje już tylko nową wersję. Miesięczny zbiór w BigQuery to osobny produkt danych, więc zapisuj daty okresu zbierania.

Brak danych oznacza za mało kwalifikujących się wizyt albo niespełnione warunki włączenia do zbioru. Metodologia CrUX pomija Safari i Chrome na iOS, więc test na prawdziwym iPhonie ma sens także przy dobrym mobilnym wyniku w CrUX.

Krok 1: Przyspiesz obraz LCP i pozwól przeglądarce wcześnie go odkryć

Najpierw znajdź w raporcie element LCP i sprawdź go osobno na telefonie i na komputerze, bo na każdym może to być inny element. Według web.dev kandydatem może być każdy blok tekstu, także nagłówek.

Dla obrazu rozbij czas oczekiwania na cztery odcinki:

Gdy obraz dalej czeka na JavaScript albo arkusz CSS, zysk z mniejszego pliku może w ogóle nie pojawić się w końcowym LCP (web.dev).

Adres obrazu udostępnij w początkowym HTML przez src albo srcset, bo adres schowany wyłącznie w data-src, który odczyta dopiero skrypt, przeglądarka odkryje za późno.

Strona testowa była syntetyczna i bez sieci, więc różnicę robi głównie narzucony timer, ale na prawdziwej stronie mechanizm jest ten sam.

Obrazu LCP nie ładuj leniwie (loading="lazy"), bo przeglądarka odłoży jego pobieranie. Ważnemu zasobowi pierwszego ekranu fetchpriority="high" pomaga dostać odpowiedni priorytet, ale to tylko wskazówka 8. Stosuj go oszczędnie, bo przy masowym użyciu zasoby zaczną ze sobą konkurować.

Dobierz wymiary, format i jakość obrazu

Porównaj obecny plik z WebP i AVIF przy jakości dobranej do grafiki i obejrzyj drobny tekst oraz krawędzie. Przy gradientach i przezroczystości PNG albo SVG bywa lepszy, a web.dev przestrzega przed zakładaniem stałego procentu oszczędności.

Telefon potrzebuje czasem obrazu o większej liczbie pikseli niż jego szerokość w CSS, bo liczy się miejsce w układzie i gęstość ekranu. srcset podaje kandydatów, a sizes opisuje szerokość wyświetlania. Przy błędnych wartościach same atrybuty nic nie dadzą (MDN).

Przykład dla obrazu o maksymalnej szerokości 1120 px i marginesach po 20 px na mniejszym ekranie (nazwy plików są przykładowe):

<img
  class="hero-image"
  src="/images/produkt-1200.webp"
  srcset="/images/produkt-640.webp 640w,
          /images/produkt-1200.webp 1200w,
          /images/produkt-1920.webp 1920w"
  sizes="(min-width: 1160px) 1120px, calc(100vw - 40px)"
  width="1200"
  height="800"
  loading="eager"
  fetchpriority="high"
  alt="Widok produktu z otwartą komorą główną"
>

.hero-image {
  display: block;
  width: calc(100% - 40px);
  max-width: 1120px;
  height: auto;
  margin-inline: auto;
}

Ten CSS zakłada rodzica na pełną szerokość, bez paddingu, więc w prawdziwym komponencie dopasuj sizes do układu, nigdy odwrotnie.

Sprawdź efekt w panelu Network i w zapisie Performance. Przeglądarka wybiera właściwy plik, żądanie startuje wcześniej albo transfer jest mniejszy, a LCP w porównywalnych testach się nie pogarsza. Preload dodaj dopiero wtedy, gdy potwierdzisz, że obraz jest odkrywany późno, bo zbędne wskazówki konkurują z innymi zasobami.

Krok 2: Skróć odpowiedź serwera (TTFB) i dobierz bezpieczny cache

Opóźnienie sprzed otrzymania HTML skracasz na serwerze, bo kompresja zdjęć go nie ruszy.

Web.dev wymienia przyczyny wysokiego TTFB: przekierowania, zestawianie połączenia, odległość, chybienie w cache i pracę aplikacji, a droższy hosting leczy tylko część z nich.

Sprawdź czas generowania odpowiedzi, zapytania do bazy i zależności od zewnętrznych API. Treści niezmienne między wizytami prerenderuj albo trzymaj w cache odpowiedzi. Trafienia i chybienia zapisuj osobno, bo różnica między nimi mówi więcej niż logo CDN w panelu hostingu.

Cache przeglądarki i CDN wykonują różne zadania

Cache przeglądarki pozwala temu samemu użytkownikowi ponownie użyć pobranych zasobów, a cache współdzielony, np. CDN, odpowiada także komuś, kto wchodzi pierwszy raz. Efekt zależy od tego, co faktycznie przechowuje (MDN), więc to sprawdź.

no-store zabrania przechowywania odpowiedzi w cache, do którego dyrektywa ma zastosowanie (MDN). Koszyk i konto klienta trzymaj poza publicznym cache, bo samo cookie w odpowiedzi nie chroni jej przed cache współdzielonym.

Sprawdź efekt na pierwszej wizycie, powrocie, aktualizacji wersji oraz przy logowaniu i wylogowaniu. Nagłówki i trafienia w cache są właściwe, nowe pliki pojawiają się po wdrożeniu, a nikt nie dostaje cudzej treści. Rocznego cache nie odwołasz później samą zmianą nagłówka na serwerze.

Krok 3: Wytnij zbędny JavaScript i CSS, potem sprawdź kompresję

Najwięcej zyskujesz na kodzie pobieranym bez potrzeby, np. gdy strona artykułu ładuje edytor, bibliotekę wykresów albo obsługę formularza używaną gdzie indziej. Podział paczek według podstron i funkcji ogranicza pracę na starcie.

Przyznam się do wpadki na stronie głównej cometweb.io: najpierw odroczyłem arkusze CSS i zyskałem około 0,1 s na pierwszym wyświetleniu, a LCP stał w miejscu.

Hamulcem był JavaScript, więc wyciąłem z kodu przed pierwszym renderem słownik i tabelę meta. JS przed pierwszym renderem spadł wtedy z 329 do 208 KB (gzip), a LCP w laboratoryjnym teście Lighthouse (symulowany profil mobilny) z 6,39 do 5,46 s. Całą diagnozę opisałem w porównaniu danych laboratoryjnych i CrUX.

Panel Coverage w DevTools pokazuje nieużywany kod tylko w nagranym scenariuszu (dokumentacja). Zanim usuniesz reguły, otwórz menu, wywołaj błąd formularza i sprawdź wersję mobilną.

Mały krytyczny CSS możesz wstawić w HTML, ale całego arkusza tam nie przenoś, bo powiększysz dokument i stracisz osobne cache'owanie. Stylów pierwszego ekranu nie odkładaj, bo użytkownik zobaczy nieostylowaną treść albo przesunięcie układu 7.

defer przesuwa wykonanie skryptu, koszt zostaje

Dla zewnętrznego klasycznego skryptu zależnego od dokumentu przydaje się:

<script src="/assets/menu.abc123.js" defer></script>

defer pozwala pobierać skrypt podczas parsowania HTML i wykonać go później, w kolejności skryptów odroczonych. async wykonuje skrypt zaraz po pobraniu, bez tej gwarancji. Skrypty type="module" są odroczone domyślnie (MDN).

Po zmianie sprawdź koszt parsowania i wykonania, bo skrypt może przestać blokować parser, a potem zablokować główny wątek, gdy użytkownik kliknie menu.

Nazwy z raportu: render-blocking resources, excessive DOM, enormous network payload

• Render-blocking resources to arkusze CSS i skrypty, które wstrzymują renderowanie głównej treści. Naprawiasz je krokami z tej sekcji.
• Excessive DOM to zbyt wiele elementów HTML. Duże drzewo podnosi koszt każdej zmiany układu i może spowalniać reakcję na kliknięcia (web.dev), więc upraszczaj zagnieżdżenia, usuwaj zbędne kopie komponentów i ogranicz listy renderowane od razu.
• Enormous network payload to za dużo danych przy pierwszym widoku. Pomaga kompresja obrazów, mniej fontów i bibliotek oraz treść spod pierwszego ekranu na żądanie (web.dev).

Dwa ostatnie łatwo pomylić, bo strona z małym transferem może mieć ogromny DOM generowany po stronie klienta, a wtedy kompresja niczego nie zmieni.

Minifikacja i kompresja to osobne kroki

Minifikacja skraca zapis kodu, a kompresja HTTP, np. Brotli albo gzip, zmniejsza przesyłaną odpowiedź tekstową. Niepotrzebną funkcję i tak trzeba usunąć, a obietnicy „20% szybszej strony” do żadnej z nich nie dopisuj 9.

W panelu Network sprawdź nagłówek 0 i porównaj rozmiar przesłany z rozmiarem po rozpakowaniu. WOFF2 i nowoczesne formaty obrazów mają własną kompresję, więc brak dodatkowego br przy takim pliku zwykle jest w porządku.

Sprawdź efekt w zapisie ładowania, który ma pokazać na danej podstronie mniej zbędnego kodu, bez regresji wyglądu i działania. Porównuj rozmiary po kompresji, bo pliki w katalogu projektu pokazują inną liczbę.

Krok 4: Popraw reakcję na kliknięcia (INP): długie zadania i skrypty zewnętrzne

INP mierzy, jak szybko strona reaguje na interakcję, a według web.dev liczy się w nim oczekiwanie na obsługę, sama obsługa i wyświetlenie kolejnej klatki.

Strona potrafi szybko pokazać produkt, a potem zawiesić się przy wyborze rozmiaru. Nagraj w panelu Performance konkretne czynności: otwarcie menu, filtr, dodanie do koszyka, walidację formularza. Szukaj ciężkich procedur obsługi, wielu zmian układu i zadań, które zajmują główny wątek (web.dev).

Pracę podziel na porcje i między nimi oddawaj przeglądarce czas na obsługę wejścia i renderowanie:

async function yieldToBrowser() {
  if (globalThis.scheduler?.yield) {
    await globalThis.scheduler.yield();
    return;
  }
  await new Promise(resolve => setTimeout(resolve, 0));
}

Wywołuj go w ciężkiej pętli, między porcjami pracy. await Promise.resolve() tu odpada, bo nie oddaje sterowania do nowego zadania. Pojedynczą bardzo drogą operację trzeba odchudzić albo wykonać inaczej. Próg 50 ms z poradnika o długich zadaniach definiuje długie zadanie, a budżet interakcji ustalasz osobno.

Rozłóż skrypty marketingowe w czasie

Czat, odtwarzacz, mapa, analityka i testy A/B dokładają pobieranie i wykonanie kodu. Zrób listę dostawców, podstron, na których są potrzebni, i momentów uruchomienia.

Przerzucenie wszystkiego na pierwszą interakcję może obciążyć przeglądarkę akurat wtedy. Przetestuj też stan po udzieleniu zgód, bo dochodzą wtedy kolejne integracje (web.dev). Przy długich listach wirtualizację testuj osobno dla każdej, także z klawiaturą i czytnikiem ekranu.

Sprawdź efekt. Wybrana interakcja działa płynniej w powtarzalnym scenariuszu, wynik operacji jest poprawny, a własne pomiary interakcji nie pokazują regresji. Niższy TBT w teście ładowania to użyteczny sygnał, choć o konkretnym INP nie przesądza 2.

Krok 5: Ogranicz fonty i dobierz sposób wyświetlania tekstu

Pobieraj tylko używane odmiany, w WOFF2, i świadomie wybierz, co czytelnik widzi przed ich pobraniem. W moim teście 13 fontów ze wstępu WOFF2 wygrywał nad samym Brotli tylko przy konturach TrueType, a cały pomiar opisałem w porównaniu WOFF2 i TTF.

Zapisz, jakich rodzin i grubości naprawdę używasz, i sprawdź, czy fonty nie przychodzą jednocześnie z własnego serwera i z zewnętrznego arkusza. Według web.dev WOFF2 to właściwy domyślny format dla współczesnych przeglądarek. Font variable porównuj z pełnym zestawem odmian, których potrzebujesz.

Przy subsettingu, czyli wycinaniu nieużywanych znaków, zachowaj znaki z treści i cen, a także z nazwisk i tłumaczeń. Oprócz polskiego alfabetu potrzebujesz m.in. €, „”, – i ….

font-display: swap szybko pokazuje font zastępczy, ale późniejsza podmiana może zmienić szerokość tekstu. optional może zostawić fallback na całą wizytę (MDN). Dopasuj metryki fontu zastępczego, a preload rodziny dodaj dopiero po pomiarze, ze zgodnym trybem żądania (crossorigin).

Sprawdź efekt w panelu Network i na gotowej stronie. Nic nie pobiera się podwójnie, a tekst ma poprawne znaki i odmiany i nie skacze. Mniejszy font to porażka, jeśli część treści wyświetla się przypadkowym fallbackiem.

Krok 6: Zarezerwuj miejsce na obrazy, reklamy i komunikaty (CLS)

CLS opisuje stabilność układu, czyli to, czy elementy strony przesuwają się bez ostrzeżenia. Według web.dev wynik liczy się z nieoczekiwanych przesunięć w oknach sesyjnych, także po pierwszym wyświetleniu strony.

Podawaj width i height obrazów zgodne z zasobem i utrzymuj proporcję w CSS. Dla osadzonych materiałów i reklam rezerwuj miejsce, zanim nadejdzie treść, z uwzględnieniem różnych rozmiarów reklam i kadrów mobilnych (web.dev).

Sprawdź baner zgód, błędy formularza, aktualizację koszyka i komunikaty nad listą produktów. Informacji potrzebnej użytkownikowi nie ukrywaj tylko po to, żeby poprawić liczbę.

Przykład kontrolowany: width i height zbiły CLS do zera bez szybszego obrazu

Przygotowałem dwa warianty lokalnej strony testowej, w których obraz pojawiał się po zadanym opóźnieniu 650 ms, ale tylko jeden miał width i height. Na każdy wariant i rozmiar widoku wykonałem po pięć prób w Chromium 144.0.7559.96.

LCP został przy ok. 708 ms, bo obraz czekał na identyczny timer, więc przyspieszenia nie ogłaszam.

Obraz był osadzony jako data:, więc eksperyment pomijał sieć, kompresję i CDN. To demonstracja mechanizmu: nie mierzyłem tu cometweb.io ani ruchu użytkowników i nie obiecuję takiego wyniku dla sklepu. Metodologię z próbami i kodem znajdziesz w materiale do odtworzenia testu.

Sprawdź efekt, obserwując układ przy wolno pojawiających się zasobach, po interakcjach i podczas przewijania. Jeden krótki test bez przesunięć mówi coś tylko o tym jednym stanie produktu.

Krok 7: Odłóż zasoby spod pierwszego ekranu (lazy loading)

Lazy loading, czyli leniwe ładowanie, stosuj do obrazów i ramek poza początkowym obszarem widoku. Zdjęcie niżej w artykule dostaje loading="lazy" i dalej ma wymiary. Według web.dev przeglądarka może zacząć pobieranie, gdy zasób zbliża się do ekranu.

<img
  src="/images/detal-produktu.webp"
  width="960"
  height="640"
  loading="lazy"
  alt="Zbliżenie szwu przy uchwycie produktu"
>

Mapę lub odtwarzacz umieszczony dalej na stronie można początkowo zastąpić lekkim podglądem z dostępnym przyciskiem uruchomienia. Sprawdź czas oczekiwania po pierwszym kliknięciu, ponieważ opóźnienie pobierania zasobów może przenieść się na moment interakcji 10.

Sprawdź efekt na całej ścieżce, bo liczy się transfer całej wizyty. Początkowe ładowanie ma pomijać zbędne zasoby, a przewijanie i pierwsze uruchomienie odroczonej funkcji mają działać.

Jak sprawdzić, czy poprawki przyspieszyły stronę

Sprawdzaj jedną hipotezę naraz, np. „obraz pojawia się późno, bo jego adres dodaje dopiero skrypt”, i porównuj przebiegi przed zmianą i po niej w tych samych warunkach. Jeśli wynik stoi w miejscu, sprawdź, czy pomiar w ogóle odtworzył problem i czy dalej dominuje inne ograniczenie 6.

Dla ważnej poprawki robię co najmniej pięć powtórzeń, choć Google tego nie wymaga. Przy kilku przebiegach to orientacja bez istotności statystycznej, ale do decyzji „wdrażać czy nie” wystarcza.

Porównuj medianę i zakres, a najwolniejszej próby „przed” nie zestawiaj z najszybszą „po”.

Wynik złożony Lighthouse traktuj pomocniczo wobec metryk (zasady punktacji). W moim teście czterech stron cometweb.io siedem prób dało zakresy wyniku od 4 do 10 punktów.

W zapisie testu zanotuj wszystko, co może zmienić wynik:

• URL i wersję wdrożenia,
• widok,
• narzędzie,
• warunki CPU i sieci,
• stan cache i zgód,
• stan logowania,
• wykonaną czynność.

Pliki HAR i logi mogą zawierać wrażliwe dane, więc przed udostępnieniem je usuń.

Po wdrożeniu przejdź funkcje krytyczne (logowanie, płatność, formularze, nawigacja, dostępność) i obserwuj własne pomiary oraz okresy CrUX. Zmiana struktury ruchu, używanych urządzeń lub kampanii może wpłynąć na wyniki pomiarów. Sama poprawa metryki wydajności nie dowodzi wzrostu konwersji.

Wyniki przed zmianą i po niej zapisuj w karcie pomiaru i retestu.

Kto w zespole prowadzi przyspieszanie strony

Zaczyna właściciel strony: wskazuje ważne ścieżki i zatwierdza, po czym poznacie, że poprawka zadziałała. Deweloper pracuje potem nad konkretnym żądaniem, komponentem albo interakcją. Na WordPressie zacznij od przeglądu motywu i wtyczek, potem warstw cache, zamiast dokładać narzędzia do tych samych zadań.

Dla jednego publicznego adresu użyj audytora wydajności CometWeb i odczytaj, jakie źródła były naprawdę dostępne: pomiary przeglądarkowe, dane terenowe czy tylko kontrole HTTP. Ma to znaczenie, bo LCP i INP zmierzy dopiero przeglądarka. Jak CometWeb oznacza dane laboratoryjne i terenowe, opisuje strona metodologii.

Moduł Performance w CometWeb Insight służy do pracy nad priorytetami i ponownych analiz całej strony:

• rozdziela dane terenowe CrUX (LCP, INP, CLS z 28 dni) od pomiaru laboratoryjnego,
• przy braku danych pokazuje N/D z wyjaśnieniem zamiast zera,
• wskazuje skrypty blokujące wątek i CSS blokujący renderowanie,
• trzyma historię pomiarów tego samego URL-a sprzed wdrożenia i po nim.

Trzy wnioski

1. Poprawki z listy to łatwa część. Trudniej ustalić, na co czeka użytkownik, a od tego zależy, co zrobisz najpierw.
2. Mniejszy plik skraca tylko jeden odcinek drogi. Font, obraz czy arkusz CSS przyspieszą stronę tylko wtedy, gdy blokowały to, na co czeka użytkownik.
3. Poprawkę potwierdza powtórzony pomiar. Wtyczka, nowy format obrazów czy 100 punktów w Lighthouse to hipoteza, dopóki pomiar jej nie potwierdzi.

W tym tygodniu otwórz raport Lighthouse dla najważniejszej strony, znajdź element LCP i zrób pięć przebiegów przed zmianą i pięć po. Dla wielu podstron naraz zacznij darmowy audyt w CometWeb Insight. Resztę powie mediana.

Najczęstsze pytania

Źródła i zakres

Liczby z cometweb.io w kroku 3: rozmiar JS przed pierwszym renderem (329 → 208 KB gzip) pochodzi z builda, a LCP 6,39 → 5,46 s z Lighthouse na produkcyjnej stronie głównej (symulowany profil mobilny, mediana 7 przebiegów, wrzesień 2026). To pomiar laboratoryjny, bo CrUX nie ma danych dla cometweb.io. Test fontów pochodzi z pakietu do porównania WOFF2 i TTF. Test obrazu i układu dotyczy wyłącznie opisanych lokalnych próbek. Poradnik nie zawiera danych GSC ani prognozy ruchu lub sprzedaży. Nazwy i ścieżki w przykładach kodu dopasuj do projektu.

1. Google Search Central: Understanding page experience in Google Search results.
2. web.dev: Web Vitals.
3. Google for Developers: About PageSpeed Insights.
4. Chrome for Developers: CrUX API.
5. Chrome for Developers: CrUX methodology.
6. web.dev: Why lab and field data can be different.
7. web.dev: Optimize Largest Contentful Paint.
8. web.dev: Optimize resource loading with the Fetch Priority API.
9. web.dev: General HTML performance considerations.
10. web.dev: Efficiently load third-party JavaScript.
11. web.dev: Best practices for fonts.
12. Chrome for Developers: Lighthouse performance scoring.