Dane

Data publikacji: 23 czerwca 2022 r., ostatnia aktualizacja: 18 listopada 2025 r.

Dane w CrUX są oparte na standardowych interfejsach API platformy internetowej udostępnianych przez przeglądarki. W zbiorze danych BigQuery te dane są agregowane do rozdzielczości pochodzenia. Właściciele witryn, którzy potrzebują bardziej szczegółowej analizy (np. na poziomie adresu URL) i statystyk dotyczących wydajności witryny, mogą używać tych samych interfejsów API do zbierania szczegółowych danych pomiarowych od rzeczywistych użytkowników (RUM) dotyczących ich własnych originów. Pamiętaj, że wszystkie interfejsy API są dostępne w Chrome, ale inne przeglądarki mogą nie obsługiwać pełnego zestawu danych.

Większość danych jest przedstawiana w formie histogramu, co umożliwia wizualizację rozkładu i przybliżone określenie wartości percentyli.

zbiorcze przesunięcie układu

„Skumulowane przesunięcie układu (CLS) to ważny wskaźnik związany z wygodą użytkownika, informujący o stabilności wizualnej, ponieważ pomaga określić, jak często użytkownicy doświadczają nieoczekiwanych przesunięć układu. Niski CLS zapewnia przyjemne korzystanie ze strony”.

web.dev/articles/cls

Załadowana zawartość DOM

„DOMContentLoaded raportuje, kiedy początkowy dokument HTML został w pełni załadowany i przeanalizowany bez czekania, aż skończą się ładować arkusze stylów, obrazy i ramki”.

MDN

Pierwsze otwarcie

„Pierwsze wyświetlenie” to czas pierwszego renderowania w przeglądarce po przejściu na daną stronę. Nie uwzględnia to domyślnego renderowania w tle, ale uwzględnia niedomyślne renderowanie w tle. Jest to pierwszy kluczowy moment, na którym zależy deweloperom podczas wczytywania strony – gdy przeglądarka zaczyna renderować stronę”.

Paint Timing API

Pierwsze wyrenderowanie treści

„Pierwsze wyrenderowanie treści (FCP) to czas, gdy przeglądarka po raz pierwszy wyrenderowała tekst, obraz (w tym obraz tła), SVG lub obiekt canvas, który nie jest pusty. Obejmuje to też tekst z oczekującymi czcionkami internetowymi. Jest to pierwszy moment, w którym użytkownicy mogą zacząć korzystać z treści strony”.

Paint Timing API

Interakcja do kolejnego wyrenderowania

„Interakcja do kolejnego wyrenderowania (INP) to wskaźnik polowy, który ocenia responsywność. INP rejestruje czas oczekiwania w odniesieniu do wszystkich interakcji w całym cyklu życia strony. Najwyższa wartość tych interakcji – lub zbliżona do najwyższej w przypadku stron z wieloma interakcjami – jest rejestrowana jako INP strony. Niska wartość INP zapewnia, że strona będzie zawsze niezawodnie reagować na działania użytkownika”.

web.dev/articles/inp

Wskaźnik INP został dodany do zbioru danych CrUX w lutym 2022 r. Te nowe dane obejmują opóźnienie poszczególnych zdarzeń od początku do końca i dają bardziej całościowy obraz ogólnej szybkości reakcji strony w całym okresie jej istnienia.

największe wyrenderowanie treści

„Największe wyrenderowanie treści (LCP) to ważny wskaźnik związany z wygodą użytkownika, informujący o postrzeganej szybkości wczytywania, ponieważ oznacza na osi czasu wczytywania strony moment, w którym prawdopodobnie załadowano jej główną zawartość. Szybkie LCP pomaga upewnić użytkownika, że strona jest przydatna”.

web.dev/articles/lcp

Typ zasobu największego wyrenderowania treści

„LCP wskazuje czas renderowania największego obrazu, bloku tekstu lub filmu wyświetlanego w widocznym obszarze w odniesieniu do czasu, w którym użytkownik po raz pierwszy przeszedł na stronę”.

