Я использовал Интернет в течение дня с бюджетом в 50 МБ

Эта статья является частью серии, в которой я пытаюсь использовать Интернет с различными ограничениями, представляя определенную демографическую группу пользователей. Я надеюсь привлечь внимание к трудностям, с которыми сталкиваются реальные люди, которых можно избежать, если мы проектируем и разрабатываем с учетом их потребностей.

В прошлый раз я просматривал веб-страницы в течение дня с помощью Internet Explorer 8. На этот раз я просматривал веб-страницы в течение дня с бюджетом в 50 МБ.

Почему 50 МБ?

Многим из нас посчастливилось пользоваться мобильными тарифными планами, которые позволяют передавать несколько гигабайт данных в месяц. В противном случае мы обычно можем подключиться к домашним или общедоступным сетям Wi-Fi, которые имеют быстрое широкополосное соединение и фактически имеют неограниченный объем данных.

Но есть части мира, где мобильные данные непомерно дороги, а широкополосная инфраструктура практически отсутствует.

Люди часто покупают пакеты данных размером всего в десятки мегабайт за раз, что делает гигабайт относительно большим и, следовательно, дорогим объемом данных для покупки.
— Дэн Хоудл, аналитик потребительских телекоммуникаций Cable.co.uk.

Насколько дорого мы говорим?

Стоимость мобильных данных

Исследование, проведенное Cable.co.uk в 2018 году, показало, что Зимбабве была самой дорогой страной в мире для мобильных данных, где 1 ГБ стоил в среднем 75,20 долларов США, в диапазоне от 12,50 до 138,46 долларов США. Огромный диапазон цен связан с тем, что меньшие объемы данных очень дороги, и они становятся пропорционально дешевле, чем больше тарифный план, который вы используете. Вы можете прочитать методологию исследования для получения дополнительной информации.

Зимбабве ни в коем случае не уникальна. На очереди Экваториальная Гвинея, острова Святой Елены и Фолклендские острова, где 1 ГБ данных стоит 65,83, 55,47 и 47,39 долларов США соответственно. В этих странах, как правило, сочетается плохая техническая инфраструктура и низкий уровень внедрения, а это означает, что доставка данных является дорогостоящей и не позволяет снизить затраты за счет эффекта масштаба.

Данные дороги в некоторых частях Европы тоже. Гигабайт данных в Греции обойдется вам в 32,71 доллара; в Швейцарии — 20,22 доллара. Для сравнения, такой же объем данных стоит 6,66 доллара в Великобритании или 12,37 доллара в США. На другом конце шкалы Индия является самым дешевым местом в мире для данных со средней стоимостью 0,26 доллара. Кыргызстан, Казахстан и Украина следуют по цене 0,27, 0,49 и 0,51 доллара за ГБ соответственно.

Скорость мобильных сетей также значительно различается между странами. Удивительно, но пользователи получают более высокие скорости по мобильной сети, чем по Wi-Fi, по крайней мере, в 30 странах мира, включая Австралию и Францию. В Южной Корее самая высокая скорость мобильной загрузки, в среднем 52,4 Мбит/с, а в Ираке самая медленная, в среднем 1,6 Мбит/с для загрузки и 0,7 Мбит/с для загрузки. США занимают 40-е место в мире по скорости загрузки мобильных устройств (около 34 Мбит/с) и рискуют отстать еще больше по мере продвижения мира к 5G.

Что касается типа подключения к мобильной сети, то 84,7% пользовательских подключений в Великобритании используют 4G, по сравнению с 93% в США и 97,5% в Южной Корее. Это сопоставимо с менее чем 50% в Узбекистане и менее чем 60% в Алжире, Эквадоре, Непале и Ираке.

Стоимость широкополосных данных

Между тем, исследование стоимости широкополосного доступа в 2018 году показывает, что широкополосное соединение в Нигере стоит 263 доллара США «за мегабит в месяц». Эту метрику немного сложно понять, поэтому вот пример: если средняя стоимость пакетов широкополосного доступа в стране составляет 22 доллара, а средняя скорость загрузки, предлагаемая пакетами, составляет 10 Мбит/с, то стоимость «за мегабит в месяц» будет быть $ 2,20.

Это интересный показатель, который подтверждает, что скорость широкополосного доступа является таким же важным фактором, как и ограничение данных. Стоимость в 263 доллара предполагает сочетание очень медленного и очень дорогого широкополосного доступа. Для справки: 1,19 доллара в Великобритании и 1,26 доллара в США.

