Co to jest FCP?
Pierwsze wyrenderowanie treści (FCP) to czas od pierwszego otwarcia strony przez użytkownika do wyrenderowania dowolnej części treści strony 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 ładowania 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. Jest to ważna różnica między pierwszym wyrenderowaniem treści a największym wyrenderowaniem treści (LCP), które ma na celu zmierzenie, kiedy główna zawartość strony zostanie wczytana.
Jaki jest dobry wynik FCP?
W trosce o wygodę użytkowników pierwsze wyrenderowanie treści powinno wynosić maksymalnie 1, 8 sekundy. Aby mieć pewność, że w przypadku większości użytkowników osiągniesz ten cel, warto mierzyć 75 centyl wczytań stron z podziałem na urządzenia mobilne i komputery.
Jak mierzyć FCP
FCP można mierzyć w laboratorium lub w terenie. Wartość ta jest dostępna w tych narzędziach:
Narzędzia terenowe
- PageSpeed Insights
- Raport na temat użytkowania Chrome
- Search Console (raport dotyczący szybkości)
- Biblioteka JavaScript
web-vitals
Narzędzia laboratoryjne
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 wyrenderowano pierwszy element 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 wysyła wpis
first-contentful-paint
w przypadku stron wczytywanych na karcie w tle, ale strony te należy zignorować przy obliczaniu FCP (czas pierwszego wyrenderowania powinien być brany pod uwagę tylko wtedy, gdy strona była przez cały czas na pierwszym planie). - Interfejs API nie zgłasza wpisów
first-contentful-paint
po przywróceniu strony z pamięci podręcznej stanu strony internetowej, ale w takich przypadkach należy mierzyć FCP, ponieważ użytkownicy odnotowują je jako odrębne 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. Ramki podrzędne 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 przypadku konkretnej witryny, możesz przeprowadzić audyt wydajności w Lighthouse i zwrócić uwagę na konkretne możliwości lub wskaźniki diagnostyczne sugerowane przez audyt.
Aby dowiedzieć się, jak ogólnie poprawić FCP (w dowolnej witrynie), zapoznaj się z tymi przewodnikami po skuteczności:
- Wyeliminuj zasoby blokujące renderowanie
- Zmniejszanie CSS
- Usuwanie nieużywanego kodu CSS
- Usuwanie nieużywanego kodu JavaScript
- Przedwczesne połączenie z wymaganymi źródłami
- Krótszy czas odpowiedzi serwera (TTFB)
- Unikaj wielokrotnych przekierowań
- Wstępne wczytywanie żądań kluczy
- Unikaj bardzo dużych ładunków sieciowych
- Wyświetlanie zasobów statycznych z zastosowaniem efektywnej zasady pamięci podręcznej
- Unikaj nadmiernego rozmiaru DOM
- Minimalizowanie głębokości żądań krytycznych
- Zadbaj o to, żeby tekst był widoczny podczas wczytywania czcionek internetowych
- Liczba żądań i ilość przesyłanych danych powinny być małe
Historia zmian
Czasami błędy wykrywane są w interfejsach API używanych do pomiaru danych, a czasem w definicjach samych wskaźników. 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 to zadanie, wszystkie zmiany w implementacji lub definicji tych danych będą widoczne w tym dzienniku zmian.
Jeśli masz opinię na temat tych danych, możesz ją przekazać w grupie Google nt. danych web-vitals.