First Contentful Paint (FCP) w SEO
Co mierzy First Contentful Paint, jaki jest dobry wynik FCP, dlaczego nie jest to Core Web Vital, czym różni się od First Paint i LCP oraz jak naprawić wolne FCP.
Języki
First Contentful Paint (FCP) to czas od rozpoczęcia ładowania strony do momentu, gdy jakakolwiek jej treść — tekst, obraz, SVG lub niebiała płaszczyzna — zostanie po raz pierwszy wyrenderowana. Dobry wynik to ≤1,8 s na 75. percentylu rzeczywistych użytkowników. NIE jest to Core Web Vital: sygnały rankingowe to LCP, INP i CLS. FCP to metryka diagnostyczna (laboratoryjna i polowa), która jest elementem składowym LCP — występuje w tym samym czasie lub przed LCP — więc jest przydatna głównie do wykrywania zasobów blokujących renderowanie i wolnego TTFB. W Lighthouse 10 stanowi 10% wyniku Performance. Napraw to, eliminując blokujące renderowanie CSS/JS, skracając TTFB, osadzając krytyczny CSS, używając font-display: swap i wstępnie łącząc się z wymaganymi źródłami.
TL;DR — First Contentful Paint (FCP) to moment, w którym odwiedzający widzi pierwszy fragment Twojej strony — dowolny tekst, obraz lub grafikę — zamiast pustego białego ekranu. Im szybciej, tym lepiej; poniżej 1,8 sekundy to ocena „dobra”. To przydatna kontrola szybkości, ale nie jest to jedna z metryk, których Google używa do rankingu.
Czym właściwie jest FCP
Gdy ktoś kliknie link do Twojej strony, przez krótką chwilę patrzy na nic — pusty ekran — podczas gdy przeglądarka pobiera i przetwarza Twoją stronę. First Contentful Paint to moment, w którym pusty ekran zamienia się w coś realnego: nagłówek, logo, zdjęcie, cokolwiek, co odwiedzający może faktycznie zobaczyć.
To cała idea. FCP odpowiada na jedno proste pytanie: „Jak długo do momentu, aż użytkownik zobaczy, że strona żyje i coś robi?” Strona, która renderuje treść w pół sekundy, wydaje się szybka. Strona, która pozostaje pusta przez trzy sekundy, wydaje się zepsuta — i ludzie ją opuszczają.
Evidence for this claim FCP measures from navigation until the first text, image, SVG, or non-white canvas content is rendered. Scope: Current web.dev FCP definition and qualifying content types. Confidence: high · Verified: web.dev: First Contentful PaintCo liczy się jako „treść”
FCP jest wyzwalane, gdy przeglądarka rysuje na ekranie którykolwiek z tych elementów:
- Tekst (nagłówek, akapit, link nawigacyjny)
- Obrazy, w tym obrazy tła
- Grafika
<svg> - Element niebiały
<canvas>
Sam jednolity kolor tła nie liczy się — to inna, wcześniejsza rzecz zwana First Paint. FCP liczy się dopiero, gdy pojawi się prawdziwa treść.
Jaki wynik jest dobry?
Progi Google, mierzone wśród prawdziwych odwiedzających:
| Czas FCP | Ocena |
|---|---|
| 1,8 sekundy lub mniej | Dobra |
| 1,8 – 3,0 sekundy | Wymaga poprawy |
| Ponad 3,0 sekundy | Słaba |
Swój FCP zobaczysz w narzędziach takich jak PageSpeed Insights i Lighthouse — w tych samych raportach, które pokazują Twoje Core Web Vitals.
Czy FCP wpływa na moje pozycje w Google?
Nie — nie bezpośrednio. To część, którą większość ludzi rozumie źle. Metryki, których Google faktycznie używa do rankingu, to trzy Core Web Vitals: LCP, INP i CLS. FCP nie jest jedną z nich.
Ale oto dlaczego wciąż warto na niego patrzeć: rzeczy, które spowalniają FCP — wolny serwer, duże arkusze stylów i skrypty blokujące rysowanie strony — często są tymi samymi rzeczami, które szkodzą Largest Contentful Paint (LCP), który jest sygnałem rankingowym. Więc naprawianie przyczyn źródłowych FCP często pomaga również LCP — ale to nie jest gwarancja, ponieważ LCP ma własne przyczyny (rozmiar i priorytet ładowania jego konkretnego największego elementu). Myśl o FCP jak o czujniku dymu: warto sprawdzić, ale to nie dowód, że ogień zgasł.
Szybkie poprawki
Jeśli Twój FCP jest wolny, oto zwykli podejrzani (i co zrobić):
- Pliki blokujące renderowanie. CSS i JavaScript w sekcji
<head>Twojej strony mogą zatrzymać przeglądarkę przed narysowaniem czegokolwiek, dopóki nie zakończą ładowania. To przyczyna #1. - Wolny serwer. Jeśli Twój serwer długo odpowiada (wysoki Time to First Byte), przeglądarka nie może malować, dopóki bajty nie dotrą.
- Czcionki ukrywające Twój tekst. Niektóre konfiguracje czcionek pozostawiają tekst niewidoczny nawet przez trzy
sekundy, podczas gdy czcionka internetowa się ładuje. Zmiana reguły na
font-display: swappokazuje tekst zastępczy natychmiast.
Chcesz wersję techniczną — różnicę między laboratorium a polem, łańcuch diagnostyczny FCP/LCP i pełną listę poprawek? Przełącz się na zakładkę Zaawansowane.
TL;DR — FCP to czas od rozpoczęcia nawigacji do momentu, gdy jakakolwiek treść strony (tekst, obraz,
<svg>lub niebiały<canvas>) zostanie po raz pierwszy wyrenderowana. To nie jest Core Web Vital — to uzupełniająca, laboratoryjna i polowa metryka diagnostyczna oraz element budulcowy LCP (FCP występuje w tym samym czasie co LCP lub wcześniej). Progi polowe (p75): dobrze ≤ 1,8 s, wymaga poprawy ≤ 3,0 s, słabo > 3,0 s. W Lighthouse 10 to 10 % wyniku wydajności. Ponieważ zegar FCP zaczyna się od nawigacji — obejmuje czas przekierowań, konfigurację połączenia i TTFB — wyniki laboratoryjne (Lighthouse) i polowe (CrUX) często się różnią. Napraw to tam, gdzie to występuje: najpierw blokujące renderowanie CSS/JS, potem TTFB, a na końcu czcionki.
Co dokładnie mierzy FCP
Definicja Google z artykułu Philipa Waltona na web.dev jest tutaj osią dokładności: FCP mierzy czas od rozpoczęcia nawigacji do chwili wyrenderowania na ekranie dowolnej części treści strony. W tym samym ujęciu „treść” obejmuje tekst, obrazy — także obrazy tła — elementy <svg> oraz niebiałe elementy <canvas>; dosłowne brzmienie źródła pozostaje w sekcji cytatów.
Słowem, które robi całą robotę, jest any. FCP nie dba o to, co się renderuje — logo o szerokości 40 pikseli liczy się tak samo jak pełny obraz hero. To sygnał “czy cokolwiek jest już na ekranie?”, co jest dokładnie powodem, dla którego jest to wskaźnik wczesny, a nie metryka ukończenia.
Evidence for this claim FCP measures from navigation until the first text, image, SVG, or non-white canvas content is rendered. Scope: Current web.dev FCP definition and qualifying content types. Confidence: high · Verified: web.dev: First Contentful PaintJeden szczegół, który łatwo przeoczyć i który zmienia sposób odczytu liczby: zegar FCP zaczyna liczyć od nawigacji, więc obejmuje wszystko, co dzieje się zanim Twój HTML zostanie w ogóle sparsowany. Kluczowy punkt Google: pomiar FCP obejmuje czas zwalniania poprzedniej strony, nawiązywania połączenia, przekierowań i Time To First Byte (TTFB), który może mieć znaczenie w pomiarach polowych. Serwer, który odpowiada w 1,5 s, już wykorzystał większość Twojego budżetu 1,8 s, zanim przeglądarka przetworzyła choć jeden bajt.
FCP NIE jest Core Web Vital
Powiem wprost, bo większość stron to zamazuje: FCP nie jest Core Web Vital i nie jest częścią sygnałów rankingowych Google. Core Web Vitals to LCP, INP i CLS — a FCP nie jest wymienione nigdzie na stronie Google Search ranking Core Web Vitals.
Czym FCP jest w taksonomii Google, to „Other Web Vital” — metryka uzupełniająca przydatna w diagnozie. Zgodnie z web.dev zarówno TTFB, jak i FCP są ważnymi aspektami doświadczenia ładowania oraz pomagają diagnozować problemy z LCP: odpowiednio wolną odpowiedź serwera i zasoby blokujące renderowanie. Dosłowny cytat znajduje się w sekcji źródłowej.
Zatem uczciwe ramy dla interesariuszy są dwustronne i powinieneś przedstawić obie połowy bez wahania:
- FCP nie wpływa bezpośrednio na ranking. Nie optymalizuj FCP “pod SEO”.
- FCP to świetne narzędzie diagnostyczne dla LCP, które wpływa na ranking. Zasoby blokujące renderowanie pojawiają się w FCP jako pierwsze.
FCP a First Paint (FP)
Te dwa są ciągle mylone:
- First Paint (FP) odpala, gdy przeglądarka maluje cokolwiek — w tym sam kolor tła bez żadnej rzeczywistej treści.
- FCP odpala tylko wtedy, gdy renderuje się kwalifikująca treść: tekst, obrazy (w tym
obrazy tła), elementy
<svg>lub nie-białe elementy<canvas>. To konkretna, zdefiniowana w specyfikacji lista — a nie luźna zasada “dowolna treść DOM” — i warto zachować precyzję, ponieważ obraz tła się liczy, nawet jeśli nie jest tekstem w DOM.
Zatem FP ≤ FCP, zawsze. Na większości stron są prawie identyczne, ponieważ malowanie
koloru tła bez treści na wierzchu jest rzadkie. Gdy jest znacząca różnica, zwykle
oznacza to kosmetyczne tło pomalowane przed jakąkolwiek prawdziwą treścią. Interfejs Paint
Timing API zwraca zarówno wpisy first-paint, jak i first-contentful-paint — ale FCP jest
tym, który warto analizować; FP rzadko mówi ci coś, co można wykorzystać.
FCP a LCP
Druga para, którą ludzie łączą:
- FCP = kiedy jakakolwiek treść się maluje. Odpala wcześnie. Może to być małe logo lub link nawigacyjny.
- LCP = kiedy renderuje się największy element w viewporcie. Odpala w tym samym czasie co FCP lub po nim.
Sformułowanie Google: FCP mierzy, kiedy jakakolwiek treść zostanie namalowana, a LCP, kiedy główna treść zostanie namalowana, więc LCP ma być bardziej selektywne. Czytaj to jako „bardziej selektywne”, a nie „potwierdzone jako poprawne” — żadna z tych metryk nie dowodzi, że faktyczna główna treść strony jest kompletna lub użyteczna dla odwiedzającego. FCP po prostu potwierdza, że coś kwalifikującego się zostało namalowane; LCP potwierdza, że największy kwalifikujący się kandydat to zrobił. Strona może mieć szybkie FCP (logo po 0,5 s) i wolne LCP (obraz hero po 4 s) — ta różnica sama w sobie jest użytecznym wskaźnikiem diagnostycznym. A jeśli Twoje FCP jest bliskie LCP, to często dobry znak: oznacza to, że pierwsza namalowana rzecz jest również największa, bez marnowania wczesnego malowania na elementy interfejsu, które nie mają znaczenia dla użytkownika.
Evidence for this claim FCP answers when any eligible content first appears, while LCP tracks the largest eligible viewport candidate; neither metric proves the page's main content is complete or useful. Scope: field and lab Confidence: high · Verified: First Contentful Paint (FCP)Jedna osobliwość pomiarowa, o której warto wiedzieć: z powodu ograniczeń bezpieczeństwa dotyczących pomiaru czasu obrazów z innych źródeł, API przeglądarki może w rzadkich przypadkach zgłosić LCP wcześniej niż FCP. To artefakt pomiarowy, a nie coś, co fizycznie miało miejsce.
Progi — i dlaczego laboratorium i pole się różnią
Progi terenowe (CrUX, p75): Dobry ≤ 1,8 s · wymaga poprawy ≤ 3,0 s · słaby > 3,0 s. Wytyczne Google mówią, aby mierzyć na 75. percentylu ładowań stron, oddzielnie dla urządzeń mobilnych i komputerów stacjonarnych.
Evidence for this claim A good FCP is 1.8 seconds or less at the 75th percentile; above 3 seconds is poor. Scope: Current web.dev FCP field thresholds. Confidence: high · Verified: web.dev: First Contentful PaintAle Lighthouse desktop używa innych, ostrzejszych progów — zielony to około 0–0,9 s, pomarańczowy 0,9–1,6 s, czerwony powyżej 1,6 s — ponieważ laboratorium uruchamia czystą, ograniczoną przeglądarkę Chrome na symulowanym urządzeniu, a nie w warunkach rzeczywistych. (Te zakresy, podobnie jak wagi wyników poniżej, są specyficzne dla wersji Lighthouse — odzwierciedlają aktualny dokument audytu w momencie pisania.) Wynik FCP w Lighthouse to „porównanie czasu FCP Twojej strony z czasami FCP rzeczywistych witryn, oparte na danych z HTTP Archive”.
To najczęstsze źródło nieporozumień dotyczących FCP, więc zapamiętaj to:
Linia „dobry” 1,8 s to próg terenowy (CrUX p75). Linia „zielona” w Lighthouse desktop to ~0,9 s. To różne skale do różnych zadań.
Wyniki laboratoryjne i terenowe różnią się głównie dlatego, że próbkują różne populacje, a nie dlatego, że jedno jest uniwersalnie „bardziej prawdziwe”. Lighthouse uruchamia pojedynczą czystą sesję na stałych warunkach urządzenia/sieci. Pole/CrUX agreguje rzeczywiste urządzenia, rzeczywiste sieci, stany pamięci podręcznej i typy nawigacji — w tym przywracanie z pamięci podręcznej wstecz/do przodu i wstępnie renderowane strony, które nie automatycznie otrzymują świeżego FCP tak jak normalna nawigacja; wymagają one własnego zarządzania cyklem życia (biblioteka web-vitals robi to za Ciebie). Na większości stron liczba terenowa faktycznie jest wyższa — prawdziwi użytkownicy mają łańcuchy przekierowań, czas rozładowania poprzedniej strony i zimne połączenia, które sesja laboratoryjna pomija — ale to tendencja, a nie reguła. Zanim zinterpretujesz różnicę laboratorium/pole jako problem, sprawdź, czy porównujesz porównywalne rzeczy (ta sama klasa urządzeń, te same warunki sieciowe). Używaj danych terenowych do rzeczywistej liczby, a Lighthouse do diagnozy.
Gdzie FCP znajduje się w wyniku Lighthouse
W Lighthouse 10 — aktualnej wersji w momencie pisania, a nie stałej wartości — FCP stanowi 10% wyniku Performance. Pełna waga:
| Metryka | Waga |
|---|---|
| Total Blocking Time (TBT) | 30% |
| Largest Contentful Paint (LCP) | 25% |
| Cumulative Layout Shift (CLS) | 25% |
| First Contentful Paint (FCP) | 10% |
| Speed Index | 10% |
Wynik Performance to średnia ważona indywidualnych wyników metryk, a Google zauważa, że wagi zmieniają się z czasem w miarę ewolucji ich badań — FCP utrzymywało się na poziomie 10% od Lighthouse 8 do 10, ale potwierdź to w wersji, której używasz, zanim potraktujesz „10%” jako niezmienne. Praktyczny wniosek: idealne FCP może przesunąć Twój wynik Lighthouse tylko w pewnym zakresie — a złe FCP często wskazuje na złe LCP (mają wspólne przyczyny źródłowe), choć to nakładanie się warto sprawdzić, a nie coś, co wynik gwarantuje.
Co powoduje wolne FCP
W przybliżonej kolejności priorytetów:
- Zasoby blokujące renderowanie — zabójca numer jeden. CSS i synchroniczny JS w
<head>zmuszają przeglądarkę do czekania: nie może zbudować CSSOM i drzewa renderowania, więc nie może namalować niczego, dopóki te pliki nie zostaną pobrane i przeanalizowane. - Wysoki TTFB — FCP nie może wystąpić, zanim nie nadejdą bajty. Wolny serwer to pierwsze domino i jest wewnątrz pomiaru FCP.
- Łańcuchy przekierowań — każde przekierowanie to pełna podróż w obie strony dodana przed pierwszym bajtem.
- Strategia ładowania czcionek internetowych —
font-display: block(lub brak reguły) może pozostawić tekst niewidocznym przez nawet ~3 sekundy. Nawet jeśli malowanie technicznie nastąpi w tle, użytkownik nie widzi niczego użytecznego.
Jak to naprawić
Pełna lista, ale z priorytetami, których dokumentacja nie podaje. To typowe dźwignie, nie uniwersalne — najpierw sprawdź własny ślad lub film, aby zobaczyć, który zasób lub faza faktycznie opóźnia Twój kandydat FCP, zanim sięgniesz po poprawki (preconnect, preload, zmiana font-display), które mogą nie dotyczyć Twojej strony:
Zrób to najpierw (największe zyski):
- Wyeliminuj CSS i JavaScript blokujące renderowanie. Wstaw krytyczny CSS dla treści nad zakładką
bezpośrednio w
<head>; resztę ładuj asynchronicznie; dodajasync/deferdo niekrytycznych skryptów. Przeniesienie tagu<link>nie pomaga — przeglądarka nie namaluje, dopóki cały CSS nie zostanie załadowany i przeanalizowany, niezależnie od tego, gdzie znajduje się tag. - Zmniejsz TTFB (czas odpowiedzi serwera). Pamięć podręczna, CDN, szybsze źródło — wszystko, co sprawi, że pierwszy bajt pojawi się szybciej, bezpośrednio skraca FCP.
- Napraw ładowanie czcionek. Użyj
font-display: swap(natychmiast pokazuje tekst zastępczy, zamienia na czcionkę internetową, gdy będzie gotowa) lubfont-display: optional(pomija czcionkę internetową, jeśli nie jest już w pamięci podręcznej). Unikajfont-display: blockdla krytycznego tekstu — to najgorsze dla FCP.
Potem uporządkuj resztę:
- Preconnect do wymaganych źródeł za pomocą
<link rel="preconnect">— wczesne nawiązywanie połączeń z ważnymi źródłami zewnętrznymi może zaoszczędzić 100–500 ms. - Preload kluczowych żądań (
<link rel="preload">) dla krytycznej czcionki lub obrazu LCP. - Minifikuj CSS, usuń nieużywany CSS, usuń nieużywany JavaScript — mniejsze pliki parsują się i odblokowują malowanie szybciej.
- Unikaj wielu przekierowań, unikaj ogromnych ładunków sieciowych, serwuj statyczne zasoby z wydajną polityką pamięci podręcznej, unikaj nadmiernego rozmiaru DOM i minimalizuj krytyczną głębokość żądań. Ogólna higiena ładunku, która wszystko zasila pierwsze malowanie.
Łańcuch diagnostyczny FCP → TTFB → LCP
Tak faktycznie użyłbym FCP i to jest rama, którą dokumentacja sugeruje, ale nie rozwija. Traktuj trzy metryki ładowania jako jeden przepływ pracy:
- FCP jest wysokie → sprawdź zasoby blokujące renderowanie (CSS/JS w
<head>). To najczęstsza przyczyna i najszybsza wygrana. - Sprawdź też TTFB — ponieważ FCP je zawiera, wolny serwer zawyża FCP, zanim jakiekolwiek blokowanie renderowania w ogóle wejdzie w grę. Wskazówka web.dev: ponieważ TTFB poprzedza zarówno FCP, jak i LCP, Twój serwer powinien odpowiadać na tyle szybko, aby 75. percentyl użytkowników osiągał “dobre” FCP.
- Te same problemy często kaskadują do LCP — metryki, która jest faktycznym sygnałem rankingowym — ponieważ FCP i LCP często mają wspólne przyczyny źródłowe. To nakładanie się warto sprawdzić, ale to nie gwarancja: LCP ma własne czynniki (rozmiar, priorytet i ścieżka ładowania swojego konkretnego największego elementu), więc naprawienie przyczyn FCP nie obiecuje naprawionego LCP. To właściwe pierwsze miejsce do szukania, nie ostatni krok.
To jest wartość FCP dla SEO: to tani, wczesny odczyt, czy ścieżka ładowania jest zdrowa, zanim bardziej selektywny pomiar LCP w ogóle się zakończy.
Podsumowanie AI
Skrócona wersja wersji zaawansowanej:
- FCP = czas od rozpoczęcia nawigacji do momentu, gdy jakakolwiek treść pojawi się po raz pierwszy — tekst, obrazy (w tym tła),
<svg>lub niebiały<canvas>. To sygnał „czy cokolwiek jest już na ekranie?”. - FCP NIE jest podstawową wskaźnikiem internetowym (Core Web Vital). Sygnałami rankingowymi są LCP, INP, CLS. FCP to uzupełniający, laboratoryjny i terenowy diagnostyczny wskaźnik — nie bezpośredni czynnik rankingowy.
- To element składowy LCP (FCP występuje przed LCP lub w tym samym czasie), więc często wychwytuje te same zasoby blokujące renderowanie i wolne TTFB, które szkodzą LCP — co wpływa na rankingi — ale naprawienie przyczyn FCP nie gwarantuje naprawy LCP; LCP ma własne czynniki.
- Progi terenowe (CrUX p75): Dobry ≤ 1,8 s · wymaga poprawy ≤ 3,0 s · słaby > 3,0 s.
- Laboratorium ≠ teren, a „teren jest zawsze wyższy” to tendencja, nie reguła. Linia „zielona” ~0,9 s w Lighthouse na desktopie jest bardziej rygorystyczna niż próg terenowy 1,8 s, ponieważ to jeden czysty przebieg w stałych warunkach; teren/CrUX agreguje rzeczywiste urządzenia, sieci, stany pamięci podręcznej i typy nawigacji (w tym przywracanie z bfcache i wstępnie renderowane strony). Dopasuj populacje, zanim odczytasz różnicę jako problem — używaj terenu dla rzeczywistej liczby, laboratorium do diagnozy.
- FCP vs FP: First Paint występuje przy każdym malowaniu (nawet kolorze tła); FCP wymaga kwalifikującej się treści (tekst, obrazy, w tym obrazy tła, SVG, niebiały canvas). FP ≤ FCP zawsze.
- FCP vs LCP: FCP = jakakolwiek kwalifikująca się treść; LCP = największy kwalifikujący się kandydat. Żaden nie dowodzi, że prawdziwa główna treść strony jest kompletna lub użyteczna — to proxy. Szybkie FCP + wolne LCP to realna, częsta luka.
- Waga w Lighthouse 10 (aktualna w momencie pisania): 10% — TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%; wagi zmieniają się między wersjami Lighthouse.
- Najlepsze poprawki w kolejności: wyeliminuj CSS/JS blokujące renderowanie → zmniejsz TTFB → napraw czcionki (
font-display: swap/optional) → preconnect/preload → minifikacja/pamięć podręczna/higiena DOM.
Oficjalna dokumentacja
Podstawowa dokumentacja na temat FCP od Google.
web.dev (Google)
- First Contentful Paint (FCP) — kanoniczna definicja Philipa Waltona, lista „co liczy się jako treść”, próg 1,8 s, kluczowy punkt o TTFB/przekierowaniach oraz jak mierzyć FCP za pomocą Paint Timing API i biblioteki web-vitals.
- Web Vitals — gdzie znajduje się FCP: „inny wskaźnik internetowy”, uzupełniający podstawowe wskaźniki internetowe (LCP, INP, CLS), przydatny do diagnozowania LCP.
- Largest Contentful Paint (LCP) — rozróżnienie FCP vs LCP i jak te dwa wskaźniki się odnoszą.
- Time to First Byte (TTFB) — dlaczego TTFB poprzedza (i jest zawarte w) FCP.
- User-centric performance metrics — klasyfikacja FCP jako wskaźnika zarówno laboratoryjnego, jak i terenowego.
Lighthouse / Chrome Developers
- First Contentful Paint audit — pasma ocen desktopowych Lighthouse (zielony ≤ 0,9 s) i jak wynik FCP jest obliczany na podstawie danych HTTP Archive.
- Lighthouse performance scoring — wagi wskaźników, w tym FCP na 10% wyniku wydajności w Lighthouse 10.
Google Search Central
- Core Web Vitals & Google Search — strona rankingowa; wymienia LCP, INP i CLS. FCP nie jest na niej, co jest sednem.
Cytaty ze źródła
Oświadczenia na piśmie z dokumentacji Google. Każdy link to link bezpośredni, który przenosi do cytowanego fragmentu na stronie źródłowej.
web.dev — definicja
- “First Contentful Paint (FCP) measures the time from when the user first navigated to the page to when any part of the page’s content is rendered on the screen.” (tłumaczenie) „First Contentful Paint (FCP) mierzy czas od momentu, gdy użytkownik po raz pierwszy przejdzie do strony, do momentu, gdy jakakolwiek część jej treści zostanie wyrenderowana na ekranie.” — Philip Walton, First Contentful Paint (FCP), web.dev (zaktualizowano 6 grudnia 2023). Przejdź do cytatu
web.dev — próg
- “sites should strive to have a First Contentful Paint of 1.8 seconds or less.” (tłumaczenie) „witryny powinny dążyć do tego, aby First Contentful Paint wynosił 1,8 sekundy lub mniej.” — to samo źródło. Przejdź do cytatu
web.dev — co obejmuje FCP (kluczowy punkt)
- “FCP includes any unload time from the previous page, connection set up time, redirect time, and Time To First Byte (TTFB) which can be significant when measured in the field.” (tłumaczenie) „FCP obejmuje czas zwalniania poprzedniej strony, czas nawiązywania połączenia, czas przekierowań oraz Time To First Byte (TTFB), które mogą być znaczące przy pomiarach w terenie.” — to samo źródło.
web.dev — rola FCP względem Core Web Vitals
- “the metrics Time to First Byte (TTFB) and First Contentful Paint (FCP) are both vital aspects of the loading experience, and are both useful in diagnosing issues with LCP (slow server response times or render-blocking resources, respectively).” (tłumaczenie) „metryki Time to First Byte (TTFB) i First Contentful Paint (FCP) są kluczowymi aspektami doświadczenia ładowania i obie są przydatne w diagnozowaniu problemów z LCP (odpowiednio wolne czasy odpowiedzi serwera lub zasoby blokujące renderowanie).” — Web Vitals, web.dev. Przejdź do cytatu
Lighthouse — jak obliczany jest wynik FCP
- “Your FCP score is a comparison of your page’s FCP time and FCP times for real websites, based on data from the HTTP Archive.” (tłumaczenie) „Twój wynik FCP to porównanie czasu FCP Twojej strony z czasami FCP rzeczywistych witryn, na podstawie danych z HTTP Archive.” — First Contentful Paint audit, developer.chrome.com.
Lighthouse — jak działa wynik Performance
- “The Performance score is a weighted average of the metric scores.” (tłumaczenie) „Wynik Performance to średnia ważona wyników poszczególnych metryk.”
- “The weightings have changed over time because the Lighthouse team is regularly doing research and gathering feedback to understand what has the biggest impact on user-perceived performance.” (tłumaczenie) „Wagi zmieniały się z czasem, ponieważ zespół Lighthouse regularnie prowadzi badania i zbiera opinie, aby zrozumieć, co ma największy wpływ na wydajność odbieraną przez użytkownika.” — Lighthouse performance scoring, developer.chrome.com.
#:~:text=; zweryfikuj je na żywych stronach przed uznaniem jakiegokolwiek cytatu za ostateczny. Wagi Lighthouse są cytowane dla Lighthouse 10 — zweryfikuj ponownie, jeśli pojawiła się nowsza wersja Lighthouse. Lista kontrolna triażu wolnego FCP
Gdy FCP jest wysokie, przejdź przez tę listę w podanej kolejności — mniej więcej od największego zysku do najmniejszego:
- Sprawdź liczbę field, nie tylko Lighthouse. Przeczytaj p75 z CrUX/PageSpeed Insights dla prawdziwego FCP; używaj Lighthouse tylko do diagnozy.
- Poszukaj zasobów blokujących renderowanie. CSS i synchroniczny JS w
<head>to główna przyczyna — audyt Lighthouse „Eliminate render-blocking resources” je wymienia. - Wbuduj krytyczny CSS powyżej linii zagięcia; resztę ładuj asynchronicznie.
- Dodaj
async/deferdo niekrytycznych skryptów; przenieś tagi stron trzecich po pierwszym malowaniu. - Zmierz TTFB. Jest wewnątrz FCP — wolny serwer zawyża FCP przed czymkolwiek innym. Dodaj cache / CDN / szybszy origin.
- Usuń łańcuchy przekierowań — każdy przeskok to pełna podróż w obie strony przed pierwszym bajtem.
- Napraw czcionki: użyj
font-display: swapluboptional; nigdyblockdla krytycznego tekstu. Wstępnie załaduj krytyczny plik czcionki. - Preconnect do wymaganych originów stron trzecich; preload obrazu LCP / kluczowych żądań.
- Zmniejsz ładunek: minifikuj CSS, usuń nieużywany CSS/JS, efektywna polityka cache, mniejszy DOM, krótsza głębokość krytycznych żądań.
- Sprawdź ponownie LCP po zmianach — te same poprawki powinny go przesunąć, a LCP to ten, który wpływa na rankingi.
Ściąga FCP
Progi terenowe (CrUX, 75. percentyl)
| Czas FCP | Ocena |
|---|---|
| ≤ 1,8 s | Dobry |
| 1,8 – 3,0 s | Wymaga poprawy |
| > 3,0 s | Słaby |
Ocena desktopowa Lighthouse (laboratorium — uwaga: ostrzejsza niż terenowa)
| Czas FCP | Kolor |
|---|---|
| 0 – 0,9 s | Zielony (szybki) |
| 0,9 – 1,6 s | Pomarańczowy (umiarkowany) |
| Ponad 1,6 s | Czerwony (wolny) |
Wagi wyniku wydajności Lighthouse 10 (aktualne w chwili pisania — wagi zmieniają się między wersjami Lighthouse)
| Metryka | Waga |
|---|---|
| Całkowity czas blokowania | 30 % |
| Największe malowanie treści | 25 % |
| Skumulowane przesunięcie układu | 25 % |
| Pierwsze malowanie treści | 10 % |
| Indeks szybkości | 10 % |
Trzy metryki ładowania, rozplątane
| Metryka | Wyzwala się, gdy… | Core Web Vital? |
|---|---|---|
| Pierwsze malowanie (FP) | przeglądarka maluje cokolwiek, nawet kolor tła | Nie |
| Pierwsze malowanie treści (FCP) | jakakolwiek prawdziwa treść się maluje (tekst/obraz/SVG/canvas) | Nie (diagnostyczna) |
| Największe malowanie treści (LCP) | największy element viewportu się renderuje | Tak |
Kolejność zdarzeń: FP ≤ FCP ≤ LCP.
Co liczy się jako „treść” dla FCP
tekst · obrazy (w tym obrazy tła) · elementy <svg> · nie-białe elementy <canvas>
Szybkie fakty
- Zegar FCP zaczyna się od nawigacji — obejmuje czas przekierowania, konfigurację połączenia i TTFB.
- FCP jest mierzalne zarówno w laboratorium, jak i w terenie.
font-display: używajswap/optional; unikajblock(niewidoczny tekst do ~3 s).- Preconnect do originów stron trzecich może zaoszczędzić 100–500 ms.
Narzędzia do pomiaru FCP
Dane terenowe (od prawdziwych użytkowników)
- PageSpeed Insights — pokazuje p75 FCP z CrUX dla Twojego URL (terenowe) obok przebiegu Lighthouse (laboratoryjnego).
- Chrome User Experience Report (CrUX) — zbiór danych od prawdziwych użytkowników stojący za liczbami terenowymi, dostępny przez API lub BigQuery.
- Biblioteka JavaScript web-vitals — wstaw
onFCP(console.log)(lub wyślij to do swojej analityki), aby przechwycić FCP od własnych odwiedzających; obsługuje przypadki brzegowe bfcache i kart w tle.
Dane laboratoryjne (symulowane)
- Lighthouse — w Chrome DevTools, PageSpeed Insights lub CLI. Użyj go do diagnozowania FCP (audyt „Eliminate render-blocking resources” jest kluczowy).
- Panel wydajności Chrome DevTools — zobacz dokładnie, kiedy pierwsze malowanie i pierwsze malowanie treści występują podczas zarejestrowanego ładowania.
Zmierz to sam za pomocą Paint Timing API
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntriesByName('first-contentful-paint')) {
console.log('FCP candidate:', entry.startTime, entry);
}
}).observe({type: 'paint', buffered: true});Albo użyj biblioteki web-vitals (zalecane)
import {onFCP} from 'web-vitals';
onFCP(console.log);Kilka zastrzeżeń, których surowe API nie obsługuje, a które obsługuje biblioteka web-vitals: ignoruje
FCP wyzwalane dla kart w tle, nadal raportuje FCP, gdy strona jest przywracana z
pamięci podręcznej wstecz/do przodu (świeże zdarzenie nawigacji nie wyzwala się automatycznie dla
przywrócenia bfcache, więc wymaga to jawnej obsługi) i używa activationStart zamiast
początku nawigacji jako początku zegara dla stron wstępnie renderowanych. Cross-origin iframe
czas malowania pozostaje znaną luką — strona, której główna treść renderuje się wewnątrz takiego elementu, może
wykazywać myląco szybki FCP.
Błędy FCP, które ukrywają prawdziwy problem
- Traktowanie FCP jako Core Web Vital. FCP to przydatny wskaźnik diagnostyczny, ale LCP, INP i CLS to Core Web Vitals używane w systemach rankingowych Google. Używaj FCP do badania fazy pustego ekranu, a nie jako zamiennika danych CWV z pola.
- Optymalizacja małego logo, ponieważ staje się pierwszym malowaniem. Wcześniejsze, ale bez znaczenia malowanie może poprawić FCP, podczas gdy użyteczna treść strony nadal pojawia się późno. Sprawdź LCP i filmstrip wraz z FCP, aby zmiana poprawiła to, co odwiedzający faktycznie widzi.
- Zaczynanie od kompresji obrazów, gdy strona jest pusta. Jeśli nic nie może się namalować, zwykłymi blokerami są czas odpowiedzi serwera, blokujące renderowanie CSS, synchroniczny JavaScript lub czcionki. Podążaj za wodospadem żądań przed zmianą niepowiązanych zasobów.
- Porównywanie niepowiązanych przebiegów Lighthouse. Emulacja urządzenia, warunki sieciowe, stan pamięci podręcznej i zmienność między przebiegami wpływają na laboratoryjny FCP. Porównuj powtarzane przebiegi w tych samych ustawieniach i potwierdzaj wynik danymi z pola, gdzie to możliwe.
Budżet pustego ekranu
Podziel FCP na trzy kolejne pytania zamiast traktować końcową liczbę jako jeden problem:
- Jak długo, zanim HTML dotrze? Sprawdź TTFB. Wolna odpowiedź oznacza, że przeglądarka nie może rozpocząć użytecznej pracy, więc zacznij od serwera, pamięci podręcznej, przekierowań lub konfiguracji połączenia.
- Jak długo, zanim przeglądarka będzie mogła renderować? Sprawdź blokujące renderowanie arkusze stylów, synchroniczne skrypty i zachowanie czcionek. HTML może być obecny, podczas gdy główny wątek lub ścieżka renderowania jest nadal zablokowana.
- Co faktycznie staje się pierwszą treścią? Użyj filmstrip lub śladu, aby potwierdzić, że pierwsze malowanie to znaczący tekst lub obrazy, a nie element zastępczy, który poprawia wskaźnik bez poprawy doświadczenia.
Struktura utrzymuje poprawki w kolejności: dostarczenie najpierw, renderowanie drugie, użyteczność na końcu. Uruchom ponownie ten sam profil laboratoryjny po każdej zmianie, aby wiedzieć, która faza się przesunęła.
Sprawdź się: First Contentful Paint
Pięć szybkich pytań o to, co mierzy FCP i jak go diagnozować. Wybierz odpowiedź na każde, a następnie sprawdź.
Zasoby warte Twojego czasu
Google / web.dev
- First Contentful Paint (FCP) — kanoniczne źródło: definicja, progi, kod pomiarowy i pełna lista optymalizacji.
- Web Vitals — jak FCP odnosi się do Core Web Vitals i dlaczego jest to wskaźnik diagnostyczny.
- Largest Contentful Paint (LCP) — wskaźnik, który FCP pomaga diagnozować, oraz Core Web Vital.
- Time to First Byte (TTFB) — wskaźnik czasu odpowiedzi serwera, który znajduje się wewnątrz FCP.
Lighthouse
- First Contentful Paint audit — pasma ocen dla komputerów stacjonarnych i sposób obliczania wyniku.
- Lighthouse performance scoring — wagi wskaźników, FCP na poziomie 10%.
Moje powiązane artykuły
- Przewodnik dla początkujących po technicznym SEO — gdzie szybkość strony wpisuje się w szerszy obraz.
- Core Web Vitals: czym są i jak je poprawić — wskaźniki sygnału rankingowego, do których FCP się przyczynia.
Z branży
- First Contentful Paint (FCP) — kanoniczny artykuł Philipa Waltona w Google: definicja, progi, kod Paint Timing API i pełna lista optymalizacji.
- Web Vitals — framework Google wyjaśniający, gdzie mieści się FCP („Other Web Vital”, uzupełniający względem Core Web Vitals) i jego rolę w diagnozowaniu LCP.
- First Contentful Paint audit — dokumentacja Chrome Developers obejmująca poziomy ocen Lighthouse dla desktopu i sposób obliczania wyniku FCP na podstawie danych HTTP Archive.
- Time to First Byte (TTFB) — przewodnik Google o tym, dlaczego TTFB poprzedza FCP i jest w nim uwzględnione, oraz jak wolny serwer pochłania budżet FCP, zanim przeglądarka namaluje choćby jeden piksel.
- Eliminate render-blocking resources — przewodnik Chrome Developers o głównym zabójcy FCP: CSS i synchronicznym JS w <head>, które blokują przeglądarce malowanie.
- Ensure text remains visible during webfont load — audyt Chrome Developers wyjaśniający wartości font-display i dlaczego
blockopóźnia FCP, aswapluboptionalutrzymuje tekst widocznym. - First Contentful Paint — praktyczny przewodnik NitroPack po FCP z poradami optymalizacyjnymi dla konkretnych CMS-ów i jasnym wyjaśnieniem różnicy między pomiarami terenowymi a laboratoryjnymi.
Statystyki, które warto cytować
- Dobre FCP = ≤ 1,8 s na 75. percentylu rzeczywistych użytkowników; do poprawy do 3,0 s; słabe powyżej (progi terenowe/CrUX). Źródło
- Lighthouse na desktopie jest bardziej rygorystyczny: ~0–0,9 s to „zielony”, bo laboratorium działa w ograniczonym, symulowanym środowisku, a nie w warunkach rzeczywistych. Źródło
- FCP stanowi 10 % wyniku Performance w Lighthouse 10 (aktualne w chwili pisania — wagi zmieniają się między wersjami Lighthouse) — obok TBT 30 %, LCP 25 %, CLS 25 % i Speed Index 10 %. Źródło
- Preconnect do zewnętrznych originów może zaoszczędzić 100–500 ms czasu ładowania dzięki wczesnemu nawiązywaniu połączeń. Źródło
Dziennik zmian
Zaktualizowano 11 sie 2026.
Podsumowanie redakcyjne i zapisane szczegóły zmian.Szczegóły zmian
-
Szczegółowe uwagi dotyczące zmian są obecnie dostępne po angielsku.
-
Szczegółowe uwagi dotyczące zmian są obecnie dostępne po angielsku.
Pełne porównanie jest niedostępne — dla tej wersji nie zarchiwizowano wcześniejszej migawki.
Zaktualizowano 3 sie 2026.
Podsumowanie redakcyjne i zapisane szczegóły zmian.Szczegóły zmian
-
Szczegółowe uwagi dotyczące zmian są obecnie dostępne po angielsku.
Pełne porównanie jest niedostępne — dla tej wersji nie zarchiwizowano wcześniejszej migawki.
Zaktualizowano 17 lip 2026.
Podsumowanie redakcyjne i zapisane szczegóły zmian.Szczegóły zmian
-
Szczegółowe uwagi dotyczące zmian są obecnie dostępne po angielsku.
Pełne porównanie jest niedostępne — dla tej wersji nie zarchiwizowano wcześniejszej migawki.