Что, пожалуй, легче понять, так это среднюю стоимость широкополосного пакета. Обратите внимание, что в этом исследовании искали самые дешевые предлагаемые пакеты широкополосного доступа, игнорируя, имеют ли эти пакеты ограничение на передачу данных, поэтому предоставляет полезную приблизительную цифру, а не стоимость данных как таковых.

Только по стоимости пакета в Мавритании самая дорогая широкополосная связь в мире, в среднем 768,16 долларов (от 307,26 до 1368,72 долларов). Эта огромная стоимость включает в себя строительство физических линий к собственности, поскольку в Мавритании их уже мало. При скорости 0,7 Мбит/с Мавритания также имеет одну из самых медленных широкополосных сетей в мире.

Тайвань имеет самую быструю широкополосную связь в мире со средней скоростью 85 Мбит/с. В Йемене самый медленный, 0,38 Мбит/с. Но даже в странах с хорошо развитой широкополосной инфраструктурой есть так называемые «не-споты». Соединенное Королевство занимает 34-е место из 207 стран по скорости широкополосного доступа, но в июле 2019 года в Великобритании все еще была школа без широкополосного доступа.

Средняя стоимость пакета широкополосного доступа в Великобритании составляет 39,58 долларов США, а в США — 67,69 долларов США. Самый дешевый средний показатель в мире — Украина, всего 5 долларов, хотя самая дешевая широкополосная связь из всех была найдена в Кыргызстане (1,27 доллара против среднего показателя по стране 108,22 доллара).

Зимбабве была самой дорогой страной для мобильных данных, и статистика ее широкополосного доступа не намного лучше: средняя стоимость составляет 128,71 доллара, а стоимость «за мегабит в месяц» - 6,89 доллара.

Абсолютная стоимость против стоимости в реальном выражении

Все затраты, описанные до сих пор, являются абсолютными затратами в долларах США и основаны на обменных курсах на момент проведения исследования. Эти расходы не учитывались в стоимости жизни, а это означает, что для многих стран стоимость в реальном выражении намного выше.

Я собираюсь ограничить свой просмотр сегодня до 50 МБ, что в Зимбабве будет стоить около 3,67 долларов США по тарифу на мобильные данные. Это может показаться не таким уж большим, но учителя в Зимбабве бастовали в этом году, потому что их зарплата упала всего до 2,50 долларов в день.

Для сравнения, 3,67 доллара — это примерно половина минимальной заработной платы в 7,25 доллара в США. Как зимбабвийцу, мне пришлось бы работать около полутора дней, чтобы заработать деньги на покупку этих 50 МБ данных, по сравнению с получасом в США. Сравнивать стоимость жизни в разных странах непросто, но, учитывая одну только заработную плату, стоимость 50 МБ данных в Зимбабве в размере 3,67 доллара будет равна 52 долларам для американца с минимальной заработной платой.

Настройка эксперимента

Я запустил Chrome и открыл инструменты разработчика, где я переключил сеть на медленное соединение 3G. Я хотел смоделировать медленное соединение, подобное тому, с которым сталкиваются пользователи в Узбекистане, чтобы посмотреть, какой опыт дадут мне веб-сайты. Я также дросселировал свой процессор, чтобы имитировать работу на более низком устройстве.

Я установил ModHeader и установил заголовок «Save-Data», чтобы веб-сайты знали, что я хочу свести к минимуму использование данных. Это также заголовок, установленный Chrome для «облегченного режима» Android, о котором я расскажу подробнее позже.

Я скачал TripMode; приложение для Mac, которое дает вам контроль над тем, какие приложения на вашем Mac могут получить доступ к Интернету. Доступ в Интернет любого другого приложения автоматически блокируется.

Как далеко, по моим прогнозам, уйдет мой бюджет в 50 МБ? Учитывая, что средний вес веб-страницы составляет почти 1,7 МБ, это говорит о том, что в моем бюджете есть около 29 страниц, хотя, возможно, несколько больше, если я смогу оставаться на тех же сайтах и ​​использовать кэширование браузера.

На протяжении всего эксперимента я буду предлагать советы по повышению производительности, чтобы ускорить первую содержательную отрисовку и воспринимаемое время загрузки страницы. Некоторые из этих советов могут не влиять на объем данных, передаваемых напрямую , но обычно предполагают отсрочку загрузки менее важных ресурсов, что при медленном соединении может означать, что ресурсы никогда не загружаются, а данные сохраняются.

Эксперимент

Без дальнейших церемоний я загрузил google.com, использовав 402 КБ своего бюджета и потратив 0,03 доллара США (около 1% моего бюджета Зимбабве).

