First Contentful Paint (FCP)

Philip Walton

Co to jest FCP?

Pierwsze wyrenderowanie treści (FCP) mierzy czas od momentu, gdy użytkownik po raz pierwszy otworzył stronę, do momentu, gdy dowolna część treści strony została wyrenderowana na ekranie. W przypadku tej metryki „treści” to tekst, obrazy (w tym obrazy tła), elementy <svg> lub elementy <canvas>, które nie są białe.

Na osi czasu wczytywania na poprzednim obrazie FCP występuje w drugiej klatce, ponieważ to wtedy na ekranie pojawiają się pierwsze elementy tekstu i obrazu.

Zauważysz, że niektóre treści zostały wyrenderowane, ale nie wszystkie. Ważne jest rozróżnianie między pierwszym wyrenderowaniem treści a największym wyrenderowaniem treści (LCP), które ma na celu zmierzenie, kiedy skończyło się wczytywanie głównej zawartości strony.

Jaki jest dobry wynik FCP?

Aby zapewnić użytkownikom wygodę, witryny powinny mieć czas First Contentful Paint wynoszący 1,8 sekund lub mniej. Aby mieć pewność, że osiągasz ten cel w przypadku większości użytkowników, warto mierzyć 50. percentyl wczytywania stron w grupach urządzeń mobilnych i komputerów.

Jak mierzyć FCP

Wartość FCP można mierzyć w laboratorium lub w warunkach rzeczywistych. Jest ona dostępna w tych narzędziach:

Narzędzia w polu

• PageSpeed Insights
• Raport na temat użytkowania Chrome
• Search Console (raport dotyczący szybkości)
• web-vitals Biblioteka JavaScript

Narzędzia laboratoryjne

• Lighthouse
• Narzędzia deweloperskie w Chrome
• PageSpeed Insights

Pomiar FCP w JavaScript

Aby mierzyć FCP w JavaScript, możesz użyć interfejsu Paint Timing API. Ten przykład pokazuje, jak utworzyć element PerformanceObserver, który nasłuchuje wpisu paint o nazwie first-contentful-paint i rejestruje go w konsoli.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntriesByName('first-contentful-paint')) {
    console.log('FCP candidate:', entry.startTime, entry);
  }
}).observe({type: 'paint', buffered: true});

W poprzednim fragmencie kodu zarejestrowany wpis first-contentful-paint informuje, kiedy został wyrenderowany pierwszy element z treścią. W niektórych przypadkach ten wpis nie jest jednak odpowiedni do pomiaru FCP.

W następującej sekcji opisano różnice między tym, co raportuje interfejs API, a sposobem obliczania danych.

Różnice między danymi a interfejsem API

• Interfejs API wyśle wpis first-contentful-paint w przypadku stron wczytanych na karcie w tle, ale te strony powinny być ignorowane podczas obliczania FCP (czasy pierwszego wyrenderowania powinny być brane pod uwagę tylko wtedy, gdy strona była na pierwszym planie przez cały czas).
• Interfejs API nie przekazuje rekordów first-contentful-paint, gdy strona jest przywracana z pamięci podręcznej stanu strony internetowej, ale w takich przypadkach należy mierzyć FCP, ponieważ użytkownicy postrzegają te zdarzenia jako oddzielne wizyty na stronie.
• Interfejs API może nie raportować czasów renderowania z elementów iframe z innych domen, ale aby prawidłowo mierzyć FCP, należy wziąć pod uwagę wszystkie klatki. Podramki mogą używać interfejsu API do raportowania czasu renderowania do ramki nadrzędnej na potrzeby agregacji.
• Interfejs API mierzy FCP od momentu rozpoczęcia nawigacji, ale w przypadku stron z zabezpieczonym wyrenderowaniem czas ten należy mierzyć od activationStart, ponieważ odpowiada on temu, który użytkownik odczuwa.

Zamiast zapamiętywać te subtelne różnice, programiści mogą używać biblioteki JavaScript web-vitals do pomiaru FCP, która załatwia te różnice (w miarę możliwości – zwróć uwagę, że problem z iframe nie jest uwzględniany):

import {onFCP} from 'web-vitals';

// Measure and log FCP as soon as it's available.
onFCP(console.log);

Pełny przykład pomiaru FCP w JavaScript znajdziesz w źródłowym kodzie onFCP().

Jak poprawić FCP

Aby dowiedzieć się, jak poprawić FCP w konkretnej witrynie, możesz przeprowadzić audyt wydajności Lighthouse i zwrócić uwagę na konkretne możliwości lub diagnozy sugerowane przez audyt.

Aby dowiedzieć się, jak ogólnie poprawić FCP (w przypadku dowolnej witryny), zapoznaj się z tymi przewodnikami dotyczącymi wydajności:

• Wyeliminuj zasoby blokujące renderowanie
• Minifikuj CSS
• Usuwanie nieużywanego kodu CSS
• Usuwanie nieużywanego kodu JavaScript
• Przedwczesne połączenie z wymaganymi źródłami
• Skrócenie czasu odpowiedzi serwera (TTFB)
• Unikaj wielokrotnych przekierowań
• Wstępne wczytywanie żądań kluczy
• Unikaj ogromnych obciążeń sieci
• Udostępnianie zasobów statycznych za pomocą skutecznych zasad dotyczących pamięci podręcznej
• Unikaj nadmiernego rozmiaru DOM
• Minimalizowanie głębokości krytycznych żądań
• Zapewnij widoczność tekstu podczas ładowania czcionek internetowych
• Liczba żądań i ilość przesyłanych danych powinny być małe

Historia zmian

Czasami w interfejsach API służących do pomiaru danych i czasami w definicjach samych danych występują błędy. W związku z tym czasami trzeba wprowadzić zmiany, które mogą się pojawiać w raportach i panelach wewnętrznych jako ulepszenia lub regresje.

Aby ułatwić Ci zarządzanie tymi danymi, wszystkie zmiany w ich implementacji lub definicji będą widoczne w Historii zmian.

Jeśli masz opinię na temat tych danych, możesz ją przekazać w grupie Google poświęconej web-vitals-feedback.