Dane

Opublikowano: 23 czerwca 2022 r., ostatnia aktualizacja: 13 października 2026 r.

Dane w raporcie na temat użytkowania Chrome są generowane przez standardowe interfejsy API platformy internetowej udostępniane przez przeglądarki. W zbiorze danych BigQuery te dane są agregowane do poziomu źródła. Właściciele witryn, którzy potrzebują bardziej szczegółowej analizy (np. na poziomie adresu URL) i statystyk dotyczących skuteczności witryny, mogą używać tych samych interfejsów API do zbierania szczegółowych danych o pomiarach rzeczywistych użytkowników (RUM) w swoich źródłach. 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 jako agregacja histogramu, co umożliwia wizualizację rozkładu i przybliżanie wartości percentyli.

Skumulowane 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. Niska wartość CLS pomaga zapewnić, że strona jest przyjemna w użyciu”.

web.dev/articles/cls

Wczytanie treści DOM

„DOMContentLoaded informuje o czasie, w którym początkowy dokument HTML został w pełni wczytany i przeanalizowany, bez oczekiwania na zakończenie wczytywania arkuszy stylów, obrazów i ramek podrzędnych”.

MDN

Pierwsze otwarcie

„Pierwsze otwarcie informuje o czasie, w którym przeglądarka po raz pierwszy wyrenderowała stronę po nawigacji. Nie obejmuje to domyślnego malowania tła, ale obejmuje malowanie tła inne niż domyślne. Jest to pierwszy kluczowy moment, na którym zależy programistom podczas wczytywania strony – gdy przeglądarka zacznie renderować stronę”.

Paint Timing API

Pierwsze wyrenderowanie treści

„Pierwsze wyrenderowanie treści (FCP) informuje o czasie, w którym przeglądarka po raz pierwszy wyrenderowała tekst, obraz (w tym obrazy tła), płótno inne niż białe lub SVG. Obejmuje to 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, który ocenia responsywność. INP rejestruje czas oczekiwania 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 responsywna”.

web.dev/articles/inp

Interakcja do kolejnego wyrenderowania (INP) została dodana do zbioru danych CrUX w lutym 2022 r.. Ten nowy wskaźnik rejestruje czas oczekiwania poszczególnych zdarzeń od początku do końca i zapewnia bardziej całościowy obraz ogólnej responsywności strony w całym jej cyklu życia.

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 moment na osi czasu wczytywania strony, w którym prawdopodobnie załadowano jej główną zawartość. Szybka wartość LCP pomaga zapewnić 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 – jakie elementy są brane pod uwagę w przypadku LCP