В целом, неплохой размер страницы, но мне было интересно, откуда берутся эти 24 сетевых запроса и можно ли сделать страницу светлее.

Главная страница Google — DOM

Глядя на разметку страницы, внешних таблиц стилей нет — весь CSS встроен.

Совет по производительности № 1: встроенный критический CSS

Это хорошо для производительности, так как избавляет браузер от необходимости делать дополнительный сетевой запрос, чтобы получить внешнюю таблицу стилей, поэтому стили могут быть проанализированы и немедленно применены для первой отрисовки содержимого. Здесь приходится идти на компромисс, так как внешние таблицы стилей можно кэшировать, а встроенные — нет (если только вы не разбираетесь в JavaScript).

Общий совет заключается в том, чтобы ваши важные стили (все, что находится выше сгиба) были встроенными, а остальные стили — внешними и загружались асинхронно. Асинхронная загрузка CSS может быть достигнута с помощью одной удивительно умной строки HTML:

 <link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

Инструменты разработчика показывают преттифицированную версию DOM. Если вы хотите увидеть, что на самом деле было загружено в браузер, перейдите на вкладку «Источники» и найдите документ.

Вы можете видеть, что здесь МНОГО встроенного JavaScript. Стоит отметить, что он был углифифицирован, а не просто минимизирован.

Совет по повышению эффективности № 2: уменьшите и украсьте свои активы

Минификация удаляет ненужные пробелы и символы, но на самом деле упрощает код, делая его короче. Контрольным признаком является то, что код содержит короткие имена переменных, сгенерированные машиной, а не нетронутый исходный код. Это хорошо, так как это означает, что скрипт меньше и быстрее загружается.

Даже в этом случае встроенные скрипты занимают примерно 120 КБ из ресурса страницы в 210 КБ (примерно половина размера 60 КБ в сжатом виде). Кроме того, есть пять внешних файлов JavaScript размером 291 КБ из загруженных 402 КБ:

Это означает, что на долю JavaScript приходится около 80 процентов общего веса страницы.

Это не бесполезный JavaScript; Google должен иметь некоторые из них, чтобы отображать предложения по мере ввода. Но я подозреваю, что во многом это код отслеживания и настройка рекламы.

Для сравнения я отключил JavaScript и перезагрузил страницу:

Версия поиска Google с отключенным JS весит всего 102 КБ, а не 402 КБ. Хотя Google не может предлагать автоподсказки в этих условиях, сайт по-прежнему работает, и я только что сократил использование данных до четверти того, что было раньше. Если бы мне действительно пришлось ограничить использование данных в долгосрочной перспективе, я бы первым делом отключил JavaScript. Это не так плохо, как кажется.

Совет по повышению эффективности № 3: меньше значит больше

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

• Прежде чем добавлять какие-либо новые функции, есть ли у вас бюджет производительности?
• Прежде чем добавлять JavaScript на свой сайт, можно ли реализовать вашу функцию с помощью простого HTML? (Например, проверка формы HTML5).
• Прежде чем добавить большую библиотеку JavaScript или CSS в свое приложение, используйте что-то вроде bundlephobia.com, чтобы измерить, насколько она велика. Стоит ли удобство веса? Можете ли вы сделать то же самое, используя ванильный код с гораздо меньшим размером данных?

Анализ информации о ресурсе

Здесь есть что распаковать, так что давайте приступим. У меня есть только 50 МБ для игры, так что я собираюсь доить каждый бит загрузки этой страницы. Приготовьтесь к краткому руководству по Chrome Devtools.

402 КБ передано, но 1,1 МБ ресурсов: что это на самом деле означает?

Это означает, что на самом деле было загружено 402 КБ контента, но в сжатом виде (с использованием алгоритма сжатия, такого как gzip или brotli). Затем браузеру пришлось проделать некоторую работу, чтобы распаковать его во что-то осмысленное. Общий размер распакованных данных составляет 1,1 МБ.

Эта распаковка платная — на распаковку ресурсов уходит несколько миллисекунд. Но это незначительные накладные расходы по сравнению с отправкой 1,1 МБ по сети.

Совет по повышению производительности № 4: сжимайте текстовые активы

Как правило, всегда сжимайте свои активы, используя что-то вроде gzip. Но не используйте сжатие для ваших изображений и других двоичных файлов — вы должны оптимизировать их заранее в исходном коде. Сжатие может на самом деле сделать их больше.

И, если возможно, избегайте сжатия файлов размером 1500 байт или меньше. Наименьший размер TCP-пакета составляет 1500 байт, поэтому, сжимая, скажем, до 800 байт, вы ничего не сохраняете, так как он по-прежнему передается в одном и том же байтовом пакете. Опять же, стоимость незначительна, но тратится некоторое время ЦП на сжатие на сервере и время ЦП на распаковку на клиенте.

