5G — технология, видимо, замедлит веб

Технология 5G — это уже реальность. Соответствующий значок начинает появляться в верхних частях экранов телефонов по всему миру. Если вы подключены к 5G-сети, то вы могли заметить, что такая сеть не кажется намного более быстрой, чем 4G-сеть. Я вполне это понимаю. Говорят, что сейчас, в дни становления новых сетей, настоящим 5G-скоростям мешает процесс миграции инфраструктуры. Но после того как технология 5G, во всех смыслах, повзрослеет, ожидается, что скорость сетей очень сильно возрастёт. Так, по некоторым сведениям, средние скорости загрузки данных в 5G-сетях в 2019 году могут составить от 100 Мбит до 1 Гбит в секунду.

Это означает, что можно будет загрузить всю дискографию Friends, а потом — торжественно перетащить её мышью в корзину, сделав это примерно за то же время, которое сейчас занимает загрузка обычной веб-страницы. Я не пытаюсь сейчас выходить на какие-то конкретные цифры. Я говорю лишь о том, что, возможно, работа в 5G сетях может выглядеть именно так. Такое будущее иначе как «прекрасным» и не назовёшь.

Да, не стоит забывать о том, что в 5G-сетях улучшится не только полоса пропускания. Ожидается и уменьшение сетевых задержек. А задержки — это одно из давно и печально известных узких мест производительности веба. Снижение задержек означает, что время, которое тратится на подключение к веб-сайту, может, по ощущениям пользователей, упасть практически до нуля. Опять же — выглядит это просто замечательно.

Получается, что качество сетей уже очень скоро значительно вырастет. И это, похоже, должно решить проблемы скорости современного веба. Так?

Должно-то оно должно, но автор материала, перевод которого мы сегодня публикуем, не ждёт, что 5G действительно ускорит веб. Как минимум — ускорит, но далеко не сразу. Он полагает, что если современные тренды веб-разработки не изменятся, то широкое внедрение 5G-сетей приведёт к тому, что среднестатистическому пользователю будет работаться в вебе не лучше, а хуже.

Хуже? Да как же это?

Более быстрые сети должны решить проблемы скорости загрузки сайтов, но до сих пор рост сетевых скоростей непреднамеренно оказывал на веб негативное воздействие. Интересно — почему? Дело тут в следующем: исторически сложилось так, что ускорение сетей позволяет разработчикам отправлять посетителям сайтов больше кода. В частности — речь идёт о JavaScript-коде.

С 2011 года по 2019 год уровень 4G-покрытия в мире вырос с 5% до 79%. За то же самое время медианное значение среднего объёма JavaScript-кода, передаваемого на мобильные устройства, выросло на 611% — c 52 Кб, до 372.9 Кб. Конечно, объёмы JS-кода выросли не только из-за роста скорости сетей. Этому способствовали и многие другие факторы. Сайты, безусловно, за это время стали гораздо более интерактивными. Это вполне могло привести к росту объёма их JS-составляющей. Кроме того, распространение получил отзывчивый дизайн. В результате множество сайтов начало отправлять один и тот же JavaScript-бандл на все устройства, на которых эти сайты просматривают. Правда, тут стоит уточнить то, что настольные сайты в 2011 году отправляли клиентам, в среднем, лишь на 50 Кб больше JS-кода, чем их мобильные коллеги. В целом же можно отметить, что шаблоны разработки интерфейсов с 2011 года изменились не слишком сильно. Например, веб-сайт Boston Globe, в разработке которого мы участвовали, создан с большим вниманием к удобству работы с ним на самых разных устройствах. Он запущен в 2010 году. Интерфейсы новостных сайтов до сих пор устроены практически точно так же. И наконец, вышеозначенный тренд, по последним данным, продолжается. А именно, за последнюю пару лет средний объём JS-кода, передаваемого клиентам, вырос более чем на 50%.

А теперь, прежде чем мы начнём винить во всём JavaScript-фреймворки, надо отметить, что возникает ощущение того, что рост объёмов JS-кода не полностью привязан к возможностям интерфейсов сайтов. Тут следует обратить внимание на то, что большая часть роста объёма кода связана с ростом использования сторонних скриптов на 706%. Несомненно, запросы на загрузку сторонних скриптов могут относиться к JS-фреймворкам, но чаще всего это — нечто иное. Это может быть код трекеров, A/B-библиотек, скриптов для персонализации. Это может быть реклама, чат-боты… И всё это, в свою очередь, делает запросы на загрузку дополнительных скриптов, а эти дополнительные скрипты ещё что-то загружают. Перед нами, так сказать, безудержное веселье. Но у такого веселья обычно бывают нехорошие последствия.

Итак, по мере того, как росла пропускная способность сетей, увеличивался и объём JS-кода, используемого на веб-страницах. Но и тут можно подумать, что если весь этот код загружается достаточно быстро, то рост его объёма — явление сравнительно безобидное. Правда это, к сожалению, не так. Если сравнить JavaScript-код с другими видами ресурсов, используемых при создании веб-страниц, то оказывается, что JavaScript — это очень дорогое удовольствие. Цена JavaScript гораздо выше, чем цена других материалов.

