Веб стає повільнішим?

У недавній історії на Hacker News стверджувалося, що швидкість веб-сторінок не підвищуються навіть зі збільшенням швидкостей Інтернету.

В цій статті я поясню, чому з вихідних даних такого висновку зробити не можна.

Також ми розглянемо зміни, що відбулися з пристроями та Інтернетом протягом попередніх десяти років, і розповімо, як вплинули ці вимірювання на швидкість інтернету.

Інтерпретація даних HTTP Archive

Цей графік з статті Nielsen Norman Group дає нам зрозуміти, що збільшення пропускної здатності мобільних мереж не привело до прискорення завантаження сторінок.

Однак швидкість підключення, використана HTTP Archive, не збільшилася за цей час.

Замість цього вона знизилася в 2013 році, перейшовши з WiFi на емульоване 3G-підключення .

C 2013 року метрика onLoad збільшилася на 55%, з 12,7с до 19,7с. Якщо ви купили телефон в 2013 році і з тих пір підключалися до Інтернету через 3G, то веб став для вас повільнішим. Перш ніж розповісти про те, як змінилися пристрої та веб за останні десять років, ось кілька приміток про те, як потрібно сприймати ці дані.

Навіщо дивитися на onLoad?

Подія load передається сторінкою, коли завантажені всі ресурси сторінки, такі як скрипти і зображення. Якщо шапка сторінки відмалюється швидко, але сторінка також завантажує ще 20 зображень нижче, то метрика onLoad дасть нам зрозуміти, що сторінка повільна. Інша сторінка може спочатку і не рендерити нічого корисного, а тільки починати завантажувати додаткові ресурси і рендерити контент вже після події onLoad. Проте, така сторінка буде здаватися швидкою. Тому onLoad не дуже підходить для вимірювання того, чи сприймає користувач сторінку як швидку. Навіщо взагалі дивитися на цю метрику? Тому що вона використовувалася тривалий час і HTTP Archive відстежував її з 2010 року. Більш новіші, наприклад, First Contentful Paint або Time to Interactive, були додані в HTTP Archive тільки в 2017 році.

Чи варто очікувати, що збільшення пропускної здатності призведе до прискорення завантаження сторінок?

Збільшення пропускної здатності прискорить завантаження сторінки, тільки якщо пропускна здатність виявляється на якомусь етапі вузьким місцем. Воно не допоможе, якщо ви сидите на гігабітному підключенні, а час передачі сигналу в обидва боки по мережі дорівнює одній секунді. Однак емульоване 3G-підключення на 1,6 Мбіт/с дуже повільне, тому варто очікувати значного підвищення швидкості при збільшенні пропускної спроможності. Середньостатистичний веб-сайт викачує в 2020 році 1,7 МБ даних, тобто при швидкості підключення HTTP Archive на скачку буде потрібно не менше 9 секунд.

Інші тонкощі HTTP Archive

У цій статті я буду багато говорити про «середньостатистичний веб-сайт». Варто зауважити, що HTTP Archive збирає дані тільки на головних сторінках, а не на сторінках глибше в ієрархії сайту. Також з часом виріс корпус тестованих доменів. Тести не завжди виконувалися на одному пристрої. Спочатку використовувався фізичний iPhone 4, а сьогодні тести виконуються на імітованому Android-пристрої. У цій статті ми розглядаємо медіанні метричні значення. Якщо більшість сайтів працює швидко, але один з п'яти веб-сайтів загальмовує телефон на 20 секунд, то ми не зможемо підвищити цю метрику.

Швидкість на настільних комп'ютерах

У цій статті ми розглянемо швидкість на мобільних пристроях в США. Однак якщо подивитися на дані настільних комп'ютерів з вихідної статті, то варто зауважити, що в 2013 році тестова пропускна здатність збільшилася, а затримка зменшилася.

Як змінилися мобільні мережі і пристрої за останні десять років?

Давайте розглянемо чотири фактори:

• пропускну здатність мережі
• мережеву затримку
• швидкості процесорів
• швидкість браузерів

Пропускна здатність мобільних мереж США

На цьому графіку показана середня пропускна здатність мобільних мереж США в різні роки за даними різних джерел. Вона збільшилася з 1 Мбіт/с до приблизно 30 Мбіт/с.