Теперь вернемся к вкладке «Сеть» в Chrome: давайте углубимся в эти приоритеты. Обратите внимание, что ресурсы имеют приоритет от «самого высокого» до «самого низкого» — это лучшее предположение браузера относительно того, какие ресурсы являются более важными для загрузки. Чем выше приоритет, тем раньше браузер попытается загрузить ресурс.

Совет по производительности № 5: предоставьте браузеру подсказки о ресурсах

Браузер догадается, какие ресурсы имеют наивысший приоритет, но вы можете указать ресурс с помощью <link rel="preload"> , предписывая браузеру загрузить ресурс как можно скорее. Рекомендуется предварительно загрузить шрифты, логотипы и все остальное, что появляется в верхней части страницы.

Поговорим о кэшировании. Я собираюсь удерживать ALT и щелкнуть правой кнопкой мыши, чтобы изменить заголовки столбцов, чтобы разблокировать более сочную информацию. Мы собираемся проверить Cache-Control.

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

Совет по повышению производительности № 6. Установите заголовки управления кешем для всех кэшируемых ресурсов

Обратите внимание, что значение управления кэшем начинается с директивы public или private , за которой следует значение истечения срока действия (например max-age=31536000 ). Что означает директива и почему странное значение max-age ?

Значение 31536000 — это количество секунд в году и теоретическое максимальное значение, разрешенное спецификацией управления кэшем. Обычно это значение применяется ко всем статическим ресурсам и фактически означает, что «этот ресурс не изменится». На практике ни один браузер не будет кэшировать в течение всего года, но он будет кэшировать актив до тех пор, пока это имеет смысл.

Чтобы объяснить директиву public/private, мы должны объяснить два основных кеша, которые существуют за пределами сервера. Во-первых, это традиционный кеш браузера, где ресурс хранится на компьютере пользователя («клиент»). А еще есть кеш CDN, который находится между клиентом и сервером; ресурсы кэшируются на уровне CDN, чтобы CDN не запрашивала ресурс с исходного сервера снова и снова.

Директива Cache-Control для public позволяет кэшировать ресурс как в клиенте, так и в CDN. Значение private означает, что его может кэшировать только клиент; CDN не должен. Это последнее значение обычно используется для страниц или ресурсов, которые существуют за проверкой подлинности, где можно кэшировать на клиенте, но мы не хотели бы утечки частной информации, кэшируя ее в CDN и доставляя ее другим пользователям.

Одна вещь, которая привлекла мое внимание, заключалась в том, что логотип Google имеет элемент управления кешем «частный». Другие изображения на странице имеют общедоступный кеш, и я не знаю, почему логотип будет обрабатываться по-другому. Если у вас есть идеи, дайте мне знать в комментариях!

Я обновил страницу, и большинство ресурсов обслуживались из кеша, за исключением самой страницы, которая, как вы уже видели, является private, max-age=0 , что означает, что ее нельзя кэшировать. Это нормально для динамических веб-страниц, где важно, чтобы пользователь всегда получал самую последнюю страницу при обновлении.

Именно в этот момент я случайно щелкнул URL-адрес «Объяснение» в инструментах разработки, который привел меня к справочнику по сетевому анализу, что стоило мне около 5 МБ моего бюджета. Упс.

Документы Google для разработчиков

4,2 МБ этой новой страницы размером 5 МБ было занято изображениями; особенно SVG. Самый весомый из них был 186 КБ, что не особо много — их было очень много, и они все скачались сразу.

Эта загрузка страницы в 5 МБ составила 10% моего бюджета на сегодня. Пока я использовал 5,5 МБ, включая перезагрузку главной страницы Google без JavaScript, и потратил 0,40 доллара. Я даже не собирался открывать эту страницу.

Что было бы лучше для пользователя здесь?

Совет по повышению производительности № 7. Отложенная загрузка изображений

Обычно, если я случайно нажимал на ссылку, я нажимал кнопку «Назад» в своем браузере. Я бы не получил никакой выгоды от загрузки этих изображений — какая пустая трата 4,2 МБ!

Помимо видео, где вы обычно знаете, во что ввязываетесь, изображения, безусловно, являются самым большим виновником использования данных в Интернете. Исследование 500 лучших веб-сайтов мира показало, что изображения занимают до 53% среднего веса страницы. «Это означает, что они оказывают большое влияние на время загрузки страницы и, следовательно, на общую производительность».

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

