Немає швидшого способу уповільнити сайт (такий ось каламбур), ніж використовувати на ньому купу JavaScript-коду. При використанні JavaScript доводиться розплачуватися за це продуктивністю проектів щонайменше чотири рази. Ось чим JavaScript-код сайту навантажує системи користувачів:
- Завантаження файлу через мережу.
- Парсинг та компіляція розпакованого вихідного коду після завантаження.
- Виконує JavaScript-код.
- Споживання пам'яті.
Ця комбінація виявляється .
А ми включаємо до складу своїх проектів дедалі більше JS-коду. У міру того, як організації рухаються у бік сайтів, що працюють на базі фреймворків та бібліотек на кшталт React, Vue та інших, ми робимо основний функціонал сайтів, що дуже залежить від JavaScript.
Я бачив безліч дуже важких сайтів, які використовують JavaScript-фреймворки. Але моє бачення питання відрізняється сильною упередженістю. Справа в тому, що компанії, з якими я працюю, звертаються до мене саме через те, що вони зустрічаються зі складними проблемами в галузі продуктивності сайтів. В результаті мені стало цікаво дізнатися про те, наскільки поширена ця проблема, і про те, які «штрафи» ми платимо тоді, коли вибираємо той чи інший фреймворк як основу для якогось сайту.
З'ясувати це мені допоміг проект .
Дані
Проект HTTP Archive загалом відстежує 4308655 посилань на звичайні сайти, призначені для настільних пристроїв, та 5484239 посилань на мобільні сайти. Серед багатьох показників, пов'язаних із цими посиланнями, є список технологій, виявлених на відповідних сайтах. Це означає, що ми можемо побудувати вибірку з тисяч сайтів, які використовують різні фреймворки та бібліотеки, і дізнатися про те, який обсяг коду вони надсилають клієнтам, і про те, яке навантаження на системи користувачів створює цей код.
Я збирав дані за березень 2020 року, це були найсвіжіші дані, до яких я мав доступ.
Я вирішив порівняти агреговані HTTP Archive дані по всіх сайтах з даними по сайтах, на яких виявлено використання React, Vue та Angular, хоча я розглядав можливість використання іншого вихідного матеріалу.
Щоб було цікавіше, я додав у набір вихідних даних ще й сайти, на яких застосовується jQuery. Ця бібліотека все ще має величезну популярність. Вона, крім того, представляє підхід до розробки веб-сайтів, який відрізняється від моделі односторінкового додатка (SPA, Single Page Application), пропонований React, Vue та Angular.
Посилання в HTTP Archive, що представляють сайти, на яких виявлено використання цікавих для нас технологій
Фреймворк чи бібліотека
Посилання на мобільні сайти
Посилання на звичайні сайти
jQuery
4615474
3714643
Реагувати
489827
241023
Vue
85649
43691
Angular
19423
18088
Надії та мрії
Перш ніж ми перейдемо до аналізу даних, хочу розповісти, на що мені хотілося б сподіватися.
Я вважаю, що в ідеальному світі фреймворки повинні йти далі задоволення потреб розробників і давати певні переваги звичайним користувачам, які працюють з нашими сайтами. Продуктивність - це лише одна з таких переваг. Тут ще спадають на думку доступність і безпека. Але це лише найважливіше.
Отже, в ідеальному світі фреймворк повинен полегшувати створення високопродуктивного сайту. Робитися це має або за рахунок того, що фреймворк дає розробнику гідну базу, на якій можна побудувати проект, або за рахунок того, що накладає на розробку обмеження, висуває до неї вимоги, які ускладнюють розробку чогось такого, що виявиться повільним.
Найкращі фреймворки повинні робити і те й інше: і давати хорошу базу, і накладати на роботу обмеження, що дозволяють досягати гідного результату.
Аналіз медіанних значень даних не дасть нам необхідної інформації. І насправді такий підхід залишає за межами нашої уваги . Натомість я вивів із наявних у мене даних показники, виражені в перцентилях. Це – 10, 25, 50 (медіана), 75, 90 перцентилів.
Мене особливо цікавлять 10 та 90 перцентилів. 10 перцентиль представляє найкращі показники (або, принаймні, більш менш близькі до найкращих) для конкретного фреймворку. Іншими словами, це означає, що лише 10% сайтів, що використовують конкретний фреймворк, доходять до цього, або до вищого рівня. 90 перцентиль, з іншого боку, це – зворотний бік медалі – він показує нам те, наскільки все може бути погано. 90 перцентиль - це сайти, що плетуться в хвості - останні 10% сайтів, які характеризуються найбільшими обсягами JS-коду або найбільшим часом, необхідним на обробку їх коду в головному потоці.
Об'єм JavaScript-коду
Для початку є сенс проаналізувати розмір JavaScript-коду, що передається різними сайтами по мережі.
Об'єм JavaScript-коду (Кб), переданого на мобільні пристрої
Перцентили
10
25
50
75
90
Усі сайти
93.4
196.6
413.5
746.8
1201.6
jQuery-сайти
110.3
219.8
430.4
748.6
1162.3
Vue-сайти
244.7
409.3
692.1
1065.5
1570.7
Angular-сайти
445.1
675.6
1066.4
1761.5
2893.2
React-сайти
345.8
441.6
690.3
1238.5
1893.6
Об'єм JavaScript-коду, що передається на мобільні пристрої
Об'єм JavaScript-коду (Кб), переданого на настільні пристрої
Перцентили
10
25
50
75
90
Усі сайти
105.5
226.6
450.4
808.8
1267.3
jQuery-сайти
121.7
242.2
458.3
803.4
1235.3
Vue-сайти
248.0
420.1
718.0
1122.5
1643.1
Angular-сайти
468.8
716.9
1144.2
1930.0
3283.1
React-сайти
308.6
469.0
841.9
1472.2
2197.8
Об'єм JavaScript-коду, що передається на настільні пристрої
Якщо говорити тільки про розміри JS-коду, що відправляється сайтами на пристрої, все виглядає приблизно так, як можна очікувати. А саме, якщо використовується один із фреймворків — це означає, що навіть в ідеальній ситуації обсяг JavaScript-коду сайту зросте. Це і не дивно - не можна зробити JavaScript-фреймворк основою сайту і очікувати, що обсяг JS-коду проекту виявиться дуже низьким.
Примітно в цих даних те, що деякі фреймворки та бібліотеки можна вважати більш вдалою стартовою точкою проекту, ніж інші. Сайти з jQuery виглядають найкраще. У настільних версіях сайтів вони містять на 15% більше JavaScript, ніж усі сайти, а в мобільних – на 18% більше. (Треба визнати, що тут можна спостерігати деяке спотворення даних. Справа в тому, що jQuery присутня на безлічі сайтів, тому цілком природно те, що такі сайти тісніші за інші пов'язані із загальною кількістю сайтів. Однак це не впливає на те, як вихідні дані виводяться для кожного фреймворку.)
Хоча зростання обсягу коду в 15-18% — це помітна цифра, порівнявши це з іншими фреймворками та бібліотеками, можна дійти висновку про те, що податок, що стягується jQuery, дуже низький. Сайти на Angular з 10 перцентиля відправляють на настільні пристрої на 344% більше даних, ніж усі сайти, а на мобільні – на 377% більше. React-сайти – наступні за «вагою», відправляють на настільні пристрої на 193% більше коду, ніж усі сайти, а на мобільні – на 270% більше.
Раніше я вже згадував про те, що хоча застосування фреймворку і означає, що в проект, на початку роботи над ним, буде включений певний обсяг коду, я сподіваюся на те, що фреймворк здатний якось обмежувати розробника. Зокрема, йдеться про обмеження максимального обсягу коду.
Цікаво те, що jQuery-сайти дотримуються цієї ідеї. Хоча вони, на рівні 10 перцентилів, трохи важчі за всі сайти (на 15-18%), вони, на рівні 90 перцентилів, трохи легші за всіх — приблизно на 3% і в настільному, і в мобільному варіантах. Не можна сказати, що це дуже вже значна вигода, але можна сказати, що сайти на jQuery, принаймні, не відрізняються величезними розмірами JavaScript-коду навіть у своїх найбільших варіантах.
А ось про інші фреймворки того ж самого сказати не можна.
Так само, як і у випадку з 10 перцентилем, на 90 перцентилі сайти на Angular та React відрізняються від інших сайтів, але відрізняються вони, на жаль, у гірший бік.
На 90% Angular-сайти відправляють на мобільні пристрої на 141% більше даних, ніж усі сайти, а на настільні — на 159% більше. Сайти на React відправляють на настільні пристрої на 73% більше, ніж усі сайти, а на мобільні – на 58% більше. Розмір коду React-сайтів на 90% становить 2197.8 Кб. Це означає, що такі сайти відправляють на мобільні пристрої на 322.9 Кб більше даних, ніж їхні найближчі конкуренти, що базуються на Vue. Розрив між настільними сайтами, заснованими на Angular та React, та між іншими сайтами, ще більший. Наприклад, настільні React-сайти відправляють на пристрої на 554.7 Кб більше JS-коду, ніж аналогічні Vue-сайти.
Час, що йде на обробку JavaScript-коду в головному потоці
Наведені вище дані чітко вказують на те, що сайти, які використовують досліджувані фреймворки та бібліотеки, містять великі обсяги JavaScript-коду. Але, звісно, це лише одна з частин нашого рівняння.
Після того, як JavaScript-код прибув до браузера, його потрібно привести в працездатний стан. Особливо багато проблем викликають ті дії, які доводиться проводити з кодом у головному потоці браузера. Головний потік відповідальний за обробку дій користувача, за обчислення стилів, за побудову та виведення макету сторінки. Якщо завалити головний потік JavaScript-справами, він не матиме можливості вчасно вирішувати інші завдання. Це призводить до затримок та «гальм» у роботі сторінок.
У базі даних HTTP Archive є відомості про те, скільки часу йде на обробку JavaScript-коду в головному потоці двигуна V8. Це означає, що ми можемо зібрати ці дані і дізнатися, скільки часу головного потоку потрібно на обробку JavaScript різних сайтів.
Процесорний час (у мілісекундах), що стосується обробки скриптів на мобільних пристроях
Перцентили
10
25
50
75
90
Усі сайти
356.4
959.7
2372.1
5367.3
10485.8
jQuery-сайти
575.3
1147.4
2555.9
5511.0
10349.4
Vue-сайти
1130.0
2087.9
4100.4
7676.1
12849.4
Angular-сайти
1471.3
2380.1
4118.6
7450.8
13296.4
React-сайти
2700.1
5090.3
9287.6
14509.6
20813.3
Процесорний час, що стосується обробки скриптів на мобільних пристроях
Процесорний час (у мілісекундах), що стосується обробки скриптів на настільних пристроях
Перцентили
10
25
50
75
90
Усі сайти
146.0
351.8
831.0
1739.8
3236.8
jQuery-сайти
199.6
399.2
877.5
1779.9
3215.5
Vue-сайти
350.4
650.8
1280.7
2388.5
4010.8
Angular-сайти
482.2
777.9
1365.5
2400.6
4171.8
React-сайти
508.0
1045.6
2121.1
4235.1
7444.3
Процесорний час, що стосується обробки скриптів на настільних пристроях
Тут можна побачити щось дуже знайоме.
Для початку сайти з jQuery витрачають на обробку JavaScript в головному потоці значно менше, ніж інші. На 10-й перцентилі, у порівнянні з усіма сайтами, jQuery-сайти на мобільних пристроях витрачають на обробку JS-коду в головному потоці на 61% більше часу. У разі настільних jQuery-сайтів час обробки зростає на 37%. На рівні 90 перцентилів показники jQuery-сайтів дуже близькі до агрегованих показників. Зокрема, jQuery-сайти на мобільних пристроях витрачають на 1.3% менше часу в головному потоці, ніж усі сайти, а на настільних пристроях — на 0.7% менше часу.
З іншого боку нашого рейтингу є фреймворки, які характеризуються найбільшим навантаженням на головний потік. Це, знову, Angular та React. Різниця між ними полягає тільки в тому, що, хоча Angular-сайти шлють у браузери більші обсяги коду, ніж React-сайти, на обробку коду Angular-сайтів йде менше процесорного часу. Значно менше.
На 10 перцентил настільні Angular-сайти витрачають на обробку JS-коду на 230% більше часу головного потоку, ніж усі сайти. Для мобільних сайтів цей показник складає 313%. React-сайти характеризуються найгіршими показниками. На настільних пристроях вони витрачають на обробку коду на 248% більше часу, ніж усі сайти, а на мобільних – на 658% більше. 658% - це не друкарська помилка. На 10 перцентилі React-сайти витрачають 2.7 секунди часу головного потоку на обробку наявного коду.
Показники 90 перцентиля, якщо порівняти їх із цими величезними цифрами, виглядають щонайменше трохи краще. Angular-проекти, порівняні з усіма сайтами, витрачають на настільних пристроях у головному потоці на 29% більше часу, а на мобільних пристроях – на 27% більше. У випадку з React-сайтами аналогічні показники виглядають відповідно як 130% і 98%.
Відсоткові значення відхилень для 90 перцентиля виглядають краще ніж схожі значення для 10 перцентиля. Але тут варто пам'ятати про те, що цифри, що вказують на якийсь час, здаються досить страшними. Скажімо, 20.8 секунд у головному потоці мобільного пристрою для сайту, побудованого на React. (Вважаю, розповідь про те, що насправді відбувається за цей час, гідний окремої статті).
Тут є одна потенційна складність (дякую за те, що він привернув мою увагу до цієї особливості, і за те, що я уважно розглянув дані з цього погляду). Справа в тому, що на багатьох сайтах використовується кілька фронтенд-інструментів. Зокрема, я бачив безліч сайтів, які використовують jQuery разом з React або Vue, оскільки ці сайти мігрують з jQuery на інші фреймворки або бібліотеки. В результаті я знову звернувся до бази даних, вибираючи цього разу лише ті посилання, які відповідають сайтам, на яких використовується тільки React, jQuery, Angular або Vue, але не їх комбінація. Ось що в мене вийшло.
Процесорний час (у мілісекундах), що стосується обробки скриптів на мобільних пристроях у ситуації, коли на сайтах використовується лише один фреймворк або тільки одна бібліотека
Перцентили
10
25
50
75
90
Сайти, на яких використовується лише jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Сайти, на яких використовується лише Vue
944.0
1716.3
3194.7
5959.6
9843.8
Сайти, на яких використовується лише Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Сайти, на яких використовується лише React
2443.2
4620.5
10061.4
17074.3
24956.3
Процесорний час, що стосується обробки скриптів на мобільних пристроях у ситуації, коли на сайтах використовується лише один фреймворк, або тільки одна бібліотека
Спочатку про те, що подиву не викликає: коли на сайті використовується лише один фреймворк або одна бібліотека, продуктивність такого сайту частіше покращується, ніж не покращується. Показники по кожному інструменту виглядають краще на 10 та 25 перцентилях. Це має сенс. Сайт, який зроблений з використанням одного фреймворку, повинен бути продуктивнішим, ніж сайт, який зроблений з використанням двох або більшої кількості фреймворків або бібліотек.
Насправді, показники по кожному досліджуваному фронтенд-інструменту виглядають краще у всіх випадках, за винятком одного цікавого виключення. Мене здивувало те, що на рівні 50 перцентиля і вище сайти, які використовують React, відрізняються найгіршою продуктивністю в тому випадку, якщо React — це єдина бібліотека, що використовується на них. Це, до речі, спричинило те, що я наводжу тут ці дані.
Це трохи дивно, але я все ж таки спробую пошукати пояснення цієї дивності.
Якщо в проекті використовується і React, і jQuery, цей проект, швидше за все, знаходиться десь на півдорозі в процесі переходу з jQuery на React. Можливо, він має кодову базу, де ці бібліотеки змішані. Так як ми вже бачили, що jQuery-сайти витрачають у головному потоці менше часу, ніж React-сайти, це може говорити нам про те, що реалізація якогось функціоналу на jQuery допомагає трохи покращити показники сайту.
Але в міру того, як проект, переходячи з jQuery на React, все більше покладається на React ситуація змінюється. Якщо сайт зроблений по-справжньому якісно, і розробники сайту використовують React обачно, то з таким сайтом все буде добре. Але для середньостатистичного React-сайту широке використання React означає, що головний потік піддається підвищеному навантаженню.
Розрив між мобільними та настільними пристроями
Ще один погляд, з якого я глянув на досліджувані дані, полягала у дослідженні того, наскільки великий розрив між роботою з сайтами на мобільних і настільних пристроях. Якщо говорити про зіставлення обсягів JavaScript-коду, то нічого страшного таке зіставлення не виявляє. Звичайно, приємно було б бачити менші обсяги коду, що завантажується, але особливої різниці в обсягах мобільного і настільного коду немає.
А от якщо проаналізувати час, необхідний для обробки коду, стає помітним дуже великий розрив між мобільними та настільними пристроями.
Зростання часу (у відсотках), що відноситься до обробки скриптів на мобільних пристроях порівняно з настільними
Перцентили
10
25
50
75
90
Усі сайти
144.1
172.8
185.5
208.5
224.0
jQuery-сайти
188.2
187.4
191.3
209.6
221.9
Vue-сайти
222.5
220.8
220.2
221.4
220.4
Angular-сайти
205.1
206.0
201.6
210.4
218.7
React-сайти
431.5
386.8
337.9
242.6
179.6
Хоча деяка різниця у швидкості обробки коду між телефоном і ноутбуком - це цілком очікувано, такі великі числа говорять мені про те, що сучасні фреймворки недостатньо націлені на малопотужні пристрої, і прагнення закриття виявленого розриву. Навіть на 10 перцентилі React-сайти витрачають у головному потоці мобільних пристроїв на 431.5% більше часу, ніж у головному потоці настільних. Найменший розрив спостерігається у jQuery, але навіть тут відповідний показник дорівнює 188.2%. Коли розробники сайтів роблять свої проекти так, що на їх обробку потрібно більше процесорного часу (а так і відбувається, і згодом все гірше), платити за це доводиться власникам малопотужних пристроїв.
Підсумки
Хороші фреймворки повинні давати розробникам якісну базу для створення веб-проектів (у плані безпеки, доступності, продуктивності), або мають вбудовані обмеження, які ускладнюють створення чогось такого, що ці обмеження порушують.
Це, як здається, не відноситься до продуктивності веб-проектів (і, мабуть, до їх ).
Те, що React-або Angular-сайти витрачають більше процесорного часу на підготовку коду, ніж інші, не обов'язково означає те, що React-сайти під час роботи сильніше навантажують процесор, ніж Vue-сайти. Насправді, розглянуті нами дані дуже мало говорять про робочу продуктивність фреймворків та бібліотек. Вони більше говорять про підходи до розробки, до яких, усвідомлено чи ні, ці фреймворки можуть підштовхувати програмістів. Йдеться про документацію до фреймворків, про їх екосистему, про поширені прийоми розробки.
Ще варто сказати про те, що ми тут не аналізували, зокрема, про те, скільки часу пристрій витрачає на виконання JavaScript-коду при переходах між сторінками сайту. Доказ на користь SPA полягає в тому, що як тільки односторінковий додаток завантажено в браузер, користувач, теоретично, зможе швидше відкривати сторінки сайту. Мій власний досвід підказує мені, що це далеко не факт. Але ми не маємо даних, які дозволяють прояснити це питання.
Цілком зрозуміло лише те, що якщо ви використовуєте фреймворк або бібліотеку для створення сайту, ви йдете на компроміс у плані початкового завантаження проекту та підготовки його до роботи. Це стосується навіть найпозитивніших сценаріїв.
У відповідних ситуаціях цілком можна піти на деякі компроміси, але важливо, щоб розробники йшли б на такі компроміси усвідомлено.
Але ми маємо і привід для оптимізму. Мене надихає те, як щільно розробники Chrome взаємодіють із тими, хто займається деякими з розглянутих нами фронтенд-інструментів у прагненні допомогти покращити продуктивність цих інструментів.
Однак я прагматична людина. Нові архітектури також часто створюють проблеми з продуктивністю, як і вирішують їх. І на те, щоб усунути недоліки, потрібен час. Так само, як нам не варто очікувати того, що вирішать усі проблеми продуктивності, не варто чекати на це і від нових версій наших улюблених фреймворків.
Якщо ви хочете скористатися одним із розглянутих у цьому матеріалі фронтенд-інструментів, це означає, що вам доведеться докласти додаткових зусиль до того, щоб, між іншим, не зашкодити продуктивності свого проекту. Ось деякі міркування, які варто розглянути перед початком застосування нового фреймворку:
- Перевірте себе з погляду здорового глузду. Вам правда потрібно використовувати вибраний фреймворк? Чистий JavaScript сьогодні здатний на багато чого.
- Чи є легша альтернатива обраному фреймворку (на зразок Preact, Svelte чи чогось ще), здатна дати вам 90% можливостей цього фреймворку?
- Якщо ви вже користуєтеся якимось фреймворком — подумайте про те, чи є щось таке, що пропонує кращі, більш консервативні, стандартні параметри (наприклад Nuxt.js замість Vue, Next.js замість React, і так далі).
- Яким буде ваш JavaScript-продуктивності?
- Як ви можете процес розробки з метою ускладнення впровадження в проект більшого обсягу JavaScript-коду, ніж це необхідно?
- Якщо ви використовуєте фреймворк для зручності розробки, подумайте про те, надсилати код фреймворку клієнтам. Можливо, ви можете вирішити всі питання на сервері?
Зазвичай до цих ідей варто придивитися незалежно від того, що саме ви обрали для розробки фронтенду. Але вони особливо важливі тоді, коли ви працюєте над проектом, якому від початку не вистачає продуктивності.
Шановні читачі! Яким ви бачите ідеальний JavaScript-фреймворк?
Джерело: habr.com