web.dev/articles/lcp – What elements are considered for LCP

Tekst i obraz (w tym pierwsza klatka filmu) często mają bardzo różne charakterystyki wczytywania i techniki optymalizacji. Znajomość proporcji typów zasobów LCP pozwala lepiej zrozumieć dane LCP i ścieżki optymalizacji.

Więcej informacji znajdziesz w poście na blogu o wprowadzeniu typów zasobów LCP.

Podczęści obrazu największego wyrenderowania treści

„Optymalizacja LCP może być bardziej złożona, gdy PageSpeed Insights nie podaje odpowiedzi na pytanie, jak poprawić ten wskaźnik. W przypadku skomplikowanych zadań lepiej jest podzielić je na mniejsze, łatwiejsze części i zająć się nimi oddzielnie”.

web.dev/articles/optimize-lcp – podział LCP na mniejsze części

Podzielenie LCP obrazów na najważniejsze podczęści umożliwia korzystanie z konkretnych rekomendacji i sprawdzonych metod optymalizacji każdej z nich.

Podział obrazu LCP jest podawany w 4 osobnych danych:

  • 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

Podczęści są uwzględniane tylko w przypadku obrazów, ale nie obejmują pierwszych klatek wideo, ponieważ są one nieco bardziej skomplikowane, gdyż nie możemy zmierzyć pełnego czasu pobierania (pamiętaj, że pierwsze klatki wideo są uwzględniane w wskaźniku typu zasobu LCP, w przypadku którego ta komplikacja nie ma znaczenia).

Nie uwzględniamy też części tekstowych, ponieważ są mniej przydatne i zniekształcają wartości LCP obrazów. W przypadku witryn, które w większości składają się z tekstu, przydatne są ogólne dane TTFBFCP, chociaż dotyczą one wszystkich elementów LCP, a nie tylko tekstowych.

Więcej informacji znajdziesz w poście na blogu o wprowadzeniu podczęści obrazu LCP.

Dane Typy nawigacji przedstawiają zestawienie odsetka wyświetleń strony w przypadku tych typów nawigacji:

Typ Opis
navigate Wczytanie strony, które nie pasuje do żadnej z pozostałych kategorii.
navigate_cache Wczytanie strony, w przypadku którego główny zasób (główny dokument HTML) został wyświetlony z pamięci podręcznej HTTP. Witryny często korzystają z pamięci podręcznej w przypadku zasobów podrzędnych, ale główny dokument HTML jest często znacznie rzadziej zapisywany w pamięci podręcznej. Jeśli jednak jest to możliwe, może to znacznie poprawić wydajność, ponieważ dokument może być zapisywany w pamięci podręcznej lokalnie i w sieci CDN.
reload Użytkownik ponownie załadował stronę, klikając przycisk ponownego załadowania, naciskając Enter w pasku adresu lub cofając zamknięcie karty. Częste ponowne ładowanie strony powoduje ponowną weryfikację na serwerze, aby sprawdzić, czy strona główna uległa zmianie. Wysoki odsetek ponownych wczytań strony może wskazywać na frustrację użytkowników.
restore Strona została ponownie załadowana po ponownym uruchomieniu przeglądarki lub karty, która została usunięta z powodu braku pamięci. W przypadku Chrome na Androida są one zgłaszane jako „reload”.
back_forward Nawigacja w historii, co oznacza, że strona była niedawno wyświetlana i użytkownik do niej wrócił. Przy prawidłowym buforowaniu powinny one działać dość szybko, ale nadal wymagają przetworzenia strony i wykonania JavaScriptu, czego unika pamięć podręczna typu „wstecz/do przodu”.
back_forward_cache Nawigacja po historii, która została wyświetlona z pamięci podręcznej stanu strony internetowej. Optymalizacja stron pod kątem korzystania z pamięci podręcznej typu „wstecz/do przodu” przez usuwanie elementów blokujących powinna przyspieszyć działanie witryny.
prerender Strona została wstępnie wyrenderowana, co podobnie jak w przypadku pamięci podręcznej stanu strony internetowej może skutkować niemal natychmiastowym wczytywaniem strony.