Существует отличное руководство css-tricks.com по развертыванию ленивой загрузки изображений, которое предлагает хороший баланс между теми, у кого хорошее соединение, теми, у кого плохое соединение, и теми, у кого отключен JavaScript.

Если бы на этой странице была реализована отложенная загрузка в соответствии с приведенным выше руководством, каждый из 38 SVG по умолчанию был бы представлен изображением-заполнителем размером 1 КБ и загружался бы в представление только при прокрутке.

Совет № 8: используйте правильный формат для ваших изображений

Я подумал, что Google упустил трюк, не используя WebP, который представляет собой формат изображения, который на 26% меньше по размеру по сравнению с PNG (без потери качества) и на 25-34% меньше по размеру по сравнению с JPEG (и сопоставимое качество). Я подумал, что попробую преобразовать SVG в WebP.

Преобразование в WebP уменьшило размер одного из SVG со 186 КБ до всего 65 КБ, но на самом деле, глядя на изображения рядом, WebP получился зернистым:

Затем я попытался преобразовать один из PNG в WebP, который должен быть без потерь и должен быть меньше. Однако вывод WebP был *тяжелее* (127 КБ вместо 109 КБ)!

Это меня удивило. WebP не обязательно является серебряной пулей, как мы думаем, и даже Google не использовал его на этой странице.

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

Теперь вернемся к ДОМу. Я наткнулся на это:

Заметили ключевое слово async в скрипте Google Analytics?

Несмотря на то, что это одна из первых вещей в заголовке документа, ему был присвоен низкий приоритет, поскольку мы явно отказались от блокирующего запроса, используя ключевое слово async .

Блокирующий запрос — это запрос, который останавливает отображение страницы. Вызов <script> блокируется по умолчанию, останавливая синтаксический анализ HTML до тех пор, пока скрипт не будет загружен, скомпилирован и выполнен. Вот почему мы традиционно помещаем вызовы <script> в конец документа.

Совет по производительности № 9: избегайте написания блокирующих вызовов скриптов

Добавляя атрибут async к нашему тегу <script> , мы сообщаем браузеру не прекращать рендеринг страницы, а загружать скрипт в фоновом режиме. Если HTML-код все еще анализируется к моменту загрузки скрипта, анализ приостанавливается на время выполнения скрипта, а затем возобновляется. Это значительно лучше, чем блокировать рендеринг, как только встречается <script> .

Существует также атрибут defer , который немного отличается. <script defer> указывает браузеру отображать страницу, пока скрипт загружается в фоновом режиме, и даже если HTML-код все еще обрабатывается к моменту загрузки скрипта, скрипт должен дождаться, пока страница не будет визуализирована, прежде чем его можно будет выполнить. . Это делает скрипт полностью неблокирующим. Прочтите «Эффективная загрузка JavaScript с помощью отсрочки и асинхронности» для получения дополнительной информации.

Впрочем, хватит гуглить. Пришло время попробовать другой сайт. У меня еще осталось почти 45 МБ бюджета!

Амазонка

Домашняя страница Amazon загружена общим весом около 6 МБ. Одним из них было изображение размером 587 КБ, которое я даже не смог найти на странице. Это был PNG, предположительно, с четким текстом, но на фотографическом фоне — классическая комбинация, которая ужасна для производительности.

На самом деле, на вкладке сети было несколько изображений размером в несколько сотен килобайт, которые я не мог видеть на странице. Я подозреваю неправильную конфигурацию где-то на Amazon, но эти невидимые изображения вместе взятые поглотили как минимум 1 МБ моих данных.

Как насчет образа героя? Это основное изображение на странице, и оно весит всего 94 КБ, но его можно было бы уменьшить примерно на 15%, если бы оно было обрезано непосредственно вокруг текста и футболистов. Затем мы могли бы применить тот же цвет фона в CSS, что и на изображении. Это имеет дополнительное преимущество, заключающееся в том, что можно изменять размер до меньших экранов, сохраняя при этом удобочитаемость текста.

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

Оптимизация изображений обеспечила, безусловно, наиболее значительное сокращение объема данных. Вы можете доказать, что JavaScript больше влияет на общую производительность, но не на сокращение объема данных. Оптимизация или удаление изображений — это самый безопасный способ обеспечить гораздо более легкий опыт, и это основная оптимизация, на которую опирается Data Saver.
— Тим Кадлек, Осмысление страниц Chrome Lite

Чтобы быть справедливым по отношению к Amazon, если я изменю размер браузера на мобильный и обновлю страницу, сайт будет оптимизирован для мобильных устройств, а общий вес страницы составит всего 2,1 МБ.

