Optymalizuj opóźnienie przy pierwszym działaniu

Jak szybciej reagować na interakcje użytkowników.

Addy Osmani
Addy Osmani
X GitHub
Houssein Djirdeh

Kliknąłem, ale nic się nie wydarzyło Dlaczego nie mogę wejść w interakcję z tą stroną? 😢

Pierwsze wyrenderowanie treści (FCP) i Największe wyrenderowanie treści Wyrenderowanie (LCP) to wskaźniki, które mierzą czas potrzebny do renderować (wyrenderować) na stronie. Chociaż czas renderowania jest ważny, nie rejestruje obciążenia responsywność, czyli jak szybko strona reaguje na interakcję użytkownika.

Opóźnienie przy pierwszym działaniu (FID) to podstawowe wskaźniki internetowe, które rejestrują to pierwsze wrażenie interaktywności i responsywności witryny. Mierzy czas od chwili, gdy użytkownik wchodzi w interakcję ze stroną do momentu, gdy przeglądarka jest w stanie rzeczywiście na nią zareagować. interakcji. FID to dane pole i nie można są symulowane w środowisku laboratoryjnym. Aby mierzyć czas oczekiwania na odpowiedź.

Prawidłowe wartości zaufania to 2,5 sekundy, słabe wartości powyżej 4,0 sekundy i inne wartości, które wymagają poprawy

Aby ułatwić prognozowanie FID w laboratorium, zalecamy całkowity czas blokowania (TBT). Mierzą one różne rzeczy, ale poprawa wyników w TBT zwykle przekłada się na poprawę wskaźnika FID.

Główną przyczyną niskiej wartości FID jest intensywne wykonywanie kodu JavaScript. Optymalizacja analizowania składni JavaScript, kompiluje i uruchamia na stronie internetowej, bezpośrednio zmniejsza FID.

Wykonywanie wielu czynności JavaScriptu

Przeglądarka nie może reagować na większość danych wejściowych użytkownika, gdy wykonuje kod JavaScript w wątku głównym. Innymi słowy, przeglądarka nie może odpowiadać na interakcje użytkowników, gdy wątek główny jest zajęty. Aby to poprawić:

Rozdziel długie zadania

Jeśli już próbowałeś(-aś) ograniczyć ilość kodu JavaScript ładowanego na jednej stronie, może on być przydatny do podzielenia długotrwałego kodu na mniejsze, asynchroniczne zadania.

Długie zadania to okresy wykonywania kodu JavaScript, w których użytkownicy mogą interfejs nie odpowiada. Każdy fragment kodu, który blokuje wątek główny na co najmniej 50 ms, jako „długie zadanie”. Długie zadania są oznaką potencjalne przeciążenie kodu JavaScript (wczytywanie i wykonywanie więcej niż być potrzebne użytkownikowi w tej chwili). Podział długich zadań może zmniejszyć opóźnienia danych wejściowych w witrynie.

Długie zadania w Narzędziach deweloperskich w Chrome
Narzędzia deweloperskie w Chrome wizualizują długie zadania w panelu wydajności

Wskaźnik FID powinien się znacznie poprawić w miarę stosowania sprawdzonych metod, takich jak podział kodu czy podział kodu Długie zadania. Chociaż TBT nie jest wskaźnikiem, przydaje się do sprawdzania postępu oraz poprawa czasu do interakcji (TTI) i FID.

Zoptymalizuj stronę pod kątem gotowości do interakcji

Istnieje wiele częstych przyczyn niskiego wyniku FID i TB w aplikacjach internetowych, które w dużym stopniu polegają na Kod JavaScript:

Wykonanie własnego skryptu może opóźnić gotowość do interakcji

  • Zbyt duży rozmiar kodu JavaScript, długie czasy wykonywania i nieefektywne dzielenie na fragmenty mogą spowolnić może reagować na dane wejściowe użytkownika i wpływać na FID, TBT oraz TTI. Stopniowe wczytywanie kodu funkcje pomagają rozkładać ten trening i zwiększać gotowość do interakcji.
  • Aplikacje renderowane po stronie serwera mogą wyglądać, jakby na ekranie były zamalowane piksele ale uważaj na to, że interakcje użytkowników mogą być blokowane przez wykonanie dużych skryptów (np. nawadnianie, aby połączyć detektory zdarzeń). Może to potrwać kilkaset milisekund, nawet sekund, jeśli używany jest podział kodu na podstawie trasy. Rozważ zmianę logiki po stronie serwera lub statycznie generuje więcej treści.

Poniżej znajdziesz wyniki do potwierdzenia przed i po zoptymalizowaniu wczytywania własnych skryptów w przypadku aplikacji. Przeniesienie wczytywania (i wykonania) kosztownego skryptu do mniej ważnego komponentu użytkownicy mogli wejść w interakcję ze stroną znacznie szybciej.

Poprawa wyniku TBT w Lighthouse po zoptymalizowaniu skryptu własnego.

Pobieranie danych może wpływać na wiele aspektów gotowości do interakcji

  • Oczekiwanie na kaskadę kaskadowych pobrań (np. JavaScript i pobrania danych dla komponentów) może wpływa na czas oczekiwania na interakcję. Staraj się zminimalizować zależność od kaskadowego pobierania danych.
  • Duże, wbudowane magazyny danych mogą wydłużyć czas analizy kodu HTML i wpływać zarówno na wyrenderowanie obrazu, jak i na interakcję. danych. Staraj się zminimalizować ilość danych, które muszą zostać przetworzone po stronie klienta.

Wykonanie skryptu innej firmy również może opóźnić interakcję

  • Wiele witryn zawiera tagi i analizy usług zewnętrznych, które mogą utrzymać obciążenie sieci powoduje, że wątek główny okresowo nie odpowiada, co wpływa na czas oczekiwania na interakcję. Odkrywaj świat ładowanie na żądanie kodu zewnętrznego (np. reklamy w części ekranu widocznej po przewinięciu mogą być wczytywane dopiero zostaną przewinięte bliżej widocznego obszaru).
  • W niektórych przypadkach skrypty innych firm mogą zastępować własne skrypty, jeśli chodzi o priorytety przepustowość w wątku głównym, opóźniając też to, jak szybko strona jest gotowa do interakcji. Próba W pierwszej kolejności ładuj to, co według Ciebie jest najbardziej wartościowe dla użytkowników.

Użyj instancji roboczej

Zablokowany wątek główny jest jedną z głównych przyczyn opóźnienia danych wejściowych. Sieć instancji roboczych umożliwiają uruchamianie JavaScriptu w wątku w tle. Przeniesienie operacji niezwiązanych z interfejsem do osobnego wątku instancji roboczej może spowodować obcięcie głównego wątku w krótszym czasie i w konsekwencji poprawić FID.

Rozważ użycie następujących bibliotek, aby ułatwić sobie używanie w witrynie instancji roboczych:

  • Comlink: biblioteka pomocnicza, która abstrakcyjna postMessage i ułatwia korzystanie
  • Workway: eksporter oprogramowania internetowego ogólnego przeznaczenia.
  • Workerize: przenieś moduł do instancji internetowej.

Skrócenie czasu wykonywania JavaScriptu

Ograniczenie ilości kodu JavaScript na stronie pozwala ograniczyć ilość czasu potrzebnego przeglądarce na na wykonanie kodu JavaScript. Dzięki temu przeglądarka będzie mogła szybciej reagować na interakcji użytkowników.

Aby ograniczyć ilość wykonywanego na Twojej stronie kodu JavaScript:

  • Odłóż nieużywany JavaScript
  • Minimalizuj nieużywane elementy polyfill

Odłóż nieużywany JavaScript

Domyślnie cały kod JavaScript blokuje renderowanie. Gdy przeglądarka napotka tag skryptu, który prowadzi do strony zewnętrznego pliku JavaScript, musi wstrzymać to, co robi, oraz pobrać, przeanalizować, skompilować i wykonać ten JavaScript. Dlatego należy wczytywać tylko kod wymagany do działania strony lub w odpowiedzi na dane wejściowe użytkownika.

Karta Zasięg w Chrome Narzędzia deweloperskie mogą określić, w jakim stopniu JavaScript nie jest używany na Twojej stronie internetowej.

Karta Zasięg

Aby ograniczyć nieużywany JavaScript:

  • Podziel pakiet na kilka fragmentów
  • Odłóż niekrytyczny JavaScript, w tym skrypty innych firm, za pomocą algorytmu async lub defer

Dzielenie kodu to koncepcja dzielenia jednego dużego pakietu JavaScript na mniejsze fragmenty. które można ładować warunkowo (tzw. leniwe ładowanie). Większość nowszych przeglądarek obsługuje składnię importu dynamicznego, który umożliwia pobieranie modułów na żądanie:

import('module.js').then((module) => {
  // Do something with the module.
});

dynamiczne importowanie kodu JavaScript przy określonych interakcjach użytkownika (takich jak zmiana trasy lub wyświetlając kod modalny) zapewnia, że kod, który nie został użyty do początkowego wczytywania strony, zostanie pobrany tylko wtedy, niezbędną.

Poza ogólną obsługą przeglądarek składnię importu dynamicznego można używać w wielu różnych kompilacji systemów uczących się.

  • Jeśli używasz pakietu webpack, Podsumowanie, lub Parcel jako pakietu modułów, skorzystaj z ich obsługi dynamicznego importu.
  • Strukturami po stronie klienta, Reaguj, Angular, Vue zapewnia abstrakcje, by ułatwić leniwe ładowanie na poziomie komponentów.

Poza podziałem kodu zawsze używaj asynchronicznych lub odroczenia w przypadku skryptów, które nie są niezbędne dla na ścieżce krytycznej lub w części strony widocznej na ekranie.

<script defer src="…"></script>
<script async src="…"></script>

Jeśli nie ma konkretnego powodu, żeby nie ładować wszystkich skryptów innych firm, należy użyć polecenia defer lub domyślnie async.

Minimalizuj nieużywane elementy polyfill

Jeśli tworzysz kod z wykorzystaniem nowoczesnej składni JavaScript i odwołasz się do interfejsów API nowoczesnych przeglądarek, muszą transpilować kod i dodać kod polyfill, aby działał w starszych przeglądarkach.

Jedną z głównych kwestii związanych z wydajnością w witrynie jest uwzględnianie elementów polyfill i transpilowanego kodu nowsze przeglądarki nie powinny być pobierane, jeśli nie są potrzebne. Aby skrócić JavaScript rozmiaru aplikacji, zminimalizuj jak najwięcej nieużywanych elementów polyfill i ogranicz ich wykorzystanie do w odpowiednich środowiskach.

Aby zoptymalizować wykorzystanie plików polyfill w witrynie:

  • Jeśli używasz Babel jako transpilatora, użyj @babel/preset-env, aby uwzględnić tylko kod polyfill wymaganych w przeglądarkach, na które chcesz kierować reklamy. W przypadku Babel 7.9 włącz bugfixes – opcja dalszego ograniczenia na niepotrzebnych elementach polyfill.

  • Użyj wzorca modułu/nomodule, aby przesłać 2 osobne pakiety (@babel/preset-env (obsługuje to przez target.esmodules)

    <script type="module" src="modern.js"></script>
<script nomodule src="legacy.js" defer></script>

    Wiele nowszych funkcji ECMAScript skompilowanych z użyciem Babel jest już obsługiwanych w środowiskach które obsługują moduły JavaScriptu. W ten sposób możesz uprościć proces uzyskiwania tylko kod po transpilacji jest używany przez przeglądarki, które go faktycznie potrzebują.

Narzędzia dla programistów

Dostępnych jest wiele narzędzi do mierzenia i debugowania FID:

Z podziękowaniem za opinie Philip Walton, Kayce Basques, Ilya Grigorik i Annie Sullivan.