Nikt nie lubi czekać. Ponad 50% użytkowników opuszcza witrynę, jeśli jej wczytywanie trwa dłużej niż 3 sekundy.
Wysyłanie dużych pakietów JavaScriptu ma znaczący wpływ na szybkość witryny. Zamiast wysyłać do użytkownika cały kod JavaScript od razu po wczytaniu pierwszej strony aplikacji, podziel pakiet na kilka części i na początku wyślij tylko to, co jest niezbędne.
Dlaczego dzielenie kodu jest korzystne?
Dzielenie kodu to technika, która ma na celu zminimalizowanie czasu uruchamiania. Jeśli na początku wysyłamy mniej JavaScriptu, możemy sprawić, że aplikacje będą szybciej interaktywne, minimalizując pracę wątku głównego w tym krytycznym okresie.
Jeśli chodzi o Core Web Vitals, zmniejszenie rozmiaru plików JavaScript pobieranych podczas uruchamiania przyczyni się do skrócenia czasu interakcji do kolejnego wyrenderowania (INP). Dzięki temu, że wątek główny jest wolny, aplikacja może szybciej reagować na dane wejściowe użytkownika, ponieważ zmniejszają się koszty uruchamiania związane z parsowaniem, kompilowaniem i wykonywaniem kodu JavaScript.
W zależności od architektury witryny – zwłaszcza jeśli w dużym stopniu opiera się ona na renderowaniu po stronie klienta – zmniejszenie rozmiaru pakietów JavaScript odpowiedzialnych za renderowanie znaczników może skrócić czas największego wyrenderowania treści (LCP). Może się to zdarzyć, gdy zasób LCP jest odkrywany przez przeglądarkę z opóźnieniem, dopiero po zakończeniu renderowania po stronie klienta, lub gdy wątek główny jest zbyt zajęty, aby wyrenderować ten element LCP. Oba te scenariusze mogą opóźnić czas LCP na stronie.
Pomiary
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 trasy, gdy użytkownik wczytuje aplikację. Minimalizuje to ilość skryptu, który musi zostać przeanalizowany i skompilowany, co przyspiesza wczytywanie strony.
Popularne usługi tworzące pakiety modułów, takie jak webpack, Parcel i Rollup, umożliwiają dzielenie pakietów za pomocą importów dynamicznych.
Rozważmy na przykład ten fragment kodu, który pokazuje przykład metody someFunction, która jest wywoływana po przesłaniu formularza.
import moduleA from "library";
form.addEventListener("submit", e => {
e.preventDefault();
someFunction();
});
const someFunction = () => {
// uses moduleA
}
W tym przypadku someFunction używa modułu zaimportowanego z określonej biblioteki. Jeśli ten moduł nie jest używany w innych miejscach, blok kodu można zmodyfikować tak, aby używał importu dynamicznego i pobierał go 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, z którego składa się moduł, nie jest uwzględniany w początkowym pakiecie i jest teraz ładowany z opóźnieniem lub udostępniany użytkownikowi dopiero wtedy, gdy jest potrzebny po przesłaniu formularza. Aby jeszcze bardziej poprawić wydajność strony, wstępnie wczytaj najważniejsze fragmenty, aby nadać im priorytet i szybciej je pobrać.
Chociaż powyższy fragment kodu jest prostym przykładem, leniwe ładowanie zależności zewnętrznych nie jest powszechnym wzorcem w większych aplikacjach. Zależności od innych firm są zwykle dzielone na osobny pakiet dostawcy, który można buforować, ponieważ nie jest on tak często aktualizowany. Więcej informacji o tym, jak może Ci w tym pomóc SplitChunksPlugin, znajdziesz w tym artykule.
Podział na poziomie trasy lub komponentu w przypadku korzystania z frameworka po stronie klienta to prostsze podejście do leniwego wczytywania różnych części aplikacji. Wiele popularnych platform korzystających z webpacka udostępnia abstrakcje, które ułatwiają leniwe ładowanie, dzięki czemu nie musisz samodzielnie zagłębiać się w konfiguracje.