Data publikacji: 11 lutego 2025 r.
Wersja raportu na temat użytkowania Chrome (CrUX) z lutego 2025 r. zawiera wiele nowych (i zmienionych!) danych:
- Największe wyrenderowanie treści (LCP): części obrazu i typy zasobów
- Szczegóły czasu błądzenia (RTT)
- Usunięcie wymiaru „Efektywny typ połączenia”
Każdy z nich zapewnia lepszy wgląd w dane o skuteczności źródeł i adresów URL dostępnych w raporcie CrUX. W tym artykule wyjaśnimy, dlaczego tak się dzieje.
Informacje diagnostyczne dotyczące LCP
Koncepcję części składowych LCP przedstawiliśmy na konferencji Google I/O 2022 jako skuteczną technikę podziału czasu LCP na stronach z elementami LCP typu obraz na mniejsze komponenty, aby umożliwić Ci optymalizację przyczyn wysokiego LCP.
Analiza danych z laboratorium HTTP Archive przedstawiona w tym wystąpieniu wykazała, że czas pobierania obrazów często stanowi najmniejszą część czasu LCP. Wiele narzędzi do testów laboratoryjnych (w tym Lighthouse firmy Google) często koncentrowało się na radach dotyczących optymalizacji formatów i rozmiarów obrazów w celu skrócenia czasu pobierania i zwiększenia wydajności. Chociaż ta porada była prawidłowa, analiza wykazała, że może ona być przesadnie podkreślona, a większym problemem są opóźnienia przed znalezieniem obrazu przez przeglądarkę i rozpoczęciem jego pobierania.
Chociaż analiza danych laboratoryjnych może być przydatna, sposób korzystania z Internetu w życiu codziennym często różni się od tego, co dzieje się w laboratorium, dlatego ważne jest, aby mieć możliwość wyświetlania tych podczęści danych zgromadzonych. W poście opublikowanym w zeszłym roku potwierdzono, że częsty błąd dotyczący optymalizacji LCP na podstawie danych polowych.
Elementy składowe LCP
W ramach tej wersji właściciele witryn mogą sprawdzać na swoich stronach części składowe LCP obrazu na poziomie pochodzenia lub adresu URL.
Podelementy są dostępne tylko w przypadku obrazów i nie obejmują obrazów z pierwszego kadru filmu (które są nieco bardziej skomplikowane, ponieważ nie możemy zmierzyć pełnego czasu pobierania). Nie uwzględniamy też części tekstu, ponieważ są one mniej przydatne i mogłyby zniekształcać liczby LCP obrazu. W przypadku witryn, które składają się głównie z tekstowych LCP, przydatne są dane dotyczące łącznego czasu oczekiwania na odpowiedź i łącznego czasu wyświetlenia treści, choć dotyczą one wszystkich LCP, a nie tylko tekstowych LCP. Wreszcie, dane dotyczące części obrazu są zbierane tylko podczas pełnego wczytania strony, w przeciwieństwie do danych LCP, które są zbierane również podczas przewijania w górę i w dół oraz na stronach wstępnie wyrenderowanych.
Od lutego 2025 r. te dane są dodawane do interfejsu CrUX API i interfejsu CrUX History API (uwaga: nie do BigQuery). W momencie wprowadzenia interfejs CrUX History API zawiera dane z 2 tygodni, ale z czasem będzie ich przybywać, aż do pełnych 25 tygodni. Interfejsy API udostępniają dane jako 75. centyl każdej części wyrażonej w milisekundach.
Aby na przykład uzyskać części składowe obrazu LCP dla https://web.dev/ w przypadku PHONE odsłon, możesz użyć tego polecenia curl (zastępując API_KEY własnym kluczem):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": [
"largest_contentful_paint_image_time_to_first_byte",
"largest_contentful_paint_image_resource_load_delay",
"largest_contentful_paint_image_resource_load_duration",
"largest_contentful_paint_image_element_render_delay"]}'
Otrzymasz odpowiedź podobną do tej:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_image_element_render_delay": {
"percentiles": {
"p75": 2088
}
},
"largest_contentful_paint_image_resource_load_delay": {
"percentiles": {
"p75": 828
}
},
"largest_contentful_paint_image_resource_load_duration": {
"percentiles": {
"p75": 417
}
},
"largest_contentful_paint_image_time_to_first_byte": {
"percentiles": {
"p75": 2385
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Zaktualizowaliśmy narzędzie CrUX Vis, aby uwzględniało te dane. Spodziewamy się, że inne narzędzia innych firm, które korzystają z interfejsów API CrUX, również będą udostępniać te cenne dane:
W tym przykładzie widzimy, że w przypadku popularnej witryny z multimediami najmniejszy komponent to czas wczytywania zasobu. Prawdziwe możliwości poprawy w przypadku tej witryny kryją się w TTFB i opóźnieniu ładowania zasobów, a mniejsze możliwości poprawy dotyczą opóźnienia renderowania elementu.
Wysokie wartości w poszczególnych częściach wskazują na różne problemy:
- Długi czas do pierwszego bajta (TTFB) zwykle wskazuje na problemy z serwerem, siecią lub przekierowaniem, jak wyjaśniono w artykule Optymalizacja TTFB.
- Wysokie opóźnienie wczytywania zasobu wskazuje, że przeglądarka późno wykryła obraz LCP. Może to być na przykład obraz LCP wstrzyknięty przez kod JavaScript po stronie klienta, którego wykonanie zajmuje trochę czasu.
- Jeśli czas wczytywania zasobów jest długi, warto zmniejszyć rozmiar pobieranych obrazów.
- Wysokie opóźnienie renderowania elementu występuje, gdy obraz jest dostępny (być może przez
<link rel=preload>, ale nie jest używany przez długi czas – znowu często z powodu tego, że do wyświetlenia obrazu wymagany jest kod JavaScript po stronie klienta.
Mamy nadzieję, że udostępnienie tych danych w narzędziu CrUX na poziomie pochodzenia i adresu URL (z uwzględnieniem standardowych kryteriów kwalifikowania) ułatwi witrynom optymalizację wartości LCP.
Typy zasobów LCP
Części składowe są najprzydatniejsze w przypadku obrazów LCP, dlatego CrUX ogranicza te dane tylko do stron z obrazami. Dlatego ważne jest, aby wiedzieć, ile z Twoich wyników LCP to wyniki LCP obrazów, a ile wyników LCP tekstu (np. nagłówki <h1> i długie akapity).
Oprócz części składowych obrazu LCP interfejsy API CrUX zawierają teraz również podział zasobów, który pokazuje podział wczytywania strony LCP na tekst i obrazy.
Aby na przykład pobrać typy zasobów LCP dla https://web.dev/ w przypadku PHONE wyświetleń strony, możesz użyć tego polecenia curl (ponownie zastąp API_KEY własnym kluczem):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["largest_contentful_paint_resource_type"]}'
Otrzymasz odpowiedź podobną do tej:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_resource_type": {
"fractions": {
"image": 0.0155,
"text": 0.9845
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Zaktualizowaliśmy też wizualizację CrUX, aby wyświetlała te dane:
W przypadku strony głównej web.dev widzimy, że 98,5% LCP to tak naprawdę LCP tekstu, więc w przypadku tej strony podelementy LCP obrazu są mniej przydatne. W takim przypadku możemy użyć pierwotnych danych TTFB i FCP jako potencjalnie lepszego narzędzia do diagnostyki.
Typy zasobów LCP to kolejne przydatne narzędzie diagnostyczne, które pomaga zrozumieć i poprawić LCP, zwłaszcza w zakresie oceny przydatności poszczególnych części obrazu LCP.
Informacje diagnostyczne dotyczące RTT
Rozszerzyliśmy też dane RTT, które zostały po raz pierwszy udostępnione w sierpniu 2024 r.
Trójkąty RTT
Do interfejsów CrUX API dodaliśmy 3 grupy, które pokazują 3 grupowania gęstości RTT:
| Opóźnienie w sieci | Rozpocznij | Zakończ |
|---|---|---|
| Niski | 0 ms | < 75 ms |
| Średni | 75 milisekund | < 275 ms |
| Wysoki | 275 ms | ∞ |
Te przedziały są bardziej precyzyjne niż poprzednie kategorie ECT, które obejmowały wszystko poniżej 270 ms w kategorii 4g. Od czasu ich wprowadzenia nastąpiły postępy w technologii sieci, dzięki którym większość witryn uzyskała większość ruchu w tej kategorii, co sprawiło, że ta kategoria stała się mniej przydatna.
Dlatego zalecamy używanie etykiet niska, średnia i wysoka zamiast zwykłych etykiet dobra, wymagająca poprawy i słaba. Nie są to dane, których właściciel witryny może bezpośrednio ulepszyć, dlatego są to dane diagnostyczne, które pomagają zrozumieć inne dane i wyjaśniają, dlaczego mogą się one różnić od oczekiwanych. Mogą one też wyjaśniać, dlaczego inne dane zmieniają się w czasie, mimo że strona nie ulega zmianie, jeśli pokazują one zmianę w grupie użytkowników.
Te zbiory są dostępne w interfejsach API CrUX, np. web.dev dla PHONE wyświetleń strony (z wykorzystaniem wartości API_KEY z Twoim kluczem):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["round_trip_time"]}'
Zwraca ona mniej więcej taki wynik:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"round_trip_time": {
"histogram": [
{
"start": 0,
"end": 75,
"density": 0.1524
},
{
"start": 75,
"end": 275,
"density": 0.6641
},
{
"start": 275,
"density": 0.1835
}
],
"percentiles": {
"p75": 230
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Przedziały są widoczne w CrUX Vis, gdy wybrane są rozkłady:
RTT w BigQuery
Oprócz rozszerzenia danych RTT w interfejsach API CrUX o trzy zbiory, udostępniliśmy je też w comiesięcznym zbiorze danych BigQuery, w tym pełny histogram w zakresach 25 ms w tabelach nieprzetworzonych oraz wartości z trzy zbiorów i p75 w tabelach zmaterializowanych.
Dzięki temu możesz lepiej poznać rozkład danych wykraczający poza trzy kategorie dostępne w interfejsach API CrUX. Umożliwia nam to też odtworzenie podziału według ECT, który został usunięty z CrUX w tym miesiącu (więcej informacji na ten temat znajdziesz później). Wprowadziliśmy przy tym niewielką zmianę progu 4g do 275 ms zamiast poprzedniego progu 270 ms. Szczegółowe dane dotyczące ECT (pochodzące teraz z danych RTT) są nadal dostępne w zmaterializowanych tabelach BigQuery w Chrome UX Report, więc narzędzia takie jak dashboard w Chrome UX Report mogą nadal wyświetlać te dane.
Zbiór danych BigQuery zawiera też dane według kraju (zdefiniowanego zgodnie ze standardem ISO 3166-1). Dzięki temu możesz przeprowadzić dokładniejsze analizy, które mogą pomóc w znalezieniu przyczyny gorszych wyników niektórych użytkowników. Możemy na przykład sprawdzić dane użytkowników Google Phone, analizując dane o https://www.google.com:
SELECT
`chrome-ux-report`.experimental.GET_COUNTRY(country_code) AS geo,
least(500, p75_rtt) AS capped_p75_rtt,
p75_rtt
FROM
`chrome-ux-report.materialized.country_summary`
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202501 AND
device = 'phone'
ORDER BY
p75_rtt DESC,
country_code
Następnie wizualizujemy dane na mapie geograficznej:
https://www.google.com(dane źródłowe z interaktywną wykresem).
Widzimy, że chociaż większość świata (zwłaszcza „świat zachodni”) ma bardzo dobre wartości RTT, w Afryce Subsaharyjskiej, częściach Bliskiego Wschodu i częściach Azji jest gorzej. W rzeczywistości wykres jest ograniczony do wartości RTT 500 ms, ponieważ użycie pełnych danych spowodowało odchylenia kolorów – zwłaszcza w przypadku Erytrei, gdzie 75. procentyl wynosi 3850 ms.
Może to być też przydatne, gdy zmieniają się wzorce ruchu. Na przykład większa liczba użytkowników z krajów o większych wartościach RTT może tłumaczyć gorsze statystyki Core Web Vitals, mimo że nic nie zmieniło się w witrynie.
Chociaż witryny nie mogą bezpośrednio poprawiać wartości RTT, udostępnienie tych danych użytkownikom pozwala lepiej poznać użytkowników witryny na całym świecie. Daje też wiele możliwości analizy w przyszłości. Mamy nadzieję, że badacze znajdą w tym zbiorze danych interesujące statystyki.
Usunięcie wymiaru ECT
Ostatnią zmianą we wrześniu 2025 r. jest wycofanie z BigQuery wymiaru „Effective Connection Type” (ECT) (z interfejsów API usunęliśmy już w wrześniu 2024 r., gdy wprowadziliśmy w jego miejsce wymiar RTT).
Jak już wspomnieliśmy w tym poście, wskaźnik RTT umożliwia dokładniejsze wyświetlanie szczegółów połączenia użytkowników witryny. Na podstawie tych histogramów możesz nawet odtworzyć zbiory ECT. (Technicznie rzecz biorąc, ECT to połączenie RTT i szybkości połączenia w dół, ale Chrome używa tylko RTT).
Ważną różnicą jest to, że ECT był wymiarem Crux, co oznacza, że inne dane można było podzielić na segmenty według tego wymiaru. RTT to dane Crux, a nie wymiar, więc nie można wyświetlić np. LCP według RTT, ale można zobaczyć RTT według innych wymiarów (typu urządzenia i kraju).
Może się to wydawać bardziej ograniczające, ale przejście z wymiaru na rodzaj danych spowoduje, że w UXP będzie dostępnych więcej danych. Dzieje się tak, ponieważ zanim dane mogą się wyświetlić, muszą osiągnąć określony minimalny próg w CrUX. Wskaźniki stały się opcjonalne w 2022 r., co oznacza, że usunęliśmy ECT lub urządzenie, jeśli było to konieczne do raportowania na wyższym poziomie, ale wskaźniki, które nie były dostępne w przypadku większości wczytanych stron (czas od interakcji do następnego wyrenderowania (INP), różne typy nawigacji i obecnie części obrazu LCP) często nie były dostępne dla źródeł w BigQuery.
Zmniejszenie liczby wymiarów powoduje, że dane są mniej podzielone na segmenty, co zwiększa liczbę źródeł spełniających te wymagania minimalne. W styczniu odnotowaliśmy INP w przypadku 68, 1% miejsc pochodzenia, podczas gdy w przypadku zbioru danych z grudnia odnotowaliśmy INP tylko w przypadku 64, 5% miejsc pochodzenia. Mechanizm ten dotyczy również typów nawigacji, części LCP i typów zasobów w tej wersji – wszystkie one korzystają z usunięcia wymiaru czasu ładowania strony. W przypadku interfejsów API CrUX zwiększone pokrycie weszło w życie na początku lutego.
Kolumny ECT pozostaną w BigQuery, aby zachować spójność z poprzednimi zbiorami danych. Dane ECT w zmaterializowanych widokach będą nadal dostępne, ale będą oparte na informacjach RTT (z różnicą 5 milisekund w przypadku 3g i 4g, jak wspomniano wcześniej) oraz na nowych wartościach RTT p75 i trójkątnych.
Podsumowanie
Dodanie do publicznego zbioru danych CrUX większej liczby danych zapewnia właścicielom witryn i badaczom znacznie więcej informacji, które ułatwiają diagnozowanie i rozwiązywanie problemów z wydajnością.
Jako publiczny zbiór danych CrUX ma pewne ograniczenia dotyczące poziomu szczegółowości, jaki możemy wyświetlać. Na przykład selektory poszczególnych elementów nigdy nie będą widoczne w CrUX. Właścicielom witryn, którzy potrzebują tego poziomu szczegółowości, zdecydowanie zalecamy wdrożenie rozwiązania RUM, które nie będzie tak ograniczone.
Jednak dane zagregowane na wyższym poziomie, takie jak te opisane w tym poście, mogą pomóc w znalezieniu odpowiedzi na pytanie, dlaczego występuje dany problem. Mamy nadzieję, że te dodatkowe dane okażą się przydatne. Jeśli masz uwagi lub pytania, daj nam znać w grupie dyskusyjnej.