Pierwsze wyrenderowanie treści (FCP) to ważny wskaźnik skupiony na użytkownikach, który służy do pomiaru widocznej szybkości wczytywania. Oznacza to pierwszy punkt na osi czasu wczytywania strony, w którym użytkownik może zobaczyć dowolny element ekranu. Szybkie FCP zapewnia użytkownikowi pewność, że coś się dzieje.
FCP to czas od pierwszego otwarcia strony przez użytkownika do momentu wyrenderowania dowolnej części jej treści na ekranie. W przypadku tego wskaźnika „treść” odnosi się do tekstu, obrazów (w tym obrazów tła), elementów <svg>
lub elementów <canvas>
innych niż białe.
Po wyrenderowaniu pierwszego elementu treści nie wszystkie treści są renderowane. To ważna różnica między FCP a największym wyrenderowaniem treści (LCP), która mierzy, kiedy zakończy się wczytywanie głównej zawartości strony.
Jaki jest dobry wynik FCP?
Aby użytkownicy byli zadowoleni, witryna musi mieć FCP o długości maksymalnie 1,8 sekundy. Aby mieć pewność, że w przypadku większości użytkowników osiągasz ten cel, dobrym progiem jest 75 centyl wczytywania stron w podziale na urządzenia mobilne i komputery.
Jak mierzyć FCP
FCP można mierzyć w module lub w terenie. Są one dostępne 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
Mierz FCP w JavaScript
Aby mierzyć FCP w JavaScript, użyj Paint Timing API.
Z przykładu poniżej dowiesz się, jak utworzyć 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 tym przykładzie zarejestrowany wpis first-contentful-paint
informuje, kiedy wyrenderowano pierwszy element treści. Jednak w niektórych przypadkach ten wpis nie nadaje się do pomiaru FCP.
W tej sekcji opisujemy różnice między danymi w raportach interfejsu API a sposobem obliczania tych danych.
Różnice między danymi a interfejsem API
- W przypadku stron wczytywanych na karcie w tle interfejs API wysyła wpis
first-contentful-paint
, ale te strony należy zignorować przy obliczaniu FCP. Czas pierwszego wyrenderowania jest brany pod uwagę tylko wtedy, gdy strona przez cały czas znajdowała się na pierwszym planie. - Interfejs API nie zgłasza wpisów
first-contentful-paint
, gdy strona jest przywracana z pamięci podręcznej stanu strony internetowej, ale w takich przypadkach należy mierzyć wartość FCP, ponieważ użytkownicy postrzegają je jako odrębne wizyty na stronie. - Interfejs API może nie zgłaszać czasu renderowania z elementów iframe z innych domen, ale aby prawidłowo mierzyć FCP, musisz wziąć pod uwagę wszystkie klatki. Ramki podrzędne mogą używać interfejsu API do zgłaszania czasu renderowania do ramki nadrzędnej na potrzeby agregacji.
- Interfejs API mierzy FCP od początku nawigacji, ale w przypadku wstępnie renderowanych stron należy mierzyć wartość FCP od
activationStart
, ponieważ odpowiada to czasowi FCP zarejestrowanemu przez użytkownika.
Zamiast zapamiętywać wszystkie te subtelne różnice, deweloperzy mogą użyć biblioteki JavaScript web-vitals
do pomiaru FCP, która w miarę możliwości eliminuje te różnice (z wyjątkiem elementów iframe):
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 kodzie źródłowym onFCP()
.
Jak poprawić FCP
Aby dowiedzieć się, jak poprawić FCP w przypadku konkretnej witryny, przeprowadź audyt wydajności w Lighthouse i zwróć uwagę na konkretne możliwości i diagnostykę sugerowaną w aukcji.
Aby dowiedzieć się, jak ogólnie poprawić FCP (w dowolnej witrynie), zapoznaj się z tymi przewodnikami po wydajności:
- Wyeliminuj zasoby blokujące renderowanie
- Zmniejsz CSS
- Usuwanie nieużywanego kodu CSS
- Usuwanie nieużywanego kodu JavaScript
- Wstępne łączenie z wymaganymi źródłami
- Skróć czas odpowiedzi serwera (TTFB)
- Unikanie wielokrotnych przekierowań na stronach
- Wstępne wczytywanie żądań kluczy
- Unikaj bardzo dużych ładunków sieciowych
- Wyświetlanie zasobów statycznych z wykorzystaniem skutecznej zasady pamięci podręcznej
- Unikaj nadmiernego rozmiaru DOM
- Minimalizowanie głębokości żądań krytycznych
- Zadbaj o to, aby tekst był widoczny podczas ładowania czcionki internetowej
- Liczba żądań powinna być mała, a rozmiar przesyłanych danych jest niewielki
Historia zmian
Czasami błędy wykrywane są w interfejsach API używanych do pomiaru danych, a niekiedy w definicjach samych wskaźników. Dlatego czasem trzeba wprowadzać zmiany, które mogą się pojawiać jako ulepszenia lub regresje w wewnętrznych raportach i panelach.
Aby Ci w tym pomóc, wszystkie zmiany w implementacji lub definicji tych danych są opisane w tej historii zmian.
Jeśli chcesz podzielić się opinią na temat tych danych, umieść ją w grupie dyskusyjnej Google web-vitals-feedback.