Core/Dash Zrozumienie dashboardów podziału metryk

Zrozumienie dashboardu podziału metryk

Metryki złożone, takie jak LCP i INP, agregują wiele różnych zdarzeń czasowych. Optymalizacja wyniku wymaga wyizolowania tych składowych. Dashboard podziału metryk rozkłada wydajność na szczegółowe fazy, pozwalając zidentyfikować konkretne wąskie gardło.

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

Anatomia dashboardu podziału

Dashboard oferuje trzy zsynchronizowane widoki do izolowania przyczyny źródłowej opóźnień:

• Contribution Donut: Wizualizuje względny udział każdej części składowej. Odpowiada na pytanie: „Co ma największy wpływ?”. Jeśli `Time to First Byte` zajmuje 70% wykresu, problem leży po stronie backendu.
• Historical Timeline: Pokazuje trendy wartości bezwzględnych każdego komponentu w czasie. Użyj go, aby powiązać zmiany wydajności z konkretnymi zdarzeniami, np. wdrożeniami.
• Segmented Data Table: Rozbija metrykę według wymiarów (URL, urządzenie itp.). Każdy wiersz zawiera pasek rozkładu przedstawiający unikalny profil danego segmentu, co pomaga wyłapać wartości odstające.

Składowe LCP (Largest Contentful Paint)

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

• TTFB (Time to First Byte): Czas reakcji serwera. Wysoki TTFB wskazuje na wolne zapytania do bazy danych lub brak buforowania na brzegu sieci.
• Load Delay: Odstęp między początkową odpowiedzią HTML a rozpoczęciem pobierania zasobu LCP. Mierzy opóźnienie w wykrywaniu zasobu.
• Load Time: Czas potrzebny na pobranie zasobu LCP (obrazu lub czcionki) przez sieć. Koreluje z rozmiarem pliku i przepustowością łącza.
• Render Delay: Czas między zakończeniem pobierania zasobu a wyrenderowaniem go na ekranie. Wysoki Render Delay często oznacza blokowanie main threadu przez JavaScript.

Składowe TTFB (Time to First Byte)

TTFB służy jako wskaźnik szybkości reakcji serwera. Ten podział izoluje fazy połączenia sieciowego:

• Waiting: Czas, jaki przeglądarka spędza na oczekiwaniu na wygenerowanie odpowiedzi przez serwer (przetwarzanie po stronie backendu).
• Cache: Czas spędzony na sprawdzaniu lokalnej lub pośredniej pamięci podręcznej.
• DNS: Czas trwania wyszukiwania DNS.
• Connection: Czas potrzebny na nawiązanie połączenia TCP.
• Request: Czas potrzebny na wysłanie nagłówków żądania HTTP.

Składowe INP (Interaction to Next Paint)

INP mierzy interaktywność. Segmentujemy cykl życia interakcji, aby dokładnie zlokalizować blokowanie main threadu:

• Input Delay: Czas między interakcją użytkownika a wykonaniem kodu obsługi zdarzenia. Wysoki Input Delay oznacza, że main thread był zajęty.
• Processing: Czas potrzebny na wykonanie callbacków zdarzenia. Pokazuje to wydajność Twojej logiki JavaScript.
• Presentation: Czas potrzebny przeglądarce na obliczenie układu i wyrenderowanie kolejnej klatki.

Procedura diagnostyczna

Wykonaj poniższe kroki, aby zdiagnozować regresję:

• Oceń skalę wąskiego gardła: Spójrz na wykres Donut, aby znaleźć dominującą część. Jeśli `TTFB` jest wysoki, sprawdź swój serwer. Jeśli `Resource Load Delay` jest wysoki, sprawdź priorytety zasobów.
• Ustal związek przyczynowo-skutkowy: Sprawdź Timeline, aby powiązać nagły skok z konkretnym wdrożeniem lub aktualizacją treści.
• Wyizoluj kontekst: Użyj Data Table, aby sprawdzić, czy ten wzorzec powtarza się na wszystkich stronach, czy dotyczy konkretnego szablonu. Znalezienie wzorca to klucz do wdrożenia skalowalnej poprawki.

Optymalizacja Core Web Vitals

Użyj tych podziałów, aby kierować zgłoszenia do odpowiednich zespołów. Problemy z TTFB przypisz do backendu. Problemy z Load Delay i Render Delay przypisz do frontendu. Opóźnienia DNS/Connection przypisz do infrastruktury. Ten usprawniony proces triażu skraca czas diagnozy i przyspiesza rozwiązanie problemów.