Profiluj ścieżkę klienta zanim zmienisz kod
Wybierz jedną ważną ścieżkę i interakcję, na przykład otwarcie nawigacji, filtrowanie wyników lub wysłanie formularza. Zarejestruj jej przebieg w panelu Performance Chrome DevTools, korzystając z czystego profilu przeglądarki. Powtórz działanie i wykonaj nagranie zarówno przy ograniczonej wydajności procesora, jak i na maszynie deweloperskiej; profil z komputera stacjonarnego może ukryć pracę uciążliwą na słabszym telefonie.
Użyj nagrania profilu do sprawdzenia wąskiej hipotezy, a nie do obwiniania komponentu na podstawie raportu pakietu JavaScript. Na wykresie płomieni Main szersze paski oznaczają dłuższy czas, a zagnieżdżone paski pokazują stos wywołań. Czerwony trójkąt przy elemencie „Task” wskazuje potencjalne długie zadanie; wybierz go i przejdź do łącza prowadzącego do kodu, który je zainicjował. Zachowuj nagrania sprzed i po istotnych zmianach.
Rozpocznij nagrywanie tuż przed akcją i zatrzymaj po widocznym wyniku.
Utrzymuj spójną trasę, stan konta i sekwencję akcji.
Przypisz każdy główny koszt do zespołu lub dostawcy, który może go zmienić.
Czytaj ślad jako kolejkę pracy
Długie zadanie jest progiem wymagającym analizy, a nie pełną diagnozą. Specyfikacja W3C Long Tasks raportuje zadania trwające co najmniej 50 milisekund. Sprawdź, czy pod zadaniem występuje wykonywanie JavaScriptu, procedura obsługi zdarzenia, ponowne obliczanie stylów, obliczanie układu strony czy malowanie. Stos wywołań wskazuje miejsce, od którego warto zacząć, a czasy pokazują, czy problem dotyczy kodu, renderowania czy ramki pochodzącej od zewnętrznego dostawcy.
Priorytetyzuj koszty, które powtarzają się podczas wartościowej interakcji. Krótki handler może dalej wydawać się wolny, gdy wywołuje layout lub stoi w kolejce za wcześniejszą pracą. Ślad to pomiar laboratoryjny, więc potwierdź poprawkę na reprezentatywnych urządzeniach i, gdzie dostępne, za pomocą telemetrii polowej z uwzględnieniem prywatności.
Parsowanie przy starcie potrzebuje innego rozwiązania niż handler po stuknięciu.
Znajdź powtarzające się wzorce zapisu stylu i odczytu layoutu przed refaktoryzacją.
Do zadania dołącz ślad, scenariusz i najwyższe koszty.
Dostarczaj mniej kodu wtedy, kiedy to ma znaczenie
Sporządź inwentaryzację skryptów według trasy i celu. Usuń nieużywane pakiety, duplikaty, wycofane eksperymenty i kod dla zakończonych funkcji. Następnie rozdziel funkcje specyficzne dla trasy lub rzadko używane, aby ładowały się w razie potrzeby zamiast na ścieżce początkowej. Dynamiczne ładowanie może zmniejszyć pracę przy starcie, ale może też spowodować widoczne opóźnienie, gdy użytkownik od razu potrzebuje funkcji.
Zastanów się, czy komponent potrzebuje pełnego frameworka po stronie klienta, czy narzędzie nie powiela istniejącej funkcjonalności oraz czy wystarczy statyczny HTML z niewielkim ulepszeniem. Przetestuj stan zastępczy opóźnionego modułu. Strona powinna poprawnie odroczyć opcjonalną funkcję, zamiast wyświetlać nieaktywny element sterujący.
Udokumentuj, jakie skrypty są dozwolone na trasie i dlaczego.
Rozważ to dla opcjonalnych edytorów, map, odtwarzaczy lub widoków raportowych.
Testuj uwierzytelnianie, dostępność, płatności i wypełnianie formularzy; uzyskaj kwalifikowaną recenzję, jeśli kontrolki są zmieniane.
Dzielenie pracy, aby przeglądarka mogła reagować
Samo nadanie nazw mniejszym funkcjom nie tworzy odrębnych zadań przeglądarki, jeśli uruchamiają się synchronicznie. Podziel pracę w długiej pętli na partie, zaktualizuj od razu stan widoczny dla użytkownika, a przed kontynuacją zwróć sterowanie przeglądarce. Pozwoli to przeglądarce obsłużyć interakcje i renderowanie między partiami.
Gdy jest dostępne, scheduler.yield() pozwala zwrócić sterowanie głównemu wątkowi i później wznowić pracę; sprawdzaj dostępność tej funkcji i przygotuj rozwiązanie zastępcze dla nieobsługiwanych przeglądarek. Nie ustępuj po każdej drobnej operacji: powoduje to narzut i może wydłużyć całkowity czas wykonania. Wyznaczaj granice na podstawie pomiarów, zachowaj możliwość anulowania i nie dopuść, aby przestarzałe wyniki zastąpiły nowszy stan.
Pokaż akceptację lub postęp przed niewidoczną pracą następczą.
Odstępuj zanim zmierzona praca stanie się długa, zamiast robić to raz na element.
Aktualne wskazówki web.dev nie rekomendują nowej strategii opartej na isInputPending().
Przenieś obliczenia, nie interfejs, do workera
Web Worker uruchamia skrypt w tle na wątku oddzielonym od głównego wątku wykonawczego. Nadaje się do kosztownego parsowania, transformacji danych, indeksowania wyszukiwania i innych obliczeń, które nie wymagają bezpośredniego dostępu do interfejsu. Wyślij zdefiniowane wejście, zwróć zdefiniowany wynik i trzymaj renderowanie oraz widoczne zmiany stanu na głównym wątku.
Workery nie są uniwersalne. Nie mogą bezpośrednio manipulować DOM ani używać Window, a komunikacja między wątkami kopiuje dane. Tworzenie workera, przenoszenie danych i koordynacja błędów mogą przewyższyć korzyść z małego obliczenia. Mierz pełną interakcję, zakończ niepotrzebne workery i zaprojektuj fallback na wypadek awarii pracy w workerze.
Zacznij od obliczenia, którego wejście i wyjście da się zserializować i przetestować.
Odrzuć wyniki utworzone dla starszego filtra, trasy lub akcji.
Przekazuj sensowny postęp przez normalny interfejs.
Zarządzaj JavaScriptem stron trzecich jak zależnością produkcyjną
Analityka, reklamy, eksperymenty, embedy społecznościowe, odtwarzacze wideo i widgety wsparcia mogą dodawać żądania, ewaluację JavaScriptu, iframe'y i zależności. Skrypt dostawcy może być niezbędny, ale leży poza bezpośrednią kontrolą zespołu aplikacyjnego i może wpływać na wydajność, prywatność, bezpieczeństwo oraz ciągłość. Sporządź inwentaryzację celu, tras, warunków ładowania, zatwierdzającego, wymogu zgody i właściciela usunięcia.
Gdy pozwalają na to warunki i umowy, porównaj reprezentatywną stronę z jedną domeną zewnętrzną oraz bez niej. Narzędzia wydajnościowe mogą ujawnić kosztowne wykonywanie kodu, rozmiary przesyłanych danych i przypisanie długich zadań. Zachowaj lekką lub opóźnioną integrację tylko wtedy, gdy jej udokumentowana wartość uzasadnia zmierzony koszt. Potwierdź, że podstawowa treść i główna transakcja działają, gdy opcjonalna zależność jest powolna lub niedostępna.
Ładuj tag tylko na trasach i warunkach, które go potrzebują.
Uwzględnij zmiany w tag-managerze w przeglądach wydajności, prywatności, bezpieczeństwa i wycofania.
Udokumentuj i przetestuj sposób wyłączenia integracji niekrytycznej.
Uczyń responsywność zabezpieczeniem przy wydaniach
Zamień zwycięski ślad w mały test regresji dla ważnej ścieżki. Zdefiniuj objęte interakcje, urządzenie lub ograniczenie CPU, oczekiwaną reakcję i recenzenta. Sparuj to z przeglądem bundla i inwentaryzacją stron trzecich, aby nowy pakiet lub tag nie wprowadził cicho pracy na głównym wątku.
Status Is UP wykorzystuje te dowody do proaktywnej optymalizacji i bezpiecznego usuwania problemów, a nie jako zamiennik monitorowania dostępności na żywo. Przed zmianą o wysokim ryzyku przygotuj plan wycofania i po wdrożeniu zweryfikuj krytyczny przepływ. Wyniki zależą od urządzenia, sieci, przeglądarki, treści i stanu konta; traktuj progi jako zabezpieczenia, a nie gwarancje.
Wymagaj śladów przed i po dla współdzielonej nawigacji, checkoutu, wyszukiwania lub dużych bundli.
Znaj funkcję flagi, ustawienie taga lub wersję wdrożenia, która przywraca znane-dobre zachowanie.
Re-profiluj po dużych wydaniach, zmianach dostawców lub przesunięciach miksu urządzeń.