Но это подводит меня к следующему пункту…

Совет по повышению производительности № 10: не делайте предположений о связях данных

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

Да, мы должны ожидать большую загрузку страницы, если наша область просмотра имеет «размер рабочего стола», поскольку изображения будут больше и лучше оптимизированы для экрана, чем более зернистое изображение для мобильных устройств. Но страница не должна быть на порядки больше.

Более того, я отправлял заголовок Save-Data со своим запросом. Этот заголовок явно указывает на предпочтение сокращенного использования данных, и я надеюсь, что в будущем больше веб-сайтов начнут обращать на это внимание.

Первоначальная загрузка «рабочего стола» могла составлять 6 МБ, но после того, как мы посидели и посмотрели ее в течение минуты, она поднялась до 8,6 МБ, поскольку ресурсы с более низким приоритетом и отслеживание событий начали действовать. Этот вес страницы включает почти 1,7 МБ минимизированного JavaScript. Я даже не хочу начинать смотреть на это.

Совет по повышению производительности № 11: используйте Web Workers для вашего JavaScript

Что будет хуже — 1,7 МБ JavaScript или 1,7 МБ изображений? Ответ — JavaScript: эти два актива не эквивалентны, когда речь идет о производительности.

Изображение в формате JPEG необходимо декодировать, растрировать и рисовать на экране. Пакет JavaScript необходимо загрузить, а затем проанализировать, скомпилировать, выполнить — и есть ряд других шагов, которые должен выполнить движок. Имейте в виду, что эти расходы не совсем эквивалентны.
— Эдди Османи, Стоимость JavaScript в 2018 г.

Если вам нужно отправить столько JavaScript, попробуйте поместить его в веб-воркер. Это удерживает большую часть JavaScript от основного потока, который теперь высвобождается для перерисовки пользовательского интерфейса, помогая вашей веб-странице оставаться отзывчивой на устройствах с низким энергопотреблением.

В моем бюджете сейчас около 15,5 МБ, и я потратил 1,14 доллара из своего бюджета на передачу данных в Зимбабве. Мне пришлось бы работать учителем полдня, чтобы заработать деньги и продвинуться так далеко.

Пинтерест

Я слышал хорошие отзывы о производительности Pinterest, поэтому решил проверить его.

Возможно, это не самое честное испытание; Меня перенаправили на страницу входа, на которой асинхронный процесс обнаружил, что я вошел в Facebook, и автоматически вошел в систему. Страница загружалась относительно быстро, но количество запросов росло по мере того, как загружалось все больше и больше контента.

Однако я видел, что при последующих загрузках страницы сервис-воркер выдавал большую часть контента, экономя примерно половину веса страницы:

Сайт Pinterest — это прогрессивное веб-приложение; он установил сервис-воркер для ручной обработки кэширования CSS и JS. Теперь я мог отключить свой WiFi и продолжать пользоваться сайтом (хотя и не очень полезно):

Совет по повышению производительности № 12: используйте сервис-воркеров для поддержки в автономном режиме

Разве не было бы здорово, если бы мне нужно было всего один раз загрузить веб-сайт по сети, и теперь я получаю всю необходимую мне информацию, даже если я не в сети?

Отличным примером может быть веб-сайт, который показывает прогноз погоды на неделю. Мне нужно загрузить эту страницу только один раз. Если я отключу свои мобильные данные и впоследствии вернусь на страницу в какой-то момент, она сможет предоставить мне последний известный контент. Если я снова подключусь к Интернету и загружу страницу, я получу более актуальный прогноз, но статические ресурсы, такие как CSS и изображения, по-прежнему должны обслуживаться локально сервис-воркером.

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

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

Сервисные работники действительно могут спасти положение, когда у вас ограниченный бюджет на передачу данных. Я не уверен, что опыт Pinterest был наиболее оптимальным с точки зрения использования данных — последующие страницы были около отметки 0,5 МБ даже на страницах с небольшим количеством изображений — но позволили вашему JavaScript обрабатывать запросы страниц для вас и сохранять те же элементы навигации на месте. может быть очень производительным. BBC управляет размером передачи всего 3,1 КБ для повторных посещений статей, которые могут отображаться через одностраничное приложение.

До сих пор один только Pinterest прожевал 14 МБ, что означает, что я потратил около 30 МБ своего бюджета, или 2,20 доллара (почти дневная заработная плата) моего бюджета Зимбабве.

Я должен быть осторожен с моими последними 20 МБ… но что в этом интересного?

Игровая площадка

