Przeczytaj bieżący proces
Budżet wykonania jest granicą dla określonego doświadczenia użytkownika, a nie wynik wybrany, ponieważ wygląda imponująco. Rozpocząć od zadań i urządzeń, które mają znaczenie: otwarcie strony produktu na skromny telefon, filtrowanie listy roboczej lub złożenie wniosku. Zmierzyć ich obecne zachowanie przed wybraniem limitu i odnotować warunki badania wraz z wynikiem.
Granica warta utrzymania
Łączenie pomiarów doświadczenia z kosztami podlegającymi kontroli. Wczytywanie, reagowanie na interakcje i stabilność układu opisują to, co osoba napotyka; skrypt, obraz i rozmiary transmisji czcionki pomagają wyjaśnić dlaczego. web.dev opisuje budżety jako ograniczenia, które kierują decyzjami o wynikach. Utrzymać budżet dołączony do strony lub zadania, z właścicielem i odpowiedź, gdy jest przekroczona. Próg bez działania jest tylko liczbą.
Wykonaj jedno prawdziwe zadanie
Załóżmy, że strona usługi publicznej dodaje interaktywne porównanie. Zmierzyć stronę produkcji przed i po zmianie w tych samych warunkach urządzenia i połączenia. Sprawdź przeniesiony kod i czy główne wyjaśnienie pojawia się natychmiast. Jeżeli interakcja powoduje opóźnienie bez pomocy w podejmowaniu decyzji, należy ją uprościć lub załadować tylko w razie potrzeby. Jeśli jest to niezbędne, należy rozważyć usunięcie mniej użytecznych kosztów gdzie indziej, a nie ukrywanie regresji.
Ochrona wyjątków
Nie porównuj ciepłego pulpitu do zimnej mobilnej lub raportuj jeden najlepszy wynik jako typowy. Oddzielne kontrole laboratoryjne z obserwacji prawdziwych odwiedzających; odpowiadają na różne pytania. Dołącz niepowodzenia, długą zawartość, przetłumaczone czcionki i skrypty stron trzecich. Budżet nie powinien wymuszać niedostępnych, małych tekstów, brakujących funkcjonalności ani pomiarów, które wykluczają najtrudniejszą trasę.
Przekształcić budżet w powtarzalną decyzję o wydaniu
Wybierz mały reprezentatywny zestaw tras, w tym najcięższą stronę użyteczną, a nie tylko stronę główną. Zapis produkcji, profil urządzenia, warunki połączenia, stan pamięci podręcznej i mierzone zadanie. Utrzymać wynik odniesienia przy tych warunkach. Kiedy późniejsza zmiana wykonuje się inaczej, zespół musi odróżnić zmianę produktu od zmiany konfiguracji testu przed podjęciem decyzji, czy zwolnienie powinno być kontynuowane.
Przypisz powód do każdego budżetu. Ograniczenie początkowego transferu skryptu może chronić powolne połączenie; ograniczenie opóźnienia interakcji może chronić powtarzające się prace filtrujące. Są to powiązane, ale różne obawy. Jeżeli pomiar nie powiedzie się, należy sprawdzić dane zadanie i jego podział kosztów. Duże skrypty, przerośnięte obrazy, późne czcionki i powolne żądania danych wymagają różnych środków zaradczych. Usunięcie użytecznej funkcjonalności jedynie w celu poprawienia jednego zagregowanego wyniku może spowodować pogorszenie produktu, więc ocena rzeczywistych konsekwencji użytkownika obok wyniku technicznego.
Wyrażcie wyjątki. Załóżmy, że wymagana wizualizacja danych dodaje pracę do strony specjalistycznej. Należy udokumentować potrzebę, zmierzony efekt, rozważane alternatywy i osobę akceptującą transakcję. Zachowaj wyjątek na tej trasie, zamiast cichego rozluźniania budżetu każdej strony. Wybierz punkt przeglądu, szczególnie jeśli zespół zamierza zastąpić tymczasową zależność. Po wydaniu porównaj oczekiwania laboratoryjne z dostępnymi obserwacjami ponownego użycia i badaj różnice zamiast traktować jeden test jako gwarancję uniwersalną. Jeżeli pomiar ponownego użycia nie jest dostępny, powiedz to i zachowaj węższy wniosek: trasy te zostały sprawdzone w tych warunkach. Jest to nadal użyteczny dowód, pod warunkiem że jego limity pozostaną widoczne.
Zestawienie robocze dotyczące przeglądu budżetu
| Pytanie | Wymagane dowody |
|---|---|
| Co stało się wolniejsze? | Identyfikacja trasy i zadania, z porównywalną przed i po biegach, a nie niepowiązane wyniki. |
| Jakie koszty się zmieniły? | Pokaż odpowiedni wkład transferu, renderowania lub zależności; unikaj zgadywania z ogólnego wyniku strony. |
| Czy dodatkowy koszt jest uzasadniony? | Określić korzyści dla użytkowników i tańsze alternatywy, które zostały faktycznie uwzględnione lub wypróbowane. |
| Jak skończy się ten wyjątek? | Nazwa właściciela, dotknięta trasą i wywołanie przeglądu, tak aby tymczasowy kompromis nie stał się niezbadanym niewykonaniem. |
Przed podjęciem decyzji
Które zadanie użytkownika jest wolniejsze, gdy ten limit jest przekroczony? Czy zespół może odtworzyć pomiar? Kto akceptuje uzasadniony wyjątek i kiedy jest on poddawany przeglądowi? Przynieść reprezentatywną trasę i profil urządzenia do oceny aplikacji web-, a następnie użyć małej powtarzalnej kontroli w procesie wydania.
Źródła i dalsza lektura
Aplikacje webowe
Przejrzysta przestrzeń do wykonywania złożonej pracy.
Porozmawiaj o tej usłudze