Przejdź do treści
Wydajność

First Contentful Paint (FCP)

Opublikowano:

First Contentful Paint (FCP), czyli pierwsze wyrenderowanie treści, to czas od momentu, w którym użytkownik rozpoczął nawigację do strony, do chwili, gdy na ekranie pojawi się jakakolwiek jej treść. Treścią jest tekst, obraz (także obraz tła), element <svg> albo niebiały <canvas>.

FCP można mierzyć zarówno w laboratorium, jak i u realnych użytkowników. Nie jest Core Web Vital: web.dev traktuje go jako metrykę pomocniczą, która pomaga zdiagnozować problemy z ładowaniem wpływające na LCP.

Co dokładnie mierzy FCP

Pomiar zaczyna się w chwili nawigacji, a nie w chwili, gdy serwer odpowie. Dlatego w danych terenowych FCP obejmuje też czas zamykania poprzedniej strony, zestawienie połączenia, przekierowania i Time to First Byte (TTFB). Wolny serwer albo łańcuch przekierowań podnosi FCP, zanim przeglądarka dostanie choćby bajt HTML.

Lighthouse nie wlicza do FCP treści wewnątrz ramek iframe. Interfejs Paint Timing może też nie raportować renderowania z ramek innego pochodzenia (cross-origin), więc pomiar w JavaScripcie bywa tu niepełny.

Progi FCP

Próg web.dev dotyczy danych terenowych: 75. percentyl wizyt, osobno dla urządzeń mobilnych i komputerów. Progi Lighthouse dotyczą pojedynczego testu laboratoryjnego na danym profilu urządzenia.

W Lighthouse 10 FCP ma 10% wagi w wyniku Performance, tyle samo co Speed Index. Więcej ważą TBT (30%) oraz LCP i CLS (po 25%).

ŹródłoDobryDo poprawySłaby
web.dev (75. percentyl wizyt)do 1,8 s1,8–3,0 spowyżej 3,0 s
Lighthouse, mobile0–1,8 s1,8–3 spowyżej 3 s
Lighthouse, desktop0–0,9 s0,9–1,6 spowyżej 1,6 s

FCP, LCP i TTFB: czym się różnią

Jeśli strona pokazuje ekran powitalny albo wskaźnik ładowania, FCP może być szybki, choć użytkownik nadal nie widzi niczego przydatnego. Dlatego FCP diagnozuje początek ładowania, a oceny postrzeganej szybkości dokonuje się na podstawie LCP.

  • TTFB mierzy, kiedy przychodzi pierwszy bajt odpowiedzi. Poprzedza FCP i LCP, dlatego web.dev zaleca taki czas odpowiedzi serwera, żeby 75. percentyl użytkowników miał dobry FCP.
  • FCP mierzy, kiedy pojawia się jakakolwiek treść. Może to być logo, nagłówek albo wskaźnik ładowania.
  • LCP mierzy, kiedy pojawia się największy element treści w widocznym obszarze. To on odpowiada na pytanie, czy główna treść już jest.

Jak skrócić FCP

  • Usuń zasoby blokujące renderowanie. CSS i synchroniczne skrypty w <head> wstrzymują pierwsze malowanie, dopóki się nie pobiorą.
  • Skróć TTFB i unikaj wielokrotnych przekierowań. Każdy dodatkowy skok sieciowy przesuwa FCP.
  • Usuń nieużywany CSS i JavaScript oraz minifikuj to, co zostaje.
  • Nawiąż wcześniej połączenia z potrzebnymi domenami (preconnect) i wczytuj z wyprzedzeniem kluczowe zasoby (preload).
  • Nie ukrywaj tekstu na czas ładowania fontu. font-display: swap pokazuje od razu font systemowy, co przyspiesza FCP i LCP, ale podmiana fontu może wywołać przesunięcie układu (CLS).
  • Ogranicz liczbę i rozmiar żądań, głębokość łańcucha krytycznych żądań i rozmiar DOM.
Font widoczny od razu, połączenie nawiązane wcześniej
HTML
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<style>
  @font-face {
    font-family: "Brand";
    src: url("/fonts/brand.woff2") format("woff2");
    font-display: swap;
  }
</style>

Jak mierzyć FCP

W laboratorium FCP pokazują Lighthouse, panel Performance w Chrome DevTools i PageSpeed Insights. Dane terenowe pochodzą z Chrome UX Report (CrUX), które pokazuje też PageSpeed Insights, albo z własnego RUM.

Do pomiaru u użytkowników najprościej użyć biblioteki web-vitals. Nie zmierzy ona jednak renderowania w ramkach innego pochodzenia.

Pomiar FCP w przeglądarce
JavaScript
import { onFCP } from 'web-vitals';

// Wypisuje FCP, gdy tylko jest dostępny
onFCP(console.log);

Źródła i dalsza lektura

Sprawdź, co opóźnia pierwszy ekran

Insight łączy wyniki laboratoryjne i dane terenowe, gdy są dostępne, i układa problemy z wydajnością według priorytetu.