Core/Dash Zrozumienie paneli Metric Breakdown

Zrozumienie panelu Metric Breakdown

Złożone metryki, takie jak LCP i INP, agregują wiele odrębnych zdarzeń czasowych. Optymalizacja całkowitego wyniku wymaga wyizolowania tych składowych. Panel Metric Breakdown rozkłada wydajność na granularne fazy, aby zidentyfikować konkretne wąskie gardło.

To narzędzie zastępuje ogólną optymalizację precyzyjnymi celami inżynieryjnymi. Przypisuje ono opóźnienia do serwera, sieci lub wykonania po stronie klienta.

Anatomia panelu Breakdown

Panel zapewnia trzy zsynchronizowane widoki, aby wyizolować przyczynę źródłową opóźnień:

• Contribution Donut: Wizualizuje względną wagę każdej podczęści. Odpowiada na pytanie: „Co jest największym czynnikiem?”. Jeśli `Time to First Byte` zajmuje 70% wykresu, wiesz, że problem jest związany z backendem.
• Historical Timeline: Przedstawia trendy wartości bezwzględnych każdego komponentu w czasie. Użyj tego, aby skorelować zmiany wydajności z konkretnymi zdarzeniami, takimi jak wdrożenia.
• Segmented Data Table: Rozbija metrykę według wymiaru (URL, urządzenie itp.). Każdy wiersz zawiera pasek rozkładu, który ujawnia unikalny profil tego segmentu, pomagając w wykrywaniu wartości odstających.

Komponenty LCP (Largest Contentful Paint)

LCP mierzy wydajność ładowania. Dzielimy tę metrykę na cztery fazy:

• TTFB (Time to First Byte): Czas odpowiedzi serwera. Wysokie TTFB wskazuje na wolne zapytania do bazy danych lub brak cache'owania na brzegu sieci (edge caching).
• Load Delay: Odstęp między początkową odpowiedzią HTML a rozpoczęciem pobierania zasobu LCP. Mierzy to opóźnienie wykrywania zasobów.
• Load Time: Czas wymagany do pobrania zasobu LCP (obrazu lub czcionki) przez sieć. Koreluje to z rozmiarem pliku i przepustowością.
• Render Delay: Czas między zakończeniem pobierania zasobu a namalowaniem go na ekranie. Wysokie Render Delay często wskazuje na blokowanie głównego wątku przez JavaScript.

Komponenty TTFB (Time to First Byte)

TTFB służy jako wskaźnik responsywności serwera. To rozbicie izoluje fazy połączenia sieciowego:

• Waiting: Czas, jaki przeglądarka spędza, czekając na wygenerowanie odpowiedzi przez serwer (przetwarzanie backendowe).
• Cache: Czas spędzony na sprawdzaniu lokalnych lub pośrednich pamięci podręcznych.
• DNS: Czas trwania wyszukiwania w systemie nazw domen (Domain Name System).
• Connection: Czas potrzebny na nawiązanie połączenia TCP.
• Request: Czas potrzebny na wysłanie nagłówków żądania HTTP.

Komponenty INP (Interaction to Next Paint)

INP mierzy interaktywność. Segmentujemy cykl życia interakcji, aby wskazać blokowanie głównego wątku:

• Input Delay: Czas między interakcją użytkownika a wykonaniem procedury obsługi zdarzenia. Wysokie Input Delay oznacza, że główny wątek był zajęty.
• Processing: Czas potrzebny na wykonanie callbacków zdarzeń. Reprezentuje to wydajność twojej logiki JavaScript.
• Presentation: Czas potrzebny przeglądarce na obliczenie układu (layout) i namalowanie następnej klatki.

Procedura diagnostyczna

Postępuj zgodnie z tą sekwencją, aby zdiagnozować regresję:

• Ilościowe określenie wąskiego gardła: Spójrz na wykres pierścieniowy (Donut chart), aby znaleźć dominującą podczęść. Jeśli `TTFB` jest wysokie, sprawdź swój serwer. Jeśli `Resource Load Delay` jest wysokie, sprawdź priorytety zasobów.
• Ustalenie przyczynowości: Sprawdź oś czasu (Timeline), aby skorelować skok z konkretnym wdrożeniem lub aktualizacją treści.
• Wyizolowanie kontekstu: Użyj tabeli danych (Data Table), aby sprawdzić, czy ten wzorzec sprawdza się na wszystkich stronach, czy jest specyficzny dla określonego szablonu. Znalezienie wzorca jest kluczem do wdrożenia skalowalnej poprawki.

Optymalizacja Core Web Vitals

Wykorzystaj te rozbicia, aby kierować zgłoszenia do odpowiedniego zespołu inżynierskiego. Przypisz problemy z TTFB do Backendu. Przypisz Load Delay i Render Delay do Frontendu. Przypisz opóźnienia DNS/Connection do Infrastruktury. Ten usprawniony proces segregacji (triage) skraca czas dochodzenia i przyspiesza rozwiązanie problemu.