Я выбрал этот, потому что в прошлом он чувствовал себя заметно вялым на моем мобильном телефоне, и я хотел разобраться в причинах этого. Конечно, загрузка домашней страницы потребляет 8,5 МБ данных.

6,5 МБ из этого ушло на автоматически воспроизводимое видео на полпути вниз по странице, которое, честно говоря, не загружалось, пока я не начал прокручивать. Тем не менее…

Я мог видеть только половину видео в окне просмотра — правая часть была обрезана. Это также длилось 30 секунд, и я готов поспорить, что большинство людей не будут сидеть и смотреть все это. Этот единственный актив увеличил размер страницы более чем в три раза.

Совет № 13: не загружайте видео заранее

Как правило, если основным способом коммуникации вашего сайта не является видео, не загружайте его заранее.

Если вы YouTube или Netflix, разумно предположить, что кто-то, заходящий на вашу страницу, захочет, чтобы видео автоматически загружалось и воспроизводилось. Ожидается, что видео проглотит некоторые данные, но это справедливый обмен за контент. Но если вы являетесь сайтом, основным носителем которого является текст и изображение — и вы просто предлагаете дополнительный видеоконтент — тогда не загружайте видео заранее.

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

Повторюсь: пользователям не нравится автовоспроизведение видео. Как разработчики, мы делаем это только потому, что наши менеджеры говорят нам об этом, а они говорят нам делать это только потому, что все самые крутые приложения делают это, а самые крутые приложения делают это только потому, что видеореклама приносит в 20–50 раз больше дохода, чем традиционные. Объявления. Google Chrome начал блокировать автоматическое воспроизведение видео для некоторых сайтов на основе личных предпочтений, поэтому, даже если вы разработаете свой сайт для автоматического воспроизведения видео, нет гарантии, что ваши пользователи получат то же самое.

Если мы согласимся с тем, что сделать видео опциональным (нажмите, чтобы воспроизвести) – это хорошая идея, мы можем сделать еще один шаг и сделать так, чтобы оно также загружалось по щелчку. Это означает издевательство над изображением-заполнителем видео с кнопкой воспроизведения над ним и загрузку видео только при нажатии кнопки воспроизведения. People on fast connections should notice no difference in buffer speed, and people on slow connections will appreciate how fast the rest of your site loaded because it didn't have to preload a large video file.

Anyway, back to Gamespot, where I was indeed forced to preload a large video file I ended up not watching. I then clicked through to a game review page that weighed another 8.5 MB, this time with 5.4 MB of video, before I even started scrolling down the page.

What was really galling was when I looked at what the video actually was. It was an advert for a Samsung TV! This advert cost me $0.40 of my Zimbabwe wages. Not only was it pre-loaded, but it also didn't end up playing anywhere as far as I'm aware, so I never actually saw it.

The 'real' video — the gameplay footage (in other words, the content) — wasn't actually loaded until I clicked on it. And that ploughed through my remaining data in seconds.

Вот и все. That's my 50 MB gone. I'll need to work another 1.5 days as a Zimbabwean schoolteacher to repeat the experience.

Performance Tip #14: Optimize For First Page Load

What's striking is that I used 50 MB of data and in most cases, I only visited one or two pages on any given site. If you think about it, this is true of most user journeys today.

Think about the last time you Googled something. You no doubt clicked on the first search result. If you got your answer, you closed the tab, or else you hit the back button and moved onto the next search result.

With the exception of a few so-called 'destination sites' such as Facebook or YouTube, where users habitually go as a starting point for other activities, the majority of user journeys are ephemeral. We stumble across random sites to get the answers to our questions, never to return to those sites again.

Web development practices are heavily skewed towards optimising for repeat visitors. “Cache these assets — they'll come in handy later”. “Pre-load this onward journey, in case the user clicks to read more”. “Subscribe to our mailing list”.

Instead, I believe we should optimize heavily for one-off visitors. Call it a controversial opinion, but maybe caching isn't really all that important. How important can a cached resource that never gets surfaced again be ? And perhaps users aren't actually going to subscribe to your mailing list after reading just the one article, so downloading the JavaScript and CSS for the mail subscription modal is both a waste of data and an annoying user experience.

The Decline Of Proxy Browsers

I had hoped to try out Opera Mini as part of this experiment. Opera Mini is a mobile web browser which proxies web pages through Opera's compression servers. It accounts for 1.42% of global traffic as of June 2019, according to caniuse.com.