(Я не дуже ретельно збирав ці дані. Наприклад, я не завжди розбирався, чи збігається дата збору даних з датою їх публікації. Мої джерела можна знайти тут)

Затримка в мобільних мережах США

За цим параметром дані знайти було складніше, але результати показують, що затримка знизилася приблизно з 200 мс (2011 рік) до 50 мс (2020 рік).

Швидкості процесорів мобільних пристроїв

Мені не вдалося знайти дані по середнім швидкостям мобільних пристроїв в США. Однак Алекс Рассел і Surma опублікували графік рейтингу GeekBench 4 разом з роками випуску різних телефонів. Навіть бюджетні телефони стали в 4 рази швидше, а iPhone став потужнішим в 20 разів.

Як змінилися браузери?

За останні десять років була проведена велика робота над удосконаленням браузерів. JavaScript став ще важливішою частиною Інтернету, тому багато покращень зосереджені в цій області. Судячи з цим графіком з блогу V8, споживання ресурсів процесора на одну сторінку скоротилося в чотири рази.

Робота з мережею

Поліпшилася і робота браузерів з мережею. Наприклад, після введення в 2015 році HTTP/2 64% запитів обробляється по HTTP/2.

Як змінилися веб-сайти?

Давайте поглянемо на дані з HTTP Archive, щоб зрозуміти, як змінилися веб-сайти.

Вага сторінки

За проміжок часу з 2013 по 2020 рік вага сторінки для мобільних збільшився на 337%. В основному це викликано збільшенням кількості зображень і коду на JavaScript. Обсяг інших ресурсів теж сильно збільшився - підозрюю, що в основному це відео.

Графік починається з 2013 року, тому що в жовтні 2012 року HTTP Archive змінив методологію вимірювань. До цього вага сторінки недооцінювалася, тому що тест припинявся після спрацьовування події завантаження сторінки, навіть якщо після нього завантажувалися інші дані.

Час виконання JavaScript

Якщо незважаючи на прискорення мобільних мереж сторінки стають повільнішими, то найбільш імовірним винуватцем цього буде JavaScript. На жаль, HTTP Archive почав збирати ці дані тільки в кінці 2017 року, і з тих пір вони здаються стабільними.

Зниження в середині 2018 року, ймовірно, пов'язано зі зміною корпусу тестованих URL. Зверніть увагу, що абсолютна тривалість виконання (0,5с) менше, ніж ми зазвичай зустрічаємо в інструментах на зразок Lighthouse. Такі інструменти зазвичай уповільнюють виконання JavaScript для емуляції мобільного пристрою, але в тестах HTTP Archive ця система була несправною. Тому хоча це значення може бути реалістичним для телефонів середнього цінового діапазону, зазвичай вважається, що бюджетні телефони приблизно в чотири рази повільніше.

Відповідаємо на питання, чи став веб повільнішим

Чи став веб повільніше? Взагалі, це залежить від вашого пристрою, підключення до мережі і найчастіше відвідуваних веб-сайтів. Нам би треба було виміряти реальні дані швидкості, щоб отримати розподіл, яке демонструє, як змінюється сприйняття веба з плином часу різними користувачами. Крім того, залишається питання, чи повинен досвід того, хто відкриває тисячі сторінок в день враховуватися так само, як досвід того, хто тільки раз на тиждень відвідує Facebook? У мене немає докладних даних по окремим користувачам, але ми можемо розглянути це питання під кількома різними кутами:

1. Дані реальних користувачів з Chrome UX Report (CrUX)
2. Наївне моделювання на підставі змін веб-сайтів і пристроїв

Також я пробував завантажувати старі версії сторінок з archive.org і тестувати їх за допомогою Lighthouse, але не зміг в прийнятні терміни отримати значущі дані. Наприклад, іноді в архіві сторінки були відсутні зображення.

Дані з Chrome User Experience Report

Великим обмеженням CrUX є те, що їх почали збирати тільки з кінця 2017 року. Але ми все одно можемо використовувати їх, щоб подивитися, чи став веб повільнішим за останні два з половиною роки. Варто врахувати, що на відміну від HTTP Archive, CrUX вивчає весь домен, а не тільки головні сторінки. В якості даних ми будемо розглядати 75-й перцентиль: це означає, що для 75% користувачів сторінки завантажуються з цією швидкістю або швидше. (Я беру середнє, а не медіанне значення серед кількох веб-сайтів, що не зовсім правильно.)