«На моём телефоне всё выглядит хорошо»

Удобства разработчиков очень легко могут завести веб-индустрию на кривую дорожку.

На среднем мобильном устройстве, из таких, которые всё ещё используются, разбор 200 Кб JavaScript-кода (сжатого для ускорения передачи) может занять //medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4" style="color: rgb(153, 34, 152); font-family: -apple-system, BlinkMacSystemFont, Arial, sans-serif; font-size: 16px;">6 секунд или даже больше. И это — уже после того, как код будет загружен по сети. Прежде чем вы решите, что 200 Кб — это нереально много для некоего сайта, предлагаю вспомнить о том, что просмотр современного сайта означает, что пользователь, в среднем, загрузит почти в два раза больший объём JS-кода. При этом в процессе разбора данного кода страница может быть видимой, но не реагирующей на воздействия. А может быть и так, что страница будет совершенно пустой (это — если скрипт к странице подключён с использованием традиционного подхода, то есть так, что его обработка блокирует рендеринг страницы). Недействующая страница и пустая страница — это одинаково плохо, но особое беспокойство вызывает то, что многие из тех, кто занят веб-разработкой, сами подобных проблем даже не замечают.

Среднее мобильное устройство — это не новейший дорогущий iPhone с тремя камерами. Среднее устройство, даже в США, это телефон из разряда бестселлеров, который стоит порядка $130. Это вполне может быть и iPhone, но — далеко не самый новый. Скорее всего, это будет Android-телефон среднего уровня, содержащий сравнительно слабую аппаратную начинку. Да что там говорить — вот телефоны-бестселлеры с Amazon. В момент написания этого материала на третьем месте среди них было устройство стоимостью $59.

Если люди с такими телефонами даже и будут пользоваться новыми быстрыми сетями, то их устройства окажутся буквально «задушенными» теми объёмами кода, которые приходится обрабатывать для показа веб-страниц. А это сведёт на нет те потенциальные улучшения в скорости загрузки материалов, которые способны дать 5G-сети.

Как быть тем, у кого нет 5G-подключений?

Организация распространения 5G-сетей требует больших инфраструктурных изменений. Первые кандидаты на появление таких сетей — это развитые страны и высокотехнологичные города. В развивающихся странах и в сельской местности эти сети вряд ли появятся так же быстро. Это означает, что люди, живущие там, где нет 5G-сетей, в современных условиях вполне могут не только работать с веб-страницами на не самых быстрых устройствах, но и загружать код этих страниц, объём которого всё растёт, пользуясь старыми 3G и 2G-сетями. Таким людям от введения в строй 5G-сетей будет плохо вдвойне.

Что делать?

Ответственность за решение этой проблемы лежит на индустрии веб-разработки, на каждом из нас. Конечно, нам нужно улучшать приоритизацию доставки клиентам содержимого веб-страниц, но нам надо ещё и прекратить включать в состав проектов столь огромные объёмы JavaScript-кода. Необходимо анализировать используемые скрипты, регулярно изучать зависимости проектов. Многие из таких зависимостей могут оказаться заброшенными их разработчиками, или представлять собой проекты с недолгим сроком жизни. Возможно, мы даже можем воспользоваться тут опытом The Telegraph, удалив старые сторонние скрипты и посмотрев, пожалуется ли кто-нибудь на какие-либо проблемы. Мы можем изучить нашу зависимость от отслеживания действий пользователя и от персонализации рекламы. Возможно, мы, так же, как The New York Times, выясним, что показ пользователям обычных неперсонализированных рекламных объявлений может увеличить наш доход от рекламы. А если так и будет — стоит избавиться от ставших ненужными рекламных скриптов. Можно, для наблюдения за тем, чтобы показатели производительности веб-проектов не выходили бы за некие границы, пользоваться инструментами вроде Calibre или SpeedCurve. При этом стоит стремиться к тому, чтобы о производительности проекта заботился бы каждый, кто имеет к нему отношение, чтобы каждый знал бы о том, как его действие или бездействие влияет на проект.

Самое главное — нам нужно сделать так, чтобы у менеджеров, владельцев сайтов, разработчиков, дизайнеров, да абсолютно у всех, был бы доступ к телефонам среднего класса, и была бы возможность регулярно тестировать наши сайты на таких телефонах. А ещё лучше — если подобные телефоны будут подключены к предоплаченному или ограниченному тарифному плану. Это позволит узнать о том, сколько времени понадобится на то, чтобы выбрать лимит трафика в мире 5G-сетей. Если все, имеющие отношение к некоему сайту, будут знать о том, как его производительность выглядит в реальном мире, это благотворно отразится на всех посетителях сайта. В том числе, кстати, на тех, кто пользуется быстрыми современными телефонами.

Повышение качества сетей означает, что у сообщества разработчиков есть огромная возможность улучшить создаваемое ими веб-пространство. Воспользуются ли они этой возможностью или нет — зависит только от них.

Есть мнение, что тем жителям глубинки, до которых не дошёл 4G он уже и не дойдёт, а до многих из них 5G дойдёт раньше чем до тех, до кого недавно дошёл 4G