Wymiar Core/Dash: Przeglądarka

Wymiar: Strona i Nawigacja: adresy URL (u)

Wymiar Przeglądarka grupuje dane o 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ądarka izoluje ograniczenia oprogramowania, różnice w silnikach renderujących (Blink, Gecko, WebKit) oraz kompatybilność skryptów third-party.

RUM vs. CrUX

Zrozumienie źródła danych jest kluczowe dla dokładnej analizy inżynierskiej.

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

Dla wielu stron internetowych przeglądarki inne niż Chrome stanowią 30-50% ruchu. Poleganie wyłącznie na CrUX tworzy martwy punkt: optymalizujesz pod kątem silnika V8 Google, zaniedbując silniki SpiderMonkey (Firefox) i JavaScriptCore (Safari), używane przez ogromną część Twoich odbiorców.

Diagnostyka specyficzna dla metryk

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

Interaction to Next Paint (INP)

Problemy z INP bezpośrednio korelują z wydajnością silnika JavaScript przeglądarki i harmonogramowaniem głównego wątku (main-thread).

• Firefox (SpiderMonkey): Firefox inaczej obsługuje priorytetyzację zadań niż Chrome. Ciężki event listener, który przechodzi w Chrome, może powodować zauważalne opóźnienie wejścia w Firefox ze względu na różnice w sposobie, w jaki główny wątek wykonuje yield.
• Safari (JavaScriptCore): często wykazuje odmienne zachowania dotyczące opóźnienia "tapnięcia" na urządzeniach mobilnych. Logika hydracji, która wydaje się natychmiastowa na Androidzie (Chrome), może wywoływać opóźnienia na iOS ze względu na odrębne modele propagacji zdarzeń.

Largest Contentful Paint (LCP)

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

• Negocjacja formatu: Jeśli Chrome raportuje szybki LCP, ale Firefox pozostaje w tyle, zweryfikuj strategię formatów obrazów. Możesz serwować AVIF dla Chrome, jednocześnie stosując fallback do większych plików JPEG dla starszych wersji przeglądarek bez wsparcia.
• Wskazówki dotyczące priorytetów: Chrome agresywnie respektuje fetchpriority="high". Przeglądarki ignorujące ten atrybut traktują zasób LCP ze standardowym priorytetem, sztucznie zawyżając Load Delay.
• Protokoły połączeń: Edge i Firefox mogą inaczej negocjować połączenia HTTP/3 (QUIC) w środowiskach korporacyjnych lub ograniczonych sieciach, wpływając na komponent TTFB metryki LCP.

Cumulative Layout Shift (CLS)

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

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

Workflow: Izolowanie regresji specyficznych dla silnika

Głównym przypadkiem użycia tego wymiaru jest "Walidacja Silnika".

• Zidentyfikuj element odstający: Posortuj tabelę Przeglądarka według Wpływu (Impact) lub Wolumenu. Szukaj konkretnej przeglądarki (np. Firefox Mobile), która ma znacznie gorszy wynik niż punkt odniesienia (Chrome Mobile).
• Zweryfikuj środowisko: Sprawdź, czy problem jest ściśle związany z przeglądarką, czy kombinacją przeglądarki i systemu operacyjnego (np. Edge na Androidzie vs. Edge na Windows).
• Debuguj: Jeśli Edge jest wolny, a Chrome szybki (oba używają Blink), zbadaj rozszerzenia third-party lub oprogramowanie zabezpieczające w firmach, powszechne u użytkowników Edge, które wstrzykują skrypty do DOM. Jeśli Firefox jest wolny, przeprowadź audyt CSS pod kątem niestandardowych właściwości lub layout thrashingu, które Gecko karze surowiej niż Blink.

Przeglądarki starszego typu i wbudowane

Użyj wymiaru Przeglądarka, aby zidentyfikować spadki wydajności typu "Long Tail".

Przeglądarki wewnątrz aplikacji: Ruch z Instagrama, LinkedIna lub Facebooka często odbywa się w ograniczonych WebView, które zachowują się inaczej niż natywna przeglądarka mobilna.

Starsze wersje: Możesz znaleźć ruch z przestarzałych wersji przeglądarek. Jeśli generują one wysoki INP, skonfiguruj narzędzia budowania (Babel/PostCSS), aby serwować niezbędne polyfille lub, jeśli wolumen jest znikomy, podejmij strategiczną decyzję o porzuceniu wsparcia, aby zmniejszyć rozmiar bundle dla nowoczesnych użytkowników.