Час завантаження сторінок в США

Дані CrUX по США не демонструють погіршення швидкості сторінок. Метрика onLoad показує невелике поліпшення, ймовірно, викликане збільшенням пропускної спроможності. А може бути, тепер більше дій відбувається після первинного завантаження сторінки.

Метрики paint виглядають досить стабільними. Largest Contentful Paint (час завантаження основного контенту) - це нова метрика, яка збирається тільки з середини 2019 року.

Решта світу

Тенденція зниження метрики onLoad в США відповідає і світовими даними. Однак існують значні відмінності в часі завантаження сторінок в різних країнах, наприклад, час onLoad в Індії майже вдвічі вище, ніж в Південній Кореї.

Ми можемо використовувати дані CrUX, щоб ширше зрозуміти дані HTTP Archive. У січні 2020 року HTTP Archive повідомив, що медіанний (50-й перцентиль) час завантаження на підставі синтетичних даних 18,7с. На противагу йому CrUX вважає, що час завантаження становить всього 5,8с - і це 75-й перцентиль. (Варто врахувати, що світові значення (Global) взяті просто як середнє і не зважені по населенню.)

Моделювання часу завантаження сторінок

Ми можемо створити теоретичну модель того, як зміни пристроїв, мереж і веб-сайтів впливають на загальну швидкість. Модель буде не ідеальною, але, сподіваємося, дасть нам якесь розуміння.

Теоретичний час на скачування сторінок

Вага сторінок з часом збільшувався, але те саме відбувалося і з пропускною спроможністю. Також знижувався час проходження сигналу туди і назад. Завантаження файлу розміром з медіанний мобільний веб-сайт в 2013 році зайняло б 1,7 с. Якщо швидкість нашого з'єднання з того часу не змінилася, то сьогодні на це було потрібно 4,4с. Але при сучасній середній швидкості підключення на це потрібно всього 0,9 с.

На практиці, веб-сайт не буде складатися з єдиного запиту, а на швидкість завантаження сторінки будуть впливати і інші фактори, наприклад, швидкість обробки процесором і затримка сервера. Час onLoad за даними HTTP Archive в 2-3 разів вище цієї нижньої межі. Але ми все одно можемо використовувати це як показник того, що зниження затримок і збільшення пропускної здатності в цілому допомогли веб-сайтам завантажуватися швидше. (Я починаю відлік з 2013, а не з 2011 року, тому що метрика ваги сторінки HTTP Archive початку вимірюватися одноманітно тільки з цього часу.)

Процесор

Я не зовсім розумію, як підходити до цього параметру, але зроблю деякі припущення. У людини, що використовував в 2013 році Galaxy S4, а тепер використовує Galaxy S10, обчислювальна потужність процесора збільшилася в п'ять разів. Припустимо, що з тих пір браузери стали в чотири рази ефективніше. Якщо безпосередньо перемножити ці два числа, то ми отримаємо поліпшення в 20 разів. З 2013 року вага JavaScript на сторінці збільшився в 3,7 рази, з 107 КБ до 392 КБ. Ймовірно, з тих пір покращилися і мініфікація зі стисненням, тому той же обсяг коду на JavaScript вміщується тепер в меншу кількість байтів. Давайте округлимо цей коефіцієнт до шести. Уявімо, що вага JavaScript на сторінці пропорційний часу виконання JavaScript. В результаті ми все одно отримаємо підвищення швидкості в 3,3 рази.

Висновок

Сьогодні веб-сайти виконують більше коду і вони в рази об'ємніші, ніж веб-сайти десятирічної давностя. Проте, я не вважаю, що мобільний веб в сприйнятті користувачів в цілому став повільнішим. У той же час, тепер мобільним Інтернетом користується набагато більше людей. Це погіршує загальні показники сприйняття швидкості інтернету.

Обчислювальна потужність мобільних пристроїв наздоганяє потужність настільних пристроїв, те ж саме відбувається і з пропускною здатністю мереж. У той же час, з'являються нові дешевші пристрої бюджетного рівня. Ці дані можна розглядати під двома кутами. З одного боку, веб поступово стає швидше. З іншого боку, покращення мереж і пристроїв являє собою упущену можливість більш значного підвищення продуктивності.

Джерело: debugbear.com