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 tego wskaźnika „content” odnoszą się do tekstu, obrazów (w tym obrazów tła), elementów <svg>
lub elementów <canvas>
innych niż białe.
Na osi czasu wczytywania przedstawionej na poprzednim obrazie FCP odbywa się w drugiej ramce, ponieważ to wtedy na ekranie są renderowane pierwsze elementy tekstowe i graficzne.
Zauważysz, że chociaż część treści została wyrenderowana, nie cała została wyrenderowana. 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
- Interfejs Chrome dla użytkowników Zgłoś
- Search Console (Szybkość Raport)
- Biblioteka JavaScript
web-vitals
Narzędzia laboratoryjne
Pomiar FCP w JavaScript
Aby mierzyć FCP w języku JavaScript, możesz użyć interfejsu Paint Timing API. Poniższy przykład pokazuje, jak utworzyć obiekt 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 zapisany wpis first-contentful-paint
informuje, kiedy wyrenderowano pierwszy element treści. W niektórych przypadkach ten wpis nie nadaje się jednak do pomiaru FCP.
W tej sekcji opisujemy różnice między danymi w raportach interfejsu 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 podawać informacji o czasach renderowania z elementów iframe z innych domen, ale aby prawidłowo zmierzyć FCP, należy uwzględnić 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 rozpoczęcia nawigacji, ale w przypadku wstępnie renderowanych stron wartość FCP należy mierzyć od
activationStart
, ponieważ odpowiada to czasowi FCP odczuwanemu przez użytkownika.
Zamiast zapamiętywać wszystkie te subtelne różnice, deweloperzy mogą użyć biblioteki JavaScript web-vitals
do pomiaru FCP, która uwzględnia te różnice za Ciebie (tam, gdzie to możliwe – problem z elementami iframe nie jest omówiony):
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 języku JavaScript znajdziesz w kodzie źródłowym strony onFCP()
.
Jak poprawić pierwsze wyrenderowanie treści
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 JavaScriptu
- Wstępnie połącz 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
- Maksymalna liczba próśb i niewielkie pliki przenoszenia
Historia zmian
Czasami błędy wykrywane są w interfejsach API używanych do pomiaru danych, a czasem w definicjach samych wskaźników. Dlatego czasami konieczne jest wprowadzenie zmian, które mogą być widoczne jako ulepszenia lub regresje w wewnętrznych raportach i panelach.
Aby ułatwić Ci to zadanie, wszystkie zmiany w implementacji lub definicji tych danych będą widoczne w tym dzienniku zmian.
Jeśli chcesz podzielić się opinią na temat tych danych, możesz przesłać ją w grupie dyskusyjnej Google z informacjami o web-vitals-feedback.