Nie ma szybszego sposobu na spowolnienie strony internetowej (zamierzona gra słów) niż użycie na niej kilku kodów JavaScript. Korzystając z JavaScriptu, trzeba za to zapłacić wykonaniem projektów nie mniej niż czterokrotnie. Oto jak kod JavaScript witryny ładuje systemy użytkowników:
- Pobieranie pliku przez sieć.
- Analiza i kompilacja rozpakowanego kodu źródłowego po pobraniu.
- Wykonanie kodu JavaScript.
- Zużycie pamięci.
Ta kombinacja się sprawdza .
A do naszych projektów dołączamy coraz więcej kodu JS. W miarę jak organizacje przechodzą na witryny oparte na frameworkach i bibliotekach, takich jak React, Vue i inne, uzależniamy podstawową funkcjonalność witryn od JavaScript.
Widziałem wiele bardzo ciężkich witryn korzystających z frameworków JavaScript. Ale moja wizja problemu jest bardzo stronnicza. Faktem jest, że firmy, z którymi współpracuję, zwracają się do mnie właśnie dlatego, że borykają się ze złożonymi problemami w zakresie wydajności witryny. W rezultacie zaciekawiło mnie, jak powszechny jest ten problem i jakie „kary” płacimy, wybierając taki lub inny framework jako podstawę dla określonej witryny.
Projekt pomógł mi to zrozumieć. .
Te
Projekt HTTP Archive śledzi łącznie 4308655 5484239 XNUMX linków do zwykłych witryn na komputery i XNUMX XNUMX XNUMX linków do witryn mobilnych. Wśród wielu wskaźników powiązanych z tymi linkami znajduje się lista technologii znalezionych na odpowiednich stronach. Oznacza to, że możemy wypróbować tysiące witryn korzystających z różnych frameworków i bibliotek oraz dowiedzieć się, ile kodu wysyłają do klientów i jakie obciążenie powoduje ten kod w systemach użytkowników.
Zebrałem dane z marca 2020 r., czyli najnowsze dane, do których miałem dostęp.
Zdecydowałem się porównać zagregowane dane archiwum HTTP we wszystkich witrynach z danymi z witryn znalezionych za pomocą React, Vue i Angular, chociaż rozważałem również użycie innych materiałów źródłowych.
Aby było ciekawiej, do źródłowego zbioru danych dodałem również strony korzystające z jQuery. Ta biblioteka jest nadal bardzo popularna. Wprowadza również inne podejście do tworzenia stron internetowych niż model Single Page Application (SPA) oferowany przez React, Vue i Angular.
Łącza w archiwum HTTP reprezentujące witryny, w przypadku których wykryto, że korzystają z interesujących technologii
Framework lub biblioteka
Linki do stron mobilnych
Linki do zwykłych stron
jQuery
4615474
3714643
React
489827
241023
Vue
85649
43691
Angular
19423
18088
Nadzieje i marzenia
Zanim przejdziemy do analizy danych, chcę porozmawiać o tym, na co chciałbym mieć nadzieję.
Wierzę, że w idealnym świecie frameworki powinny wykraczać poza zaspokajanie potrzeb programistów i zapewniać określone korzyści przeciętnemu użytkownikowi pracującemu z naszymi witrynami. Wydajność to tylko jedna z tych zalet. Tutaj liczy się dostępność i bezpieczeństwo. Ale to tylko najważniejsze.
Tak więc w idealnym świecie jakiś framework powinien ułatwiać tworzenie witryny o wysokiej wydajności. Należy to zrobić albo dlatego, że framework daje programiście przyzwoitą bazę do zbudowania projektu, albo dlatego, że nakłada ograniczenia na rozwój, stawia mu wymagania, które komplikują rozwój czegoś, co obraca być powolny.
Najlepsze frameworki powinny dawać jedno i drugie: dawać dobrą bazę i nakładać ograniczenia na pracę, pozwalając na osiągnięcie przyzwoitego wyniku.
Analiza wartości median danych nie da nam potrzebnych informacji. I faktycznie, takie podejście pomija naszą uwagę . Zamiast tego wyprowadziłem wartości procentowe z danych, które posiadałem. Są to 10, 25, 50 (mediana), 75, 90 percentyli.
Szczególnie interesują mnie 10. i 90. percentyl. 10. percentyl reprezentuje najlepsze wyniki (lub przynajmniej mniej więcej zbliżone do najlepszych) dla określonej struktury. Innymi słowy, oznacza to, że tylko 10% witryn korzystających z określonego frameworka osiąga ten lub wyższy poziom. Z drugiej strony 90. percentyl to druga strona medalu – pokazuje nam, jak źle może się potoczyć. 90. percentyl to strony pozostające w tyle — te ostatnie 10% witryn, które mają najwięcej kodu JS lub najdłuższy czas przetwarzania kodu w głównym wątku.
Tomy kodu JavaScript
Na początek warto przeanalizować rozmiar kodu JavaScript przesyłanego przez różne witryny w sieci.
Ilość kodu JavaScript (Kb) przesłanego na urządzenia mobilne
Percentyle
10
25
50
75
90
Wszystkie witryny
93.4
196.6
413.5
746.8
1201.6
witryny jQuery
110.3
219.8
430.4
748.6
1162.3
Witryny Vue
244.7
409.3
692.1
1065.5
1570.7
Witryny kątowe
445.1
675.6
1066.4
1761.5
2893.2
Witryny Reaguj
345.8
441.6
690.3
1238.5
1893.6
Ilość kodu JavaScript wysłanego na urządzenia mobilne
Ilość kodu JavaScript (Kb) przeniesiona na urządzenia stacjonarne
Percentyle
10
25
50
75
90
Wszystkie witryny
105.5
226.6
450.4
808.8
1267.3
witryny jQuery
121.7
242.2
458.3
803.4
1235.3
Witryny Vue
248.0
420.1
718.0
1122.5
1643.1
Witryny kątowe
468.8
716.9
1144.2
1930.0
3283.1
Witryny Reaguj
308.6
469.0
841.9
1472.2
2197.8
Ilość kodu JavaScript wysłanego do urządzeń stacjonarnych
Jeśli mówimy tylko o rozmiarze kodu JS, który strony wysyłają do urządzeń, to wszystko wygląda tak, jak można by się spodziewać. Mianowicie użycie jednego z frameworków oznacza, że nawet w idealnej sytuacji zwiększy się objętość kodu JavaScript strony. Nie jest to zaskakujące - nie można uczynić frameworku JavaScript podstawą witryny i oczekiwać, że objętość kodu JS projektu będzie bardzo mała.
Niezwykłe w tych danych jest to, że niektóre frameworki i biblioteki można uznać za lepszy punkt wyjścia dla projektu niż inne. Strony z jQuery wyglądają najlepiej. W wersjach witryn na komputery zawierają one o 15% więcej kodu JavaScript niż wszystkie witryny, a na urządzeniach mobilnych zawierają o 18% więcej. (Trzeba przyznać, że dochodzi tu do pewnego uszkodzenia danych. Faktem jest, że jQuery jest obecny w wielu witrynach, więc naturalne jest, że takie witryny są ściślej niż inne powiązane z całkowitą liczbą witryn. Nie wpływa to jednak na to, jak surowe dane są wyprowadzane dla każdej struktury.)
Podczas gdy wzrost objętości kodu o 15-18% jest godną uwagi liczbą, porównując to z innymi frameworkami i bibliotekami, można stwierdzić, że „podatek” pobierany przez jQuery jest bardzo niski. Witryny Angular w 10 percentylu wysyłają o 344% więcej danych na komputer niż wszystkie witryny i o 377% więcej na urządzenia mobilne. Witryny React są na drugim miejscu pod względem obciążenia, wysyłając o 193% więcej kodu na komputer niż wszystkie witryny i o 270% więcej na urządzenia mobilne.
Wcześniej wspomniałem, że choć korzystanie z frameworka oznacza, że w projekcie znajdzie się pewna ilość kodu, to już na samym początku prac nad nim mam nadzieję, że framework jest w stanie w jakiś sposób ograniczyć dewelopera. W szczególności mówimy o ograniczeniu maksymalnej ilości kodu.
Co ciekawe, strony jQuery podążają za tym pomysłem. Chociaż są nieco cięższe niż wszystkie witryny na 10. percentylu (o 15-18%), są nieco lżejsze na 90. percentylu i wynoszą około 3% zarówno na komputerach, jak i urządzeniach mobilnych. Nie oznacza to, że jest to bardzo znacząca korzyść, ale można powiedzieć, że witryny jQuery przynajmniej nie mają ogromnych rozmiarów kodu JavaScript, nawet w swoich największych wersjach.
Ale tego samego nie można powiedzieć o innych frameworkach.
Podobnie jak w przypadku 10 percentyla, na 90 percentylu strony na Angular i React różnią się od innych stron, ale różnią się niestety na gorsze.
Na 90. percentylu witryny Angular wysyłają o 141% więcej danych na urządzenia mobilne niż wszystkie witryny i o 159% więcej na komputery. Witryny React wysyłają o 73% więcej na komputer niż wszystkie witryny i o 58% więcej na urządzenia mobilne. Rozmiar kodu witryn React na 90. percentylu wynosi 2197.8 KB. Oznacza to, że takie strony przesyłają do urządzeń mobilnych o 322.9 KB więcej danych niż ich najbliżsi konkurenci bazujący na Vue. Przepaść między witrynami desktopowymi opartymi na Angular i React a innymi witrynami jest jeszcze większa. Na przykład strony React na komputery stacjonarne wysyłają do urządzeń o 554.7 KB więcej kodu JS niż podobne strony Vue.
Czas potrzebny na przetworzenie kodu JavaScript w głównym wątku
Powyższe dane jednoznacznie wskazują, że strony korzystające z badanych frameworków i bibliotek zawierają duże ilości kodu JavaScript. Ale oczywiście to tylko jedna część naszego równania.
Po dotarciu kodu JavaScript do przeglądarki należy doprowadzić go do stanu umożliwiającego działanie. Szczególnie wiele problemów powodują te działania, które należy wykonać z kodem w głównym wątku przeglądarki. Główny wątek odpowiada za przetwarzanie działań użytkownika, obliczanie stylów, budowanie i wyświetlanie układu strony. Jeśli przeciążysz główny wątek zadaniami JavaScript, nie będzie on miał możliwości wykonania reszty zadań na czas. Prowadzi to do opóźnień i „przerw” w pracy stron.
Baza danych HTTP Archive zawiera informacje o tym, ile czasu zajmuje przetworzenie kodu JavaScript w głównym wątku silnika V8. Oznacza to, że możemy zebrać te dane i dowiedzieć się, ile czasu zajmuje główny wątek przetwarzanie JavaScript różnych witryn.
Czas procesora (w milisekundach) związany z przetwarzaniem skryptów na urządzeniach mobilnych
Percentyle
10
25
50
75
90
Wszystkie witryny
356.4
959.7
2372.1
5367.3
10485.8
witryny jQuery
575.3
1147.4
2555.9
5511.0
10349.4
Witryny Vue
1130.0
2087.9
4100.4
7676.1
12849.4
Witryny kątowe
1471.3
2380.1
4118.6
7450.8
13296.4
Witryny Reaguj
2700.1
5090.3
9287.6
14509.6
20813.3
Czas procesora związany z przetwarzaniem skryptów na urządzeniach mobilnych
Czas procesora (w milisekundach) związany z przetwarzaniem skryptów na urządzeniach stacjonarnych
Percentyle
10
25
50
75
90
Wszystkie witryny
146.0
351.8
831.0
1739.8
3236.8
witryny jQuery
199.6
399.2
877.5
1779.9
3215.5
Witryny Vue
350.4
650.8
1280.7
2388.5
4010.8
Witryny kątowe
482.2
777.9
1365.5
2400.6
4171.8
Witryny Reaguj
508.0
1045.6
2121.1
4235.1
7444.3
Czas procesora związany z przetwarzaniem skryptów na urządzeniach stacjonarnych
Tutaj możesz zobaczyć coś bardzo znajomego.
Na początek strony z jQuery wydają znacznie mniej na przetwarzanie JavaScript w głównym wątku niż inne strony. Na 10. percentylu, w porównaniu ze wszystkimi witrynami, witryny jQuery na urządzeniach mobilnych spędzają o 61% więcej czasu na przetwarzaniu kodu JS w głównym wątku. W przypadku desktopowych serwisów jQuery czas przetwarzania wzrasta o 37%. Na 90. percentylu witryny jQuery osiągają wyniki bardzo zbliżone do wyników zagregowanych. W szczególności witryny jQuery na urządzeniach mobilnych spędzają 1.3% mniej czasu na głównym wątku niż wszystkie witryny i 0.7% mniej czasu na urządzeniach stacjonarnych.
Po drugiej stronie naszej oceny znajdują się ramy, które charakteryzują się największym obciążeniem głównego wątku. To znowu jest Angular i React. Jedyna różnica między nimi polega na tym, że podczas gdy witryny Angular wysyłają więcej kodu do przeglądarek niż witryny React, witryny Angular wymagają mniej czasu procesora na przetworzenie kodu. Znacznie mniej.
Na 10 percentylu strony Angular na komputery stacjonarne spędzają 230% więcej czasu na przetwarzaniu kodu JS głównego wątku niż wszystkie inne strony. W przypadku witryn mobilnych liczba ta wynosi 313%. Najgorzej radzą sobie strony reagujące. Na komputerach spędzają o 248% więcej czasu na przetwarzaniu kodu niż na wszystkich witrynach i o 658% więcej na urządzeniach mobilnych. 658% to nie pomyłka. Na 10 percentylu strony React spędzają 2.7 sekundy czasu głównego wątku na przetwarzaniu swojego kodu.
90. percentyl w porównaniu z tymi ogromnymi liczbami wygląda przynajmniej trochę lepiej. W porównaniu do wszystkich witryn projekty Angular spędzają 29% więcej czasu na urządzeniach stacjonarnych w głównym wątku i 27% więcej czasu na urządzeniach mobilnych. W przypadku witryn React te same liczby wyglądają odpowiednio na 130% i 98%.
Odchylenia procentowe dla 90 percentyla wyglądają lepiej niż podobne wartości dla 10 percentyla. Ale tutaj warto pamiętać, że liczby wskazujące czas wydają się dość przerażające. Powiedzmy, że 20.8 sekundy w głównym wątku mobilnym dla strony internetowej zbudowanej przy użyciu React. (Myślę, że historia tego, co faktycznie dzieje się w tym czasie, jest warta osobnego artykułu).
Jest tu jedna potencjalna komplikacja (dzięki za zwrócenie mojej uwagi na tę cechę, oraz za uważne rozważenie danych z tego punktu widzenia). Faktem jest, że wiele witryn korzysta z kilku narzędzi front-end. W szczególności widziałem wiele witryn korzystających z jQuery wraz z React lub Vue, ponieważ strony te migrują z jQuery do innych frameworków lub bibliotek. W rezultacie ponownie trafiłem do bazy danych, tym razem wybierając tylko te linki, które odpowiadają witrynom, które używają tylko React, jQuery, Angular lub Vue, ale nie żadnej ich kombinacji. Oto, co mam.
Czas procesora (w milisekundach) związany z przetwarzaniem skryptów na urządzeniach mobilnych w sytuacji, gdy strony wykorzystują tylko jeden framework lub tylko jedną bibliotekę
Percentyle
10
25
50
75
90
Witryny, które używają tylko jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Witryny, które używają tylko Vue
944.0
1716.3
3194.7
5959.6
9843.8
Witryny, które używają tylko Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Witryny, które używają tylko React
2443.2
4620.5
10061.4
17074.3
24956.3
Czas procesora związany z przetwarzaniem skryptów na urządzeniach mobilnych w sytuacji, gdy strony używają tylko jednego frameworka lub tylko jednej biblioteki
Po pierwsze, coś, co nie jest zaskakujące: gdy witryna korzysta tylko z jednego frameworka lub jednej biblioteki, wydajność takiej witryny najczęściej poprawia się. Każdy instrument działa lepiej na 10. i 25. percentylu. To ma sens. Witryna utworzona przy użyciu jednego frameworka powinna działać lepiej niż witryna utworzona przy użyciu dwóch lub więcej frameworków lub bibliotek.
W rzeczywistości wydajność każdego badanego narzędzia front-end wygląda lepiej we wszystkich przypadkach, z wyjątkiem jednego ciekawego wyjątku. Zaskoczyło mnie to, że na poziomie 50. percentyla i powyżej strony korzystające z React działają gorzej, gdy React jest jedyną biblioteką, z której korzystają. Nawiasem mówiąc, to było powodem, dla którego przedstawiam te dane tutaj.
To trochę dziwne, ale nadal będę próbował szukać wyjaśnienia tej dziwności.
Jeśli projekt używa zarówno React, jak i jQuery, to prawdopodobnie jest on gdzieś w połowie przejścia z jQuery do React. Być może ma bazę kodu, w której te biblioteki są mieszane. Ponieważ widzieliśmy już, że witryny jQuery spędzają mniej czasu na głównym wątku niż witryny React, może to nam powiedzieć, że zaimplementowanie niektórych funkcji w jQuery pomaga stronie działać nieco lepiej.
Ale gdy projekt przechodzi z jQuery do React i bardziej polega na React, sytuacja się zmienia. Jeśli witryna jest naprawdę wysokiej jakości, a jej twórcy ostrożnie stosują React, to z taką witryną wszystko będzie dobrze. Ale dla przeciętnej witryny React, intensywne korzystanie z React oznacza, że główny wątek jest mocno obciążony.
Przepaść między urządzeniami mobilnymi a stacjonarnymi
Kolejnym punktem widzenia, z którego spojrzałem na badane dane, było zbadanie, jak duża jest przepaść między pracą z witrynami na urządzeniach mobilnych i stacjonarnych. Jeśli mówimy o porównywaniu ilości kodu JavaScript, to takie porównanie nie ujawnia niczego strasznego. Oczywiście byłoby miło zobaczyć mniejsze ilości kodu do pobrania, ale nie ma dużej różnicy w ilości kodu mobilnego i stacjonarnego.
Jeśli jednak przeanalizujemy czas potrzebny do przetworzenia kodu, zauważalna staje się bardzo duża przepaść między urządzeniami mobilnymi a stacjonarnymi.
Wzrost czasu (w procentach) związany z przetwarzaniem skryptów na urządzeniach mobilnych w porównaniu do komputerów stacjonarnych
Percentyle
10
25
50
75
90
Wszystkie witryny
144.1
172.8
185.5
208.5
224.0
witryny jQuery
188.2
187.4
191.3
209.6
221.9
Witryny Vue
222.5
220.8
220.2
221.4
220.4
Witryny kątowe
205.1
206.0
201.6
210.4
218.7
Witryny Reaguj
431.5
386.8
337.9
242.6
179.6
Chociaż można się spodziewać pewnej różnicy w szybkości przetwarzania kodu między telefonem a laptopem, tak duże liczby mówią mi, że nowoczesne frameworki nie są wystarczająco ukierunkowane na urządzenia o niskim poborze mocy i że starają się wypełnić odkrytą lukę. Nawet na 10 percentylu strony React spędzają 431.5% więcej czasu w głównym wątku mobilnym niż w głównym wątku stacjonarnym. jQuery ma najmniejszą lukę, ale nawet tutaj odpowiednia liczba wynosi 188.2%. Kiedy twórcy stron internetowych robią swoje projekty w taki sposób, że ich przetwarzanie wymaga więcej czasu procesora (a tak się dzieje, az czasem jest tylko gorzej), właściciele urządzeń o małej mocy muszą za to zapłacić.
Wyniki
Dobre frameworki powinny dawać programistom dobrą podstawę do budowania projektów internetowych (pod względem bezpieczeństwa, dostępności, wydajności) lub powinny mieć wbudowane ograniczenia, które utrudniają zbudowanie czegoś, co je narusza.
Wydaje się, że nie ma to zastosowania do wydajności projektów internetowych (i prawdopodobnie nie do ich ).
Warto zauważyć, że tylko dlatego, że witryny React lub Angular spędzają więcej czasu procesora na przygotowywaniu kodu niż inne, niekoniecznie oznacza to, że witryny React są bardziej obciążające procesor niż witryny Vue podczas działania. W rzeczywistości dane, które przejrzeliśmy, mówią bardzo niewiele o wydajności operacyjnej frameworków i bibliotek. Mówią więcej o podejściach programistycznych, które świadomie lub nie, te ramy mogą popchnąć programistów. Mówimy o dokumentacji dla frameworków, o ich ekosystemie, o wspólnych technikach programistycznych.
Warto również wspomnieć o czymś, czego tutaj nie analizowaliśmy, a mianowicie o tym, ile czasu urządzenie spędza na wykonywaniu kodu JavaScript podczas poruszania się między stronami serwisu. Argumentem przemawiającym za SPA jest to, że po załadowaniu aplikacji jednostronicowej do przeglądarki użytkownik teoretycznie będzie mógł szybciej otwierać strony serwisu. Moje własne doświadczenie mówi mi, że jest to dalekie od prawdy. Ale nie mamy danych, aby wyjaśnić tę kwestię.
Oczywiste jest, że jeśli używasz frameworka lub biblioteki do stworzenia strony internetowej, idziesz na kompromis pod względem początkowego załadowania projektu i przygotowania go do pracy. Dotyczy to nawet najbardziej pozytywnych scenariuszy.
W odpowiednich sytuacjach można pójść na pewne kompromisy, ale ważne jest, aby programiści świadomie dokonywali takich kompromisów.
Ale mamy też powody do optymizmu. Nie mogę się doczekać, aby zobaczyć, jak ściśle programiści Chrome współpracują z programistami niektórych sprawdzonych przez nas narzędzi front-end, starając się poprawić wydajność tych narzędzi.
Jestem jednak pragmatykiem. Nowe architektury powodują problemy z wydajnością równie często, jak je rozwiązują. A naprawianie błędów wymaga czasu. Tak jak nie powinniśmy się spodziewać rozwiąże wszystkie problemy z wydajnością, nie należy tego oczekiwać od nowych wersji naszych ulubionych frameworków.
Jeśli chcesz użyć jednego z narzędzi front-endowych omówionych w tym artykule, oznacza to, że musisz włożyć dodatkowy wysiłek, aby w międzyczasie nie zaszkodzić wydajności swojego projektu. Oto kilka kwestii, które należy wziąć pod uwagę przed rozpoczęciem nowego frameworka:
- Sprawdź się ze zdrowym rozsądkiem. Czy naprawdę musisz korzystać z wybranego frameworka? Dzisiejszy czysty JavaScript potrafi wiele.
- Czy istnieje lżejsza alternatywa dla wybranego frameworka (np. Preact, Svelte lub coś innego), która może zapewnić 90% możliwości tego frameworka?
- Jeśli już używasz frameworka, zastanów się, czy istnieje coś, co oferuje lepsze, bardziej konserwatywne, standardowe opcje (np. Nuxt.js zamiast Vue, Next.js zamiast React itd.).
- Co będzie twoje Wydajność JavaScript?
- Jak możesz proces programistyczny, aby utrudnić wstrzykiwanie większej ilości kodu JavaScript do projektu, niż jest to absolutnie konieczne?
- Jeśli używasz frameworka w celu ułatwienia programowania, rozważ to wysłać kod frameworka do klientów. Może uda Ci się rozwiązać wszystkie problemy na serwerze?
Zwykle warto przyjrzeć się tym pomysłom, niezależnie od tego, co dokładnie wybrałeś do tworzenia front-endu. Ale są one szczególnie ważne, gdy pracujesz nad projektem, w którym od samego początku brakuje wydajności.
Drodzy Czytelnicy! Jak widzisz idealny framework JavaScript?
Źródło: www.habr.com