Tekst i obraz (w tym obraz pierwszej klatki 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 dotyczącym wprowadzenia typów zasobów LCP.

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

„Optymalizacja LCP może być bardziej złożonym zadaniem, jeśli PageSpeed Insights nie podaje odpowiedzi na pytanie, jak poprawić ten wskaźnik. W przypadku złożonych zadań lepiej jest podzielić je na mniejsze, łatwiejsze do zarządzania zadania i rozwiązywać je oddzielnie”.

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

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

Podczęści obrazu LCP są podawane 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, a nie obrazów pierwszej klatki filmu, ponieważ są one nieco bardziej skomplikowane – nie możemy zmierzyć pełnego czasu pobierania (pamiętaj, że pierwsze klatki filmu są uwzględniane w danych typu zasobu LCP, gdzie ta komplikacja nie ma znaczenia).

Podczęści tekstu też nie są uwzględniane, ponieważ są mniej przydatne i zniekształcają liczby LCP obrazu. W przypadku witryn, które składają się głównie z tekstu LCP, przydatne są ogólne dane TTFB i ogólne dane FCP – pamiętaj jednak, że dotyczą one wszystkich LCP, a nie tylko LCP tekstu.

Więcej informacji znajdziesz w poście na blogu dotyczącym wprowadzenia podczęści obrazu LCP.

Dane typy nawigacji zawierają podział procentowy odsłon stron według 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órej główny zasób (główny dokument HTML) został udostępniony 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 zapisywany w pamięci podręcznej znacznie rzadziej. Jeśli można go zapisać w pamięci podręcznej, może to spowodować zauważalną poprawę wydajności dzięki możliwości zapisania go w pamięci podręcznej lokalnie i w CDN.
reload Użytkownik ponownie wczytał stronę, klikając przycisk ponownego wczytania, naciskając Enter na pasku adresu lub cofając zamknięcie karty. Ponowne wczytanie strony często powoduje ponowne sprawdzenie na serwerze, czy główna strona się zmieniła. Wysoki odsetek ponownych wczytań strony może wskazywać na frustrację użytkowników.
restore Strona została ponownie wczytana po ponownym uruchomieniu przeglądarki lub karty, która została usunięta z powodu braku pamięci. W przypadku Chrome na Androidzie 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 zapisywaniu w pamięci podręcznej powinny to być dość szybkie działania, ale nadal wymagają przetworzenia strony i wykonania JavaScriptu – czego unika bfcache.
back_forward_cache Nawigacja w historii, która została udostępniona z bfcache. Optymalizacja stron pod kątem korzystania z bfcache przez usunięcie blokad powinna skutkować szybszym działaniem, dlatego witryny powinny
prerender Strona została wstępnie wyrenderowana, co – podobnie jak w przypadku bfcache – może spowodować niemal natychmiastowe wczytanie strony.

W niektórych przypadkach wczytanie strony może być połączeniem kilku typów nawigacji. W takim przypadku CrUX zgłasza pierwsze dopasowanie w odwrotnej kolejności tabeli (od dołu do góry).

Więcej informacji znajdziesz w poście dotyczącym ogłoszenia o typach nawigacji.

Onload

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

MDN

Czas błądzenia

Podaje szacunkowy czas błądzenia HTTP (warstwy aplikacji) na początku nawigacji na podstawie ostatnich połączeń sieciowych. Te dane są oparte na właściwości rtt interfejsu Network Information API, czyli tego samego interfejsu API, który odpowiada za poprzedni wymiar Efektywny typ połączenia (ECT).

Więcej informacji znajdziesz w poście na blogu dotyczącym wprowadzenia typów zasobów LCP.

Dane eksperymentalne

Dane eksperymentalne są dostępne zarówno w zbiorze danych CrUX w BigQuery, jak i w interfejsie CrUX API, ale nie wszystkie dane są dostępne w obu tych miejscach. Te dane mogą ulec zmianie, ponieważ są rozwijane na podstawie opinii użytkowników. Aby być na bieżąco z najnowszymi zmianami, zapoznaj się z informacjami o wersji.

Eksperymentalne dane Core Web Vitals dotyczące nawigacji miękkiej

W wersji z października 2026 r. wprowadziliśmy eksperymentalne wersje danych Core Web Vitals, w tym dotyczące nawigacji miękkiej:

  • experimental_largest_contentful_paint_with_softnavs
  • experimental_interaction_to_next_paint_with_softnavs
  • experimental_cumulative_layout_shift_with_softnavs

Te dane obejmują zarówno pełne wczytanie strony, jak i nawigację miękką.

Więcej informacji znajdziesz w artykule Wprowadzenie eksperymentalnych danych Core Web Vitals do raportu na temat użytkowania Chrome.

Czas do pierwszego bajtu

TTFB w CrUX jest zbierany tylko podczas pełnego wczytywania strony, w przeciwieństwie do innych liczników czasu (np. LCP), które są też zbierane podczas nawigacji w pamięci podręcznej stanu strony internetowej (bfcache) oraz na stronach wstępnie renderowanych. Dlatego rozmiar próby TTFB może być mniejszy niż w przypadku innych danych i nie musi być z nimi bezpośrednio porównywany. TTFB w CrUX będzie obejmować wczytywanie strony na zimno, wczytywanie strony z pamięci podręcznej i wczytywanie strony z ustalonego połączenia (np. wczytywanie strony w witrynie).

TTFB nie jest bezpośrednim pomiarem czasu odpowiedzi serwera, ponieważ obejmuje też pomiary przed nim, w tym czas przekierowania, i może zależeć od tego, czy odpowiedź jest udostępniana z pamięci podręcznej, CDN czy serwera. Jest to szczególnie widoczne w danych rzeczywistych, 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ść

Dane pozycji wg popularności to względna miara popularności witryny w zbiorze danych CrUX, mierzona łączną liczbą nawigacji w źródle. Pozycja jest podawana w skali logarytmicznej o podstawie 10 z połówkami (np. 1 tys. najlepszych, 5 tys. najlepszych, 10 tys. najlepszych, 50 tys. najlepszych, 100 tys. najlepszych, 500 tys. najlepszych, 1 mln najlepszych itp.), przy czym każda pozycja wyklucza poprzednią (np. 5 tys. najlepszych to w rzeczywistości 4 tys. adresów URL, z wyłączeniem 1 tys. najlepszych). Górny limit jest dynamiczny, ponieważ zbiór danych się powiększa.

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

Zgoda na wyświetlanie powiadomień

W przypadku witryn, które proszą o zgodę na wyświetlanie użytkownikom powiadomień, te dane reprezentują względną częstotliwość odpowiedzi użytkowników na prośby: akceptuj, odrzuć, zignoruj lub odrzuć.

Dane reklamy

Chrome udostępnia publiczne dane i narzędzia, które pomagają witrynom i innym podmiotom, takim jak reklamodawcy, lepiej zrozumieć wrażenia użytkowników związane z reklamami i ich wpływ.

  • Liczba reklam: te dane opisują, ile reklam typowy użytkownik widzi jednocześnie w witrynie.
  • Gęstość reklam: te dane opisują równowagę między treścią a widocznością reklam u typowego użytkownika.
  • **Waga reklamy: procesor**: te dane opisują zużycie procesora przez reklamy, co może wpływać na wydajność.
  • **Waga reklamy: sieć**: te dane opisują zużycie zasobów sieciowych przez reklamy.

Spodziewamy się, że te dane będą szczególnie przydatne dla reklamodawców internetowych i usług, z których korzystają do umieszczania reklam. Od wielu zainteresowanych stron ekosystemu reklamowego dowiedzieliśmy się, że te dane mogą poprawić sposób, w jaki oceniają oni możliwości reklamowe i podejmują decyzje dotyczące produktów reklamowych.

Więcej informacji znajdziesz w poście na blogu dotyczącym wprowadzenia danych reklamy oraz w dokumentacji pomiarów skuteczności reklam.