- PVSM.RU - https://www.pvsm.ru -
В недавней истории на Hacker News утверждалось, что скорости веб-страниц не повышаются даже с увеличением скоростей Интернета.
В своей статье я объясню, почему из исходных данных такого вывода сделать нельзя.
Также мы рассмотрим изменения, произошедшие с устройствами и вебом на протяжении предыдущих десяти лет, и расскажем, как повлияли эти измерения на скорость веба.
Этот график из статьи Nielsen Norman Group [1] даёт нам понять, что увеличение пропускной способности мобильных сетей не привело к ускорению загрузки страниц.
Однако скорость подключения, использованная HTTP Archive, не увеличилась за это время.
Вместо этого она понизилась в 2013 году, перейдя с WiFi на эмулируемое 3G-подключение [2].
C 2013 года метрика onLoad увеличилась на 55%, с 12,7 с до 19,7 с. Если вы купили телефон в 2013 году и с тех пор подключались к Интернету через 3G, то веб стал для вас медленнее.
Прежде чем рассказать о том, как изменились устройства и веб за последние десять лет, вот несколько примечаний о том, как нужно воспринимать эти данные.
Событие load
передаётся страницей, когда скачаны все ресурсы страницы, такие как скрипты и изображения.
Если шапка страницы отрендерилась быстро, но страница также загружает ещё 20 изображений ниже, то метрика onLoad даст нам понять, что страница медленная.
Другая страница может изначально и не рендерить ничего полезного, а только начинать загружать дополнительные ресурсы и рендерить контент уже сильно после события onLoad. Тем не менее, такая страница будет казаться быстрой.
Поэтому onLoad не очень подходит для измерения того, воспринимает ли пользователь страницу как быструю.
Зачем вообще смотреть на эту метрику? Потому что она использовалась долгое время и HTTP Archive отслеживал её с 2010 года. Более новые метрики, например, First Contentful Paint [3] или Time to Interactive, были добавлены в HTTP Archive только в 2017 году.
Увеличение пропускной способности ускорит загрузку страницы, только если пропускная способность оказывается на каком-то этапе узким местом. Оно не поможет, если вы сидите на гигабитном подключении, а время передачи сигнала в обе стороны по сети равно одной секунде.
Однако эмулируемое HTTP Archive 3G-подключение на 1,6 Мбит/с очень медленное, поэтому стоит ожидать значительного повышения скорости при увеличении пропускной способности. Среднестатистический веб-сайт скачивает в 2020 году 1,7 МБ данных, то есть при скорости подключения HTTP Archive на скачку потребуется не менее 9 секунд.
В этой статье я буду много говорить о «среднестатистическом веб-сайте». Стоит заметить, что HTTP Archive собирает данные только на главных страницах, а не на страницах глубже в иерархии сайта. Также со временем вырос корпус тестируемых доменов.
Тесты не всегда выполнялись на одном устройстве. Изначально использовался физический iPhone 4, а сегодня тесты выполняются на эмулируемом Android-устройстве.
В этой статье мы рассматриваем медианные метрические значения. Если большинство сайтов работает быстро, но один из пяти веб-сайтов затормаживает телефон на 20 секунд, то мы не сможем повысить эту метрику.
В этой статье мы рассмотрим скорость на мобильных устройствах в США. Однако если посмотреть на данные настольных компьютеров из исходной статьи, то стоит заметить, что в 2013 году тестовая пропускная способность увеличилась, а задержка уменьшилась.
Давайте рассмотрим четыре фактора:
На этом графике показана средняя пропускная способность мобильных сетей США в разные годы по данным различных источников. Она увеличилась с 1 Мбит/с до примерно 30 Мбит/с.
(Я не очень тщательно собирал эти данные. Например, я не всегда разбирался, совпадает ли дата сбора данных с датой их публикации. Мои источники можно найти здесь [4].)
По этому параметру данные найти было сложнее, но результаты показывают, что задержка снизилась примерно с 200 мс (2011 год) до 50 мс (2020 год).
Мне не удалось найти данные по средним скоростям мобильных устройств в США. Однако Алекс Рассел [5] и Surma [6] опубликовали график [7] рейтинга GeekBench 4 вместе с годами выпуска различных телефонов.
Даже бюджетные телефоны стали в 4 раза быстрее, а iPhone стал мощнее в 20 раз.
За последние десять лет была проделана большая работа над совершенствованием браузеров. JavaScript стал ещё более важной частью веба, поэтому многие улучшения сосредоточены в этой области.
Судя по этому графику [8] из блога V8, потребление ресурсов процессора на одну страницу сократилось в четыре раза.
Улучшилась и работа браузеров с сетью. Например, после введения в 2015 году HTTP/2 64% запросов обрабатывается по HTTP/2.
Давайте взглянем на данные из HTTP Archive, чтобы понять, как поменялись веб-сайты.
За промежуток времени с 2013 по 2020 год вес [9] страницы для мобильных увеличился на 337%. В основном это вызвано увеличением количества изображений и кода на JavaScript.
Объём других ресурсов тоже сильно увеличился — подозреваю, что в основном это видео.
График начинается с 2013 года, потому что в октябре 2012 года HTTP Archive изменил методологию измерений. До этого вес страницы недооценивался, потому что тест прекращался после срабатывания события загрузки страницы, даже если после него загружались другие данные.
Если несмотря на ускорение мобильных сетей страницы становятся медленнее, то наиболее вероятным виновником этого будет JavaScript. К сожалению, HTTP Archive начал собирать эти данные только в конце 2017 года, и с тех пор они кажутся стабильными.
Снижение в середине 2018 года, вероятно, связано с изменением корпуса тестируемых URL.
Обратите внимание, что абсолютная длительность исполнения (0,5 с) меньше, чем мы обычно встречаем в инструментах наподобие Lighthouse. Такие инструменты обычно замедляют исполнение JavaScript для эмулирования мобильного устройства, но в тестах HTTP Archive эта система была неисправной [10]. Поэтому хотя это значение может быть реалистичным для телефонов среднего ценового диапазона, обычно считается, что бюджетные телефоны примерно в четыре раза медленнее.
Стал ли веб медленнее? Вообще, это зависит от вашего устройства, подключения к сети и самых часто посещаемых веб-сайтов.
Нам бы потребовалось измерить реальные данные скорости, чтобы получить распределение, демонстрирующее, как изменяется восприятие веба с течением времени разными пользователями. Кроме того, остаётся вопрос, должен ли опыт того, кто открывает тысячи страниц в день учитываться так же, как опыт того, кто только раз в неделю посещает Facebook?
У меня нет подробных данных по отдельным пользователям, но мы можем рассмотреть этот вопрос под несколькими разными углами:
Также я пробовал скачивать старые версии страниц с archive.org и тестировать их с помощью Lighthouse, но не смог в приемлемые сроки получить значимые данные. Например, иногда в архиве страницы отсутствуют изображения.
Большим ограничением данных 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 раза.
Сегодня веб-сайты исполняют больше кода и они в разы объёмнее, чем веб-сайты десять лет назад. Тем не менее, я не считаю, что мобильный веб в восприятии пользователей в целом стал медленнее.
В то же время, теперь мобильным вебом пользуется гораздо больше людей [12]. Это ухудшает общие показатели восприятия скорости веба.
Вычислительная мощь мобильных устройств догоняет мощь настольных устройств, то же самое происходит и с пропускной способностью сетей. В то же время, появляются новые более дешёвые устройства бюджетного уровня.
Эти данные можно рассматривать под двумя углами. С одной стороны, веб постепенно становится быстрее. С другой стороны, совершествование сетей и устройств представляет собой упущенную возможность более значительного повышения производительности.
VDSina предлагает недорогие серверы [13] с посуточной оплатой, каждый сервер подключён к интернет-каналу в 500 Мегабит и бесплатно защищён от DDoS-атак!
Автор: Mikhail
Источник [14]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/news/356944
Ссылки в тексте:
[1] статьи Nielsen Norman Group: https://www.nngroup.com/articles/the-need-for-speed/
[2] перейдя с WiFi на эмулируемое 3G-подключение: https://httparchive.org/faq#what-changes-have-been-made-to-the-test-environment-that-might-affect-the-data
[3] First Contentful Paint: https://www.debugbear.com/docs/metrics/first-contentful-paint
[4] здесь: https://docs.google.com/spreadsheets/d/1ifZ_ngADpT3YzezNQLpXKCsr74-BvaBJUkYm6PGpv1g/edit?usp=sharing
[5] Алекс Рассел: https://infrequently.org/
[6] Surma: https://surma.dev/
[7] график: https://twitter.com/slightlylate/status/1233275220275818498
[8] этому графику: https://v8.dev/blog/10-years
[9] вес: https://httparchive.org/reports/page-weight
[10] неисправной: https://almanac.httparchive.org/en/2019/methodology#lighthouse
[11] Chrome UX Report (CrUX): https://developers.google.com/web/tools/chrome-user-experience-report
[12] теперь мобильным вебом пользуется гораздо больше людей: https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet
[13] недорогие серверы: https://vdsina.ru/cloud-servers?partner=habr98
[14] Источник: https://habr.com/ru/post/519006/?utm_source=habrahabr&utm_medium=rss&utm_campaign=519006
Нажмите здесь для печати.