W przeszłości dla programistów stron internetowych wyzwaniem było zmierzenie, jak szybko główna treść strony internetowej wczytuje się i jest widoczna dla użytkowników. Starsze dane, takie jak load czy DOMContentLoaded, nie działają dobrze, ponieważ nie muszą być zgodne z tym, co użytkownik widzi na ekranie. Z kolei nowsze, skoncentrowane na użytkownikach dane o wydajności, takie jak pierwsze wyrenderowanie treści (FCP), odnotowują dopiero na samym początku wczytywania strony. Jeśli na stronie pojawia się ekran powitalny lub wskaźnik wczytywania, użytkownik nie ma w tej chwili żadnych informacji.
W przeszłości zalecaliśmy dane o wydajności, takie jak First Meaningful Paint (FMP) i Speed Index (SI) (dostępne w Lighthouse), aby lepiej uchwycić czas wczytywania strony po pierwszym wyrenderowaniu. Są one jednak złożone, trudne do wyjaśnienia i często błędne, co oznacza, że nadal nie identyfikują, kiedy główna treść strony została wczytana.
Na podstawie dyskusji w grupie W3C Web Performance Activity Group i badań przeprowadzonych w Google doszliśmy do wniosku, że dokładniejszym sposobem na zmierzenie czasu wczytywania głównej treści strony jest sprawdzanie czasu wyrenderowania największego elementu.
Co to jest LCP?
LCP podaje czas renderowania największego bloku graficznego lub tekstowego widocznego w widocznym obszarze w odniesieniu do czasu, w którym użytkownik po raz pierwszy przeszedł na stronę.
Jaki jest dobry wynik LCP?
Aby zadbać o wygodę użytkowników, witryny powinny wyświetlać największe wyrenderowanie treści, które trwa nie więcej niż 2,5 sekundy. Aby mieć pewność, że w przypadku większości użytkowników osiągasz ten cel, dobrym progiem jest 75 centyl wczytań stron w podziale na urządzenia mobilne i komputery.
Jakie elementy są uwzględniane?
Zgodnie z informacjami obecnie w interfejsie Largest Contentful Paint typy elementów rozpatrywane jako największe wyrenderowanie treści to:
<img>(czas wyświetlania pierwszej klatki jest używany w przypadku treści animowanych, takich jak pliki GIF czy animowane pliki PNG).- Elementy
<image>w elemencie<svg> - Elementy
<video>(w przypadku filmów używany jest czas wczytywania obrazu plakatu lub czas wyświetlania pierwszej klatki w przypadku filmów – zależnie od tego, co nastąpi wcześniej). - Element z obrazem tła wczytanym za pomocą funkcji
url()(a nie gradientem CSS). - elementów na poziomie bloku, które zawierają węzły tekstowe lub inne elementy podrzędne elementów tekstowych na poziomie wbudowanego;
Zwróć uwagę, że ograniczenie elementów do tego ograniczonego zbioru było zamierzone, aby na początku wszystko było proste. W przyszłości w miarę prowadzenia kolejnych badań możemy dodać kolejne elementy (takie jak pełna obsługa <svg>).
Pomiary LCP uwzględniają nie tylko niektóre elementy, ale też korzystają z metod heurystycznych do wykluczania określonych elementów, które użytkownicy mogą uznać za „bez treści”. W przypadku przeglądarek opartych na Chromium są to:
- elementów o przezroczystości 0, które są niewidoczne dla użytkownika;
- elementy zasłaniające cały widoczny obszar, które prawdopodobnie są uznawane za tło, a nie treść;
- obrazy zastępcze lub inne obrazy o niskiej entropii, które prawdopodobnie nie odzwierciedlają prawdziwej treści strony;
Przeglądarki zapewne będą nadal ulepszać heurystyki, by spełniać oczekiwania użytkowników dotyczące największego elementu treści.
Te „trafne” heurystyki mogą różnić się od tych stosowanych w metodzie Pierwsze wyrenderowanie treści (FCP), ponieważ może uwzględniać niektóre z tych elementów, np. obrazy zastępcze lub obrazy w pełnym widocznym obszarze, nawet jeśli nie kwalifikują się do list kandydatów do LCP. Mimo że oba słowa używają słowa „treści” w nazwie, cele tych danych są różne. Wskaźnik FCP określa, kiedy dowolna treść jest malowana na ekran, a LCP, gdy główna treść jest malowana, tak aby wskaźnik LCP był bardziej selektywny.
Jak określa się rozmiar elementu?
Rozmiar elementu zgłoszonego w przypadku LCP jest zwykle taki sam jak rozmiar widoczny dla użytkownika w widocznym obszarze. Jeśli element wychodzi poza widoczny obszar lub którykolwiek z elementów jest przycięty bądź ma niewidoczne overflow, te części nie wliczają się do rozmiaru elementu.
W przypadku elementów graficznych, których rozmiar został zmieniony z rozmiaru wewnętrznego, w raportach uwzględniany jest rozmiar widoczny lub wewnętrzny (w zależności od tego, która wartość jest mniejsza).
W przypadku elementów tekstowych LCP bierze pod uwagę tylko najmniejszy prostokąt, który może zawierać wszystkie węzły tekstowe.
W przypadku wszystkich elementów LCP nie uwzględnia marginesów, dopełnienia ani obramowań zastosowanych za pomocą CSS.
Kiedy raport LCP jest raportowany?
Strony internetowe są często wczytywane etapowo, w związku z czym może się zmienić największy z nich.
Aby uwzględnić tę możliwość, natychmiast po wyrenderowaniu pierwszej klatki przeglądarka wysyła PerformanceEntry typu largest-contentful-paint identyfikujący największy element treści. Jednak po wyrenderowaniu kolejnych klatek z każdej zmiany największego elementu treści wysyła kolejny element PerformanceEntry.
Na przykład na stronie z tekstem i banerem powitalnym przeglądarka może początkowo tylko renderować tekst – wtedy przeglądarka wysyła wpis largest-contentful-paint, którego właściwość element prawdopodobnie odwołuje się do <p> lub <h1>. Później, po zakończeniu wczytywania banera powitalnego, wysłany zostanie drugi wpis largest-contentful-paint, a jego właściwość element będzie się odwoływać do <img>.
Element może zostać uznany za największy element treści dopiero po wyrenderowaniu i wyświetleniu się użytkownikowi. Obrazy, które nie zostały jeszcze wczytane, nie są uważane za „wyrenderowane”. Ani węzły tekstowe, które korzystają z czcionek internetowych w okresie bloku czcionek. W takich przypadkach mniejszy element może zostać zgłoszony jako największy element treści, ale gdy tylko większy element zakończy renderowanie, tworzony jest kolejny element PerformanceEntry.
Oprócz późno wczytywanych obrazów i czcionek strona może dodawać nowe elementy do DOM w miarę pojawiania się nowych treści. Jeśli którykolwiek z tych nowych elementów jest większy niż poprzedni pod względem wielkości element treści, w raportach też pojawi się nowy element PerformanceEntry.
Jeśli największy element treści zostanie usunięty z widocznego obszaru lub nawet z DOM, pozostaje on największym elementem treści, chyba że zostanie wyrenderowany większy.
Przeglądarka przestaje zgłaszać nowe wpisy, gdy tylko użytkownik wejdzie w interakcję ze stroną (kliknie, przewiń lub naciśnie klawisz), ponieważ interakcja użytkownika często zmienia to, co jest dla niego widoczne (co dzieje się zwłaszcza w przypadku przewijania).
Do celów analitycznych zgłaszaj do usługi analitycznej tylko ostatnio wysłane urządzenie PerformanceEntry.
Czas wczytywania a czas renderowania
Ze względów bezpieczeństwa sygnatura czasowa renderowania obrazów nie jest dostępna w przypadku obrazów z innych domen, które nie mają nagłówka Timing-Allow-Origin. Ujawniany jest tylko czas wczytywania strony (ponieważ jest już widoczny w wielu innych internetowych interfejsach API).
Może to prowadzić do sytuacji, w której LCP jest zgłaszane przez internetowe interfejsy API jako wcześniejsze niż FCP. Nie o to tutaj chodzi, ale tylko ze względu na to ograniczenie bezpieczeństwa.
Jeśli to możliwe, zalecamy ustawienie nagłówka Timing-Allow-Origin, ponieważ zwiększy to dokładność danych.
Jak są wprowadzane zmiany układu i rozmiaru elementów?
Zmiana rozmiaru lub pozycji elementu nie powoduje wygenerowania nowych propozycji LCP. Pozwala to utrzymać niską skuteczność przy obliczaniu i wysyłaniu nowych wpisów o skuteczności. Uwzględniany jest tylko początkowy rozmiar i położenie elementu w widocznym obszarze.
Oznacza to, że obrazy, które są początkowo renderowane poza ekranem, a potem przeniesione na ekran, mogą nie zostać zgłoszone. Oznacza to też, że elementy początkowo renderowane w widocznym obszarze, a potem przesuwane w dół, poza widocznym obszarem nadal podają początkowy rozmiar widocznego obszaru.
Przykłady
Oto kilka przykładów sytuacji, w której w kilku popularnych witrynach następuje wyrenderowanie największej treści:
Na obu powyższych osiach czasu największy element zmienia się wraz z wczytywaniem treści. W pierwszym przykładzie do DOM jest dodawana nowa treść, która zmienia rozmiar największego elementu. W drugim przykładzie zmieni się układ, a treści, które wcześniej były największe, zostaną usunięte z widocznego obszaru.
Chociaż często zdarza się, że treści wczytujące się później są większe niż te, które znajdują się już na stronie, nie musi to być przyczyną. Następne 2 przykłady pokazują LCP występujące przed pełnym wczytaniem strony.
W pierwszym przykładzie logo Instagrama jest ładowane stosunkowo wcześnie i pozostaje największym elementem, mimo że inne treści są pokazywane stopniowo. Na przykład na stronie wyników wyszukiwania Google największym elementem jest akapit tekstu wyświetlany przed zakończeniem wczytywania obrazu lub logo. Ponieważ wszystkie obrazy są mniejsze od tego akapitu, pozostaje on największym elementem podczas procesu wczytywania.
Jak mierzyć LCP
LCP można mierzyć w module lub w terenie. Ten wskaźnik jest dostępny w tych narzędziach:
Narzędzia terenowe
- Raport na temat użytkowania Chrome
- PageSpeed Insights
- Search Console (raport dotyczący podstawowych wskaźników internetowych)
- Biblioteka JavaScript
web-vitals
Narzędzia laboratoryjne
Mierz LCP w JavaScript
Aby zmierzyć LCP w języku JavaScript, możesz użyć interfejsu Largest Contentful Paint API. Z przykładu poniżej dowiesz się, jak utworzyć PerformanceObserver, który nasłuchuje wpisów largest-contentful-paint i rejestruje je w konsoli.
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
console.log('LCP candidate:', entry.startTime, entry);
}
}).observe({type: 'largest-contentful-paint', buffered: true});
W powyższym przykładzie każdy zarejestrowany wpis largest-contentful-paint reprezentuje bieżący kandydat do LCP. Ogólnie wartość startTime ostatniej wysłanej pozycji to wartość LCP, ale nie zawsze tak jest. Nie wszystkie wpisy largest-contentful-paint są odpowiednie do pomiaru LCP.
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 w tle interfejs API wysyła wpisy
largest-contentful-paint, ale należy je zignorować przy obliczaniu LCP. - Interfejs API będzie nadal wysyłać wpisy
largest-contentful-paint, gdy strona zacznie działać w tle, ale te wpisy należy zignorować przy obliczaniu LCP (elementy mogą być brane pod uwagę tylko wtedy, gdy strona przez cały czas znajdowała się na pierwszym planie). - Interfejs API nie zgłasza wpisów
largest-contentful-paint, gdy strona jest przywracana z pamięci podręcznej stanu strony internetowej, ale w takich przypadkach należy mierzyć LCP, ponieważ użytkownicy postrzegają je jako osobne wizyty na stronie. - Interfejs API nie uwzględnia elementów w elementach iframe, ale dane są uwzględniane, ponieważ są częścią wrażeń użytkownika na stronie. Na stronach z LCP w elemencie iframe (na przykład w przypadku obrazu plakatu w umieszczonym filmie) będzie to różnica między wskaźnikami CrUX i RUM. Aby właściwie mierzyć LCP, weź je pod uwagę. Ramki podrzędne mogą używać interfejsu API do zgłaszania swoich wpisów
largest-contentful-paintdo ramki nadrzędnej na potrzeby agregacji. - Interfejs API mierzy LCP od początku nawigacji, ale w przypadku wstępnie renderowanych stron LCP należy mierzyć od
activationStart, ponieważ odpowiada to czasowi LCP.
Zamiast zapamiętywać wszystkie te subtelne różnice, programiści mogą użyć biblioteki JavaScript web-vitals do pomiaru LCP, która obsługuje te różnice (tam, gdzie to możliwe, problem z elementami iframe nie jest omówiony):
import {onLCP} from 'web-vitals';
// Measure and log LCP as soon as it's available.
onLCP(console.log);
Pełny przykład pomiaru LCP w JavaScript znajdziesz w kodzie źródłowym onLCP().
Co zrobić, jeśli największy element nie jest najważniejszy?
W niektórych przypadkach najważniejszy element (lub elementy) na stronie nie jest taki sam jak największy z nich. Deweloperzy mogą być bardziej zainteresowani pomiarami czasów renderowania tych elementów. Możesz to zrobić, korzystając z interfejsu Element Timing API, jak opisano w artykule o danych niestandardowych.
Jak poprawić LCP
Dostępny jest pełny przewodnik na temat optymalizacji LCP, który przeprowadzi Cię przez proces identyfikowania czasów LCP w terenie oraz korzystania z danych laboratoryjnych do ich analizy i analizy.
Dodatkowe materiały
- Wnioski z monitorowania wydajności w Chrome napisane przez Annie Sullivan, performance.now() (2019)
Historia zmian
Czasami błędy wykrywane są w interfejsach API używanych do pomiaru danych, a czasem w definicjach samych danych. Dlatego czasem trzeba wprowadzać określone zmiany, które mogą być widoczne w wewnętrznych raportach i panelach jako ulepszenia lub regresje.
Aby Ci w tym pomóc, wszystkie zmiany w implementacji lub definicji tych danych będą pojawiać się w tej historii zmian.
Jeśli chcesz podzielić się swoją opinią na temat tych danych, możesz ją przekazać w grupie dyskusyjnej Google web-vitals-feedback.