W niektórych przypadkach wczytanie strony może być kombinacją kilku typów nawigacji. W takim przypadku raport na temat użytkowania Chrome podaje pierwsze dopasowanie w odwrotnej kolejności niż w tabeli (od dołu do góry).

Więcej informacji znajdziesz w poście z ogłoszeniem o typach nawigacji.

Onload

„Zdarzenie wczytywania jest wywoływane, gdy strona i jej zasoby zależne zostaną wczytane”.

MDN

Czas błądzenia

Podaje szacowany czas podróży w obie strony w przypadku protokołu HTTP (warstwa aplikacji) na początku nawigacji na podstawie ostatnich połączeń sieciowych. Ta wartość jest obliczana na podstawie właściwości rtt interfejsu Network Information API, który jest tym samym interfejsem API, który odpowiadał za poprzedni wymiar Efektywny typ połączenia (ECT).

Więcej informacji znajdziesz w poście na blogu o wprowadzeniu typów zasobów LCP.

Dane eksperymentalne

Dane eksperymentalne są dostępne w zbiorze danych CrUX w BigQuery, a niektóre z nich także w interfejsie CrUX API. Te dane mogą się regularnie zmieniać, ponieważ są dostosowywane na podstawie opinii użytkowników. Aby być na bieżąco z najnowszymi zmianami, zapoznaj się z informacjami o wersji.

Czas do pierwszego bajtu

Dane TTFB w CrUX są zbierane tylko w przypadku pełnego wczytania strony, w przeciwieństwie do innych liczników (np. LCP), które są też zbierane w przypadku nawigacji z pamięci podręcznej stanu strony internetowej (bfcache)wstępnie renderowanych stron. Dlatego rozmiar próbki TTFB może być mniejszy niż w przypadku innych danych i nie musi być z nimi bezpośrednio porównywany. TTFB w CrUX obejmuje wczytywanie stron bez pamięci podręcznej, wczytywanie stron z pamięci podręcznej i wczytywanie stron z ustalonego połączenia (np. wczytywanie stron w obrębie witryny).

TTFB nie jest bezpośrednim pomiarem czasu odpowiedzi serwera, ponieważ obejmuje też pomiary wcześniejsze, w tym czas przekierowania, i zależy od tego, czy odpowiedź jest udostępniana z pamięci podręcznej, sieci CDN czy serwera. Jest to szczególnie widoczne w przypadku danych z terenu, takich jak CrUX, podczas gdy testy laboratoryjne są zwykle mniej podatne na te czynniki, ponieważ testowany jest końcowy adres URL i często wielokrotnie negowane są zmiany w pamięci podręcznej.

Popularność

Wskaźnik pozycja pod względem popularności to względna miara popularności witryny w zbiorze danych CrUX, mierzona łączną liczbą nawigacji w źródle. Ranga jest podana w skali logarytmicznej o podstawie 10 z krokami o wartości 0, 5 (np. 1 tys., 5 tys., 10 tys., 50 tys., 100 tys., 500 tys., 1 mln itd.). Każda ranga wyklucza poprzednią (np. 5 tys. to w rzeczywistości 4 tys. adresów URL, z wyłączeniem 1 tys.). Górny limit jest dynamiczny i zmienia się wraz ze wzrostem zbioru danych.

Popularność jest podawana jako wskazówka do przeprowadzenia ogólnej analizy, np. do określenia skuteczności według kraju w przypadku 1000 najpopularniejszych źródeł.

Zgoda na wyświetlanie powiadomień

W przypadku witryn, które proszą użytkowników o zgodę na wyświetlanie powiadomień, te dane przedstawiają względną częstotliwość odpowiedzi użytkowników na prośby: akceptacja, odrzucenie, zignorowanie lub zamknięcie.