Wymiar Core/Dash: Przeglądarka

Wymiar: Przeglądarka (browser)

Wymiar przeglądarki grupuje dane dotyczące wydajności na podstawie ciągu User Agent wysyłanego przez klienta. Pozwala to na audyt wydajności Core Web Vitals przez pryzmat konkretnego oprogramowania renderującego Twoją aplikację (np. Chrome, Firefox, Safari, Edge, Samsung Internet).

Wymiar przeglądarki izoluje ograniczenia oprogramowania, różnice między silnikami renderującymi (Blink, Gecko, WebKit) oraz kompatybilność skryptów stron trzecich.

RUM vs. CrUX

Zrozumienie źródła danych jest ważne dla dokładnej analizy inżynieryjnej.

• CrUX (Chrome User Experience Report): Ten zbiór danych gromadzi dane wyłącznie od użytkowników Chrome (i niektórych pochodnych Chromium), którzy wyrazili na to zgodę. Ślepo wyklucza ruch z Firefoksa (silnik Gecko) i Safari (silnik WebKit).
• CoreDash RUM: Gromadzi dane z każdej przeglądarki, która wykonuje fragment kodu JavaScript.

Dla wielu witryn przeglądarki inne niż Chrome stanowią 30-50% ruchu. Poleganie wyłącznie na CrUX tworzy martwy punkt: optymalizujesz pod kątem silnika V8 od Google, zaniedbując silniki SpiderMonkey (Firefox) i JavaScriptCore (Safari), których używa ogromny segment Twoich odbiorców.

Diagnostyka specyficzna dla metryk

Różne silniki przeglądarek inaczej zarządzają zasobami, kompilują JavaScript i obliczają geometrię układu (layout). Użyj tego wymiaru, aby wskazać błędy specyficzne dla danego silnika.

Interaction to Next Paint (INP)

Problemy z INP bezpośrednio korelują z wydajnością silnika JavaScript przeglądarki i planowaniem głównego wątku.

• Firefox (SpiderMonkey): Firefox traktuje priorytetyzację zadań inaczej niż Chrome. Ciężki detektor zdarzeń, który przechodzi w Chrome, może powodować zauważalne opóźnienia wejścia w przeglądarce Firefox ze względu na różnice w sposobie, w jaki główny wątek wykonuje yield.
• Safari (JavaScriptCore): często wykazuje odmienne zachowania w zakresie opóźnień "tapnięcia" na urządzeniach mobilnych. Logika hydratacji, która wydaje się natychmiastowa na systemie Android (Chrome), może wywoływać opóźnienia na iOS ze względu na odmienne modele propagacji zdarzeń.

Largest Contentful Paint (LCP)

Rozbieżności LCP zazwyczaj sygnalizują brak zgodności funkcji lub wsparcia dla nowoczesnych API optymalizacyjnych.

• Negocjacja formatu: Jeśli Chrome zgłasza szybki LCP, ale Firefox odstaje, zweryfikuj swoją strategię doboru formatu obrazu. Możliwe, że serwujesz AVIF dla Chrome, stosując fallback do większych plików JPEG dla starszych wersji przeglądarek pozbawionych wsparcia.
• Priority Hints: Chrome agresywnie respektuje fetchpriority="high". Przeglądarki, które ignorują ten atrybut, traktują zasób LCP ze standardowym priorytetem, sztucznie zawyżając Load Delay.
• Protokoły połączeń: Edge i Firefox mogą negocjować połączenia HTTP/3 (QUIC) inaczej w środowiskach korporacyjnych lub ograniczonych sieciach, wpływając na komponent TTFB dla LCP.

Cumulative Layout Shift (CLS)

Silniki renderujące obliczają geometrię pikseli przy użyciu odmiennej logiki subpikselowej.

• Renderowanie czcionek (Gecko vs. Blink): Firefox (Gecko) i Chrome (Blink) renderują linie bazowe czcionek oraz tracking nieznacznie inaczej. Jeśli nie dopasujesz idealnie metryk swojego fontu typu fallback, blok tekstu zmieni rozmiar po załadowaniu fontu webowego, powodując przesunięcie w jednej przeglądarce, ale nie w innej.
• Rezerwacja paska przewijania: Przeglądarki w systemie Windows (Edge/Firefox/Chrome) rezerwują fizyczną przestrzeń na paski przewijania, podczas gdy przeglądarki w systemie macOS nakładają je na treść. Ta dysproporcja często powoduje przesunięcia układu oparte na szerokości, które są niewidoczne podczas tworzenia aplikacji na komputerach Mac, ale wyraźne dla użytkowników Windows.

Przepływ pracy: Izolowanie regresji specyficznych dla silnika

Głównym przypadkiem użycia tego wymiaru jest "Weryfikacja silnika".

• Zidentyfikuj wartości odstające: Posortuj tabelę przeglądarek według Wpływu (Impact) lub Wolumenu (Volume). Poszukaj określonej przeglądarki (np. Firefox Mobile), która ma znacznie gorszy wynik niż wartość bazowa (Chrome Mobile).
• Zweryfikuj środowisko: Sprawdź, czy problem jest ściśle związany z przeglądarką, czy z kombinacją przeglądarki i systemu operacyjnego (np. Edge na Androidzie vs. Edge na Windowsie).
• Debugowanie: Jeśli Edge jest wolny, ale Chrome szybki (oba używają Blink), zbadaj rozszerzenia stron trzecich lub oprogramowanie zabezpieczające w firmie powszechne u użytkowników Edge, które wstrzykują skrypty do DOM.Jeśli Firefox jest wolny, przeprowadź audyt swojego CSS pod kątem niestandardowych właściwości lub zjawiska layout thrashing, które Gecko karze surowiej niż Blink.

Przeglądarki starszego typu i wbudowane

Użyj wymiaru przeglądarki, aby zidentyfikować obciążenia wydajności "długiego ogona" (Long Tail).

Przeglądarki w aplikacjach (In-App): Ruch z Instagrama, LinkedIn lub Facebooka często działa w ograniczonych widokach WebView, które zachowują się inaczej niż natywna przeglądarka mobilna.

Starsze wersje (Legacy): Możesz napotkać ruch z nieaktualnych wersji przeglądarek. Jeśli generują one wysoki INP, skonfiguruj swoje narzędzia do budowania (Babel/PostCSS), aby serwowały niezbędne polyfille, lub, jeśli wolumen jest znikomy, podejmij strategiczną decyzję o porzuceniu wsparcia w celu zmniejszenia rozmiaru pakietu dla współczesnych użytkowników.