Nikt nie lubi czekać. Ponad 50% użytkowników porzuca stronę, jeśli wczytuje się ona dłużej niż 3 sekundy.
Wysyłanie dużych ładunków JavaScriptu znacząco wpływa na szybkość witryny. Zamiast wysyłać cały kod JavaScript do użytkownika, gdy tylko zostanie załadowana pierwsza strona aplikacji, podziel pakiet na kilka części i wyślij tylko to, co jest potrzebne na samym początku.
Dlaczego dzielenie kodu jest korzystne?
Dzielenie kodu to technika, która ma na celu skrócenie czasu uruchamiania. Dzięki temu, że dostarczamy mniej kodu JavaScriptu podczas uruchamiania, aplikacje mogą szybciej reagować, ponieważ w tym kluczowym okresie minimalizujemy pracę głównego wątku.
Jeśli chodzi o podstawowe wskaźniki internetowe, zmniejszenie rozmiaru danych JavaScript pobieranych przy uruchamianiu aplikacji pozwoli skrócić czas interakcji do kolejnego wyrenderowania (INP). Dzieje się tak, ponieważ po uwolnieniu głównego wątku aplikacja jest w stanie szybciej reagować na dane wejściowe użytkownika, ograniczając koszty przetwarzania, kompilowania i uruchamiania kodu JavaScript.
W zależności od architektury witryny – zwłaszcza jeśli witryna w dużym stopniu opiera się na renderowaniu po stronie klienta – zmniejszenie ładunków JavaScript odpowiedzialnych za renderowanie znaczników może poprawić największe wyrenderowanie treści (LCP). Może się tak zdarzyć, gdy przeglądarka opóźni wczytanie zasobu LCP do momentu zakończenia znaczników po stronie klienta lub gdy wątek główny jest zbyt zajęty, aby renderować ten element LCP. W obu przypadkach czas LCP strony może się wydłużyć.
Zmierz odległość
Lighthouse wyświetla nieudany audyt, gdy wykonanie całego kodu JavaScript na stronie zajmuje dużo czasu.
Podziel pakiet JavaScript, aby wysyłać tylko kod potrzebny do początkowej ścieżki, gdy użytkownik wczytuje aplikację. Dzięki temu minimalizujesz ilość kodu, który musi zostać przeanalizowany i skompilowany, co powoduje szybsze wczytywanie strony.
Popularne narzędzia do tworzenia pakietów modułów, takie jak webpack, Parcel i Rollup, umożliwiają dzielenie pakietów za pomocą dynamicznych importów.
Weźmy na przykład ten fragment kodu, który przedstawia przykładową metodę someFunction uruchamianą przy przesyłaniu formularza.
import moduleA from "library";
form.addEventListener("submit", e => {
e.preventDefault();
someFunction();
});
const someFunction = () => {
// uses moduleA
}
Tutaj someFunction używa modułu zaimportowanego z konkretnej biblioteki. Jeśli ten moduł nie jest używany gdzie indziej, możesz zmodyfikować blok kodu, aby używać importu dynamicznego i pobierać moduł tylko wtedy, gdy użytkownik prześle formularz.
form.addEventListener("submit", e => {
e.preventDefault();
import('library.moduleA')
.then(module => module.default) // using the default export
.then(() => someFunction())
.catch(handleError());
});
const someFunction = () => {
// uses moduleA
}
Kod, który składa się na moduł, nie jest włączany do początkowego pakietu i jest teraz leniwie ładowany lub jest dostarczany użytkownikowi tylko wtedy, gdy jest potrzebny po przesłaniu formularza. Aby jeszcze bardziej poprawić wydajność strony, wczytaj wcześniej najważniejsze fragmenty, aby nadać im priorytet i pobrać je wcześniej.
Chociaż poprzedni fragment kodu jest prostym przykładem, leniwe ładowanie zależności zewnętrznych nie jest typowym wzorcem w większych aplikacjach. Zwykle zależności innych firm są dzielone na osobny pakiet dostawców, który można przechowywać w pamięci podręcznej, ponieważ są one rzadziej aktualizowane. Więcej informacji o tym, jak w tym pomóc może wtyczka SplitChunksPlugin, znajdziesz tutaj.
Dzielenie na poziomie trasy lub komponentu przy użyciu frameworku po stronie klienta to prostsze podejście do leniwego wczytywania różnych części aplikacji. Wiele popularnych frameworków korzystających z webpacka udostępnia abstrakcje, które ułatwiają opóźnione wczytywanie, ponieważ nie trzeba wtedy samodzielnie konfigurować.