Przedstawiliśmy Microsoft Clarity jako produkt stworzony z myślą o praktycznych, rzeczywistych zastosowaniach przez prawdziwych specjalistów, którzy rozumieją wyzwania stojące przed firmami takimi jak Switas. Funkcje takie jak wykrywanie kliknięć i śledzenie błędów JavaScript okazały się nieocenione w identyfikowaniu frustracji użytkowników i problemów technicznych, umożliwiając wprowadzenie ukierunkowanych usprawnień, które bezpośrednio wpłynęły na doświadczenia użytkowników i wskaźniki konwersji.
Całkowity czas blokowania
Całkowity czas blokowania (TTC) mierzy skumulowany czas, przez jaki główny wątek przeglądarki był blokowany przez długie zadania podczas ładowania strony, uniemożliwiając jej reakcję na dane wprowadzane przez użytkownika. Sumuje on część każdego zadania przekraczającą pięćdziesiąt milisekund, zliczając tylko nadmiar. Jest mierzony w warunkach laboratoryjnych między pierwszym renderowaniem zawartości a momentem, w którym strona staje się niezawodnie interaktywna.
Jego celem jest służenie jako laboratoryjny odpowiednik responsywności, którą trudno zmierzyć bez rzeczywistej interakcji użytkownika. Ponieważ interakcja z następnym malowaniem wymaga rzeczywistego działania użytkownika, nie można jej uchwycić w teście syntetycznym, w którym nikt nie klika. Całkowity czas blokowania (TTC) przybliża ten sam podstawowy problem, mierząc, przez jaki czas ładowania przeglądarka nie byłaby w stanie zareagować, i koreluje na tyle dobrze, że jest przydatny w diagnozie.
Próg pięćdziesięciu milisekund odzwierciedla ludzką percepcję, a nie arbitralny wybór. Zadania trwające krócej pozwalają przeglądarce reagować na dane wejściowe na tyle szybko, że interfejs wydaje się natychmiastowy, podczas gdy zadania trwające dłużej powodują zauważalne opóźnienie. Licząc tylko czas przekraczający próg, oznacza to, że pojedyncze zadanie trwające pięćset milisekund wnosi znacznie więcej niż dziesięć zadań trwających sześćdziesiąt, co słusznie odzwierciedla fakt, że jeden długi blok jest gorszy niż kilka krótkich.
Przyczynami są niemal wyłącznie wykonywanie kodu JavaScript. Duże pakiety, które wymagają parsowania i kompilowania, inicjalizacja i hydratacja frameworka na stronach renderowanych na serwerze, skrypty innych firm wykonywane podczas ładowania oraz kosztowne obliczenia wykonywane synchronicznie – wszystkie te procesy zajmują wątek główny. Ulepszenia sieciowe nie rozwiązują tego problemu: skrypt pobierany natychmiast nadal blokuje wątek podczas wykonywania.
Naprawa polega na zidentyfikowaniu zadań, które są długie i co zawierają. Standardowymi metodami są: dzielenie pakietów tak, aby natychmiast ładował się tylko kod potrzebny do początkowego widoku, odkładanie wykonywania niekrytycznych skryptów, dzielenie długich zadań na mniejsze części, które następnie są przekazywane przeglądarce, przenoszenie dużych obliczeń do wątku roboczego oraz usuwanie skryptów zewnętrznych, których koszt nie jest uzasadniony. Indywidualny audyt zewnętrznych skryptów jest często krokiem przynoszącym największe korzyści, ponieważ pojedynczy kontener menedżera tagów może zdominować pomiar.
Jego związek z danymi terenowymi wymaga starannej interpretacji. Całkowity czas blokowania (CTC) to pomiar laboratoryjny w kontrolowanych warunkach, natomiast interakcja z następnym malowaniem (Interaction to Next Paint) jest zbierana od rzeczywistych użytkowników na rzeczywistych urządzeniach. Strona może rejestrować akceptowalny czas blokowania na szybkim komputerze testowym i słabą reakcję w terenie na telefonach średniej klasy, z których korzysta znaczna część odbiorców. Testowanie w warunkach ograniczonej przepustowości, przybliżających rzeczywisty rozkład urządzeń, sprawia, że dane laboratoryjne są predykcyjne.
Obejmuje on również jedynie okres ładowania, co stanowi realne ograniczenie. Problemy z responsywnością, pojawiające się później, gdy użytkownik filtruje dużą listę lub otwiera złożony widok, są niewidoczne dla pomiaru, który zatrzymuje się po zakończeniu ładowania. Aplikacje o znacznej interaktywności po załadowaniu wymagają pomiaru rzeczywistych interakcji w terenie, a nie polegania na proxy w czasie ładowania.
Ponieważ rozwiązania dotyczą kodu aplikacji i zależności od stron trzecich, a nie dostarczania zasobów, udoskonalenie wymaga inżynierii, a nie konfiguracji. W praktyce diagnoza leży w… wydajność sieci praca, pakiet i zmiany wykonania są dostarczane za pośrednictwem rozwój produktów, a decyzje dotyczące tego, które skrypty innych firm uzasadniają koszt głównego wątku, zwykle wymagają zaangażowania usługi marketingowe, ponieważ większość takich skryptów jest dostępna na ich prośbę.
Świtas widziany na