Opera Mini claims to save up to 90% of data by doing some pretty intensive transcoding. HTML is parsed, images are compressed, styling is applied, and a certain amount of JavaScript is executed on Opera's servers. The server doesn't respond with HTML as you might expect — it actually transcodes the data into Opera Binary Markup Language (OBML), which is progressively loaded by Opera Mini on the device. It renders what is essentially an interactive 'snapshot' of the web page — think of it as a PDF with hyperlinks inside it. Read Tiffany Brown's excellent article, “Opera Mini and JavaScript” for a technical deep-dive.

It would have been a perfect way to eek my 50 MB budget as far as possible. Unfortunately, Opera Mini is no longer available on iOS in the UK. Attempting to visit it in the app store throws an error:

It's still available “in some markets” but reading between the lines, Opera will be phasing out Opera Mini for its new app — Opera Touch — which doesn't have any data-saving functionality apart from the ability to natively block ads.

Opera desktop used to have a 'Turbo mode', acting as a traditional proxy server (returning a HTML document instead of OBML), applying data-saving techniques but less intensively than Opera Mini. According to Opera, JavaScript continues to work and “you get all the videos, photos and text that you normally would, but you eat up less data and load pages faster”. However, Opera quietly removed Turbo mode in v60 earlier this year, and Opera Touch doesn't have a Turbo mode either. Turbo mode is currently only available on Opera for Android.

Android is where all the action is in terms of data-saving technology. Chrome offers a 'Lite mode' on its mobile browser for Android, which is not available for iPhones or iPads because of “platform constraints“. Outside of mobile, Google used to provide a 'Data Saver' extension for Chrome desktop, but this was canned in April.

Lite mode for Chrome Android can be forcibly enabled, or automatically kicks in when the network's effective connection type is 2G or worse, or when Chrome estimates the page will take more than 5 seconds to reach first contentful paint. Under these conditions, Chrome will request the lite version of the HTTPS URL as cached by Google's servers, and display this stripped-down version inside the user's browser, alongside a “Lite” marker in the address bar.

I'd love to try it out — apparently it disables scripts, replaces images with placeholders, prevents loading of non-critical resources and shows offline copies of pages if one is available on the device. This saves up to 60% of data. However, it isn't available in private (Incognito) mode, which hints at some of the privacy concerns surrounding proxy browsers.

В облегченном режиме URL-адрес HTTPS используется совместно с Google, поэтому логично, что этот режим недоступен в режиме инкогнито. Однако другая информация, такая как файлы cookie, данные для входа и содержимое персонализированной страницы, не передается Google — согласно ghacks.net — и «никогда не нарушает безопасное соединение между Chrome и веб-сайтом». Возникает вопрос, почему, по-видимому, ни один из этих сервисов по сохранению данных не разрешен на iOS (и нет никаких новостей о том, станет ли облегченный режим когда-либо доступным на iOS).

Прокси-серверы для экономии данных требуют большого доверия; ваша активность в Интернете, файлы cookie и другая конфиденциальная информация доверены какому-либо серверу, часто в другой стране. Многие прокси просто больше не будут работать, потому что многие сайты перешли на HTTPS, а это означает, что такие инициативы, как режим Turbo, стали в значительной степени «бесполезной функцией». HTTPS предотвращает такое поведение «человек посередине», и это хорошо, хотя это означало упадок некоторых из этих прокси-сервисов и сделало сайты менее доступными для тех, у кого плохое соединение.

Мне не удалось найти какой-либо инструмент для сохранения данных, совместимый с OSX или iOS, за исключением Bandwidth Hero для Firefox (который требует настройки собственной службы сжатия данных — далеко за пределами технических возможностей большинства пользователей!) и skyZIP Proxy (который последний раз обновлялся в 2017 года и изобилующие опечатками, я просто не мог заставить себя поверить).

Заключение

Сокращение объемов данных вашего веб-сайта идет рука об руку с повышением производительности интерфейса. Это самая надежная вещь, которую вы можете сделать для ускорения своего сайта.

Помимо стоимости данных, есть много веских причин, чтобы сосредоточиться на производительности, как описано в сообщении блога GOV.UK по этому вопросу:

• 53% пользователей покинут мобильный сайт, если он загружается более 3 секунд.
• Людям приходится концентрироваться на 50 % больше, когда они пытаются выполнить простую задачу на веб-сайте с использованием медленного соединения.
• Более производительные веб-страницы лучше подходят для времени автономной работы устройства пользователя и обычно требуют меньше энергии на сервере для доставки. Эффективный сайт полезен для окружающей среды.

У нас нет возможности изменить глобальную стоимость неравенства данных. Но у нас есть возможность уменьшить его влияние, улучшая опыт для всех участников процесса.