Wymiar Core/Dash: Przeglądarka

Wymiar: Przeglądarka (browser)

Wymiar Przeglądarka 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ądarka izoluje ograniczenia oprogramowania, różnice w silnikach renderujących (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.

W przypadku 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 od Google, zaniedbując silniki SpiderMonkey (Firefox) i JavaScriptCore (Safari) używane przez 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. Użyj tego wymiaru, aby precyzyjnie wskazać awarie specyficzne dla danego silnika.

Interaction to Next Paint (INP)

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

• Firefox (SpiderMonkey): Firefox obsługuje priorytetyzację zadań inaczej niż Chrome. Ciężki detektor zdarzeń (event listener), który przechodzi w Chrome, może powodować zauważalne opóźnienie wejścia w przeglądarce Firefox z powodu różnic w sposobie, w jaki główny wątek wykonuje yielding.
• Safari (JavaScriptCore): często wykazuje odmienne zachowania dotyczące opóźnienia "tap" 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 odmienne 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 szybkie LCP, ale Firefox odstaje, zweryfikuj swoją strategię formatowania obrazów. Możesz serwować AVIF dla Chrome, jednocześnie stosując fallback do większych plików JPEG dla starszych wersji przeglądarek, którym brakuje wsparcia.
• Wskazówki priorytetów (Priority Hints): Chrome agresywnie respektuje atrybut fetchpriority="high". Przeglądarki, które ignorują ten atrybut, traktują zasób LCP ze standardowym priorytetem, sztucznie zawyżając opóźnienie ładowania (Load Delay).
• Protokoły połączeń: Edge i Firefox mogą inaczej negocjować połączenia HTTP/3 (QUIC) w środowiskach korporacyjnych lub ograniczonych sieciach, co wpływa na komponent TTFB metryki 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) nieco inaczej renderują linie bazowe czcionek (baselines) i odstępy (tracking). Jeśli nie dopasujesz idealnie metryk czcionki fallback, blok tekstu zmieni rozmiar po załadowaniu czcionki internetowej, powodując przesunięcie w jednej przeglądarce, ale nie w innej.
• Rezerwacja paska przewijania (Scrollbar Reservation): 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 programowania na komputerze Mac, ale zauważalne dla użytkowników systemu Windows.

Przepływ pracy (Workflow): Izolowanie regresji specyficznych dla silnika

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

• Zidentyfikuj wartość odstającą: Posortuj tabelę Przeglądarki 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 w porównaniu z Edge na Windowsie).
• Debuguj: Jeśli Edge działa wolno, a Chrome szybko (oba używają silnika Blink), zbadaj rozszerzenia innych firm lub oprogramowanie zabezpieczające przedsiębiorstwa popularne wśród użytkowników Edge, które wstrzykują skrypty do DOM. Jeśli Firefox działa wolno, przeprowadź audyt swojego CSS pod kątem niestandardowych właściwości lub zjawiska layout thrashing, które Gecko karze surowiej niż Blink.

Starsze wersje i wbudowane przeglądarki

Użyj wymiaru Przeglądarka, aby zidentyfikować obciążenia wydajności w "Długim ogonie" ("Long Tail").

Przeglądarki w aplikacjach (In-App Browsers): Ruch z Instagrama, LinkedIna lub Facebooka często odbywa się w ograniczonych widokach WebViews, które zachowują się inaczej niż natywna przeglądarka mobilna.

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