Медиа запросы полосы пропускания — они нам не нужны.

Перевод статьиBandwidth Media Queries? We Don’t Need ’Em!
Автор статьи: Yoav Weiss.

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

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

Да, если бы только в нашем распоряжении был такой механизм медиа запросов (а также соответствующий HTML элемент, позволяющий нам применять их), который предоставлял бы веб-разработчикам необходимый уровень контроля над используемыми изображениями, реализованный в виде функции полосы пропускания, все вопросы отпали бы сами собой.

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

Что представляет собой полоса пропускания?

Поскольку речь идет о полосе пропускания (ее ширине), то давайте на минутку прервемся и определимся с этим понятием.

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

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

TCP является доминирующим протоколом надежной передачи данных в Интернете. Данный протокол, как собственно и другие, помимо передачи полезной информации предусматривает наличие служебных данных, которые и образуют разницу между теоретической и эффективной полосой пропускания. Но имеется и другой фактор, который является причиной куда более существенного различия между этими двумя значениями. Протокол TCP никогда не использует всю доступную пропускную способность сетевого соединения, это объясняется тем, что ему просто не известна величина полосы пропускания. (*TCP как раз и пытается это выяснить в процессе передачи данных.)

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

Изначально каждому TCP соединению отводится очень ограниченная часть всей доступной ширины полосы пропускания, называемая окном перегрузки. С течением времени величина этого окна экспоненциально растет до тех пор, пока TCP протоколом за один раз не будет послано максимально допустимое количество данных (максимальный сегмент), на передачу которого рассчитано сетевое соединение. Эта фаза называется затяжной пуск, который может длиться несколько секунд, в зависимости от коэффициента задержек сети. Далее TCP периодически пытается передать на один сегмент больше, проверяя таким образом возможности сети и сможет ли он увеличить объем передаваемых данных не приводя к заторам. Это уже фаза предотвращения перегрузки.

Загрузка изображения в зависимости от конфигурационных условий конечного устройства.

Изображение взято с ресурса Elliot Jay Stocks.

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

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

Колебания ширины полосы пропускания.

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

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

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

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

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

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

Определение ширины полосы пропускания — непростая задача.

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

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

А что если взглянуть на типичный сценарий загрузки веб-страницы.

  1. Загрузка исходного HTML документа.
    Большую часть времени этой фазы браузер загружает исходный HTML код веб-страницы, используя для этого новое TCP соединение. Как описывалось выше, протокол устанавливает вновь создаваемое соединение с осторожностью, изначально посылая порцию данных, которую в состоянии обработать физический уровень, то есть запускается механизм медленного старта. Это означает, что если браузеру понадобиться измерить доступную ему эффективную полосу пропускания в период этой фазы, то результат такого измерения будет значительно ниже доступной пропускной способности. И если мы говорим об использовании медиа блоков полосы пропускания, то именно эта фаза загрузки веб-страницы является критической. Таким образом, если браузеру необходимо будет определить какой из ресурсов загружать, учитывая представленную в медиа запросах информацию, то вероятней всего, что результат именно этого измерения будет им использован в качестве значения ширины полосы пропускания для данного сервера.
  2. Загрузка внешних ресурсов CSS и JavaScript.
    В ходе этой фазы у браузера появляется ряд новых TCP соединений, каждое из которых находится на этапе затяжного пуска, и совсем не обязательно, что все они устанавливаются с одним сервером. Опять же, в этот период оценка доступной пропускной способности будет недостоверной.
  3. Загрузка изображений.
    Теперь браузер использует несколько соединений, каждое из которых необходимо для загрузки отдельного ресурса. Проблема заключается в том, что все эти соединения не всегда находятся в одной и той же фазе их жизненного цикла. То есть некоторые из них могут находиться в фазе медленного старта; другие в это время испытывать потерю пакетов и как следствие снижение окна перегрузки и пропускной способности, которой они пытаются достичь; третьи же могут находиться на пике своей активности, практически полностью используя доступную полосу пропускания. Все они не обязательно используют один и тот же сервер, а соединения с разными серверами, как правило, имеют различия в значениях пропускной способности.

То есть оценка ширины полосы пропускания в принципе возможна, но это далеко не простая задача, которая выполнима только на определенных этапах процесса загрузки документа. А поскольку наличие нескольких TCP соединений с серверами различных назначений, это обычное дело (к примеру, графические ресурсы страницы могут находиться на CDN хосте), то в реальных условиях мы не можем определенно сказать, ширину полосы пропускания какого именно из имеющихся соединений нам необходимо измерять.

Медиа запрос — это инструкция.

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

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

Пример отображения отзывчивого дизайна.

Изображение взято с ресурса Andy Chung.

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

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

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

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

Так где же альтернатива?

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

Как не хочется это говорить, но нет, мы не должны.

Веб-разработчику нужно предоставить лишь возможность указания ресурсов изображений различного разрешения, которые впоследствии будут использоваться в ходе эвристической оптимизации, выполняемой браузером. Это может быть реализовано с помощью декларативного синтаксиса, схожего с тем, который используется при определении атрибута указания альтернативных изображений srcset, предложенного для реализации отзывчивых изображений. Такой синтаксис должен позволять определение различных ресурсов, подсказывая при этом браузеру какие из них должны использоваться в различных ситуациях с учетом различных критериев, таких, например, как разрешение или размер экрана конечного устройства и др. Браузер, в свою очередь, принимая во внимание предоставленные ему подсказки, должен предусмотреть возможность дополнительной оптимизации, то есть при наличии другой конфигурационной информации (такой как значение полосы пропускания, предпочтения пользователя, стоимость тарифного плана, и многое другое, можете самостоятельно продолжить этот список), браузер должен учитывать и ее.

Несмотря на то, что у меня есть сомнения касательно эффективности srcset механизма, а также множество претензий к его синтаксису, всё-таки в нашем случае, когда дело касается основанной на пропускной способности (а также других критериях используемых в ходе выполняемого браузером эвристического анализа) оптимизации, декларативная модель является лучшим решением.

Зачем тогда нам нужны медиа запросы?

Медиа запросы необходимы для тех случаев, когда веб-браузер как раз не должен применять эвристические методы анализа в ходе выбора корректного источника представляемого изображения. Одним из ярких примеров таких случаев (который одновременно демонстрирует один из существенных недостатков предоставляемого srcset атрибутом функционала) является прецедент «художественного редактирования». Это именно тот сценарий использования, когда предложенный в качестве решения элемент pictutre на самом деле идеалено справляется с поставленной задачей.

Прецедент «художественного редактирования».

Изображение взято с ресурса W3C.

Прецедент «художественного редактирования».

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

Сетевые измерения.

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

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

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

Заключение.

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

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

Обзор
комментариев

Да, действительно, даже если этот механизм когда-то и заработает, адекватно оценивая возможности сетевого соединения, проблема предоставления пользователю необходимого уровня удобства использования ресурса, зависимого от этого критерия, всё равно останется открытым. Ведь мы никогда не можем предугадать преследуемые пользователем цели. Он может перейти на сайт по одной из внешних ссылок для получения дополнительной, расширенной информации касательно интересующей его темы. Другой может заглянуть на него с целью загрузки предлагаемых на сайте ресурсов, третий воспользоваться определенным сервисом. А попав на сайт с одной целью, посетитель может заинтересоваться другими сторонами представленного на нем контента. Некоторые пользователи намеренно стараются снизить используемый ими трафик так как за него им приходится платить, другие же наслаждаются безлимитным тарифом. Здесь вариантов миллион. И почему, в конце концов, мы должны навязывать пользователю свои принципы выбора ресурса. Именно эта точка зрения выражена в большинстве комментариев к этой и не только этой статье, а также к другим статьям на ту же тему. То есть проблема удобства для пользователя все же остается.

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

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

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

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

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

Имеют право на существование и некоторые другие версии выхода из положения. Так, допустим, в области оптимизации компьютерных игр используется концепция текстур с варьируемым разрешением, которая предусматривает использования текстур, содержащих несколько различного размера изображений в одном графическом файле, а игровой движок и/или видео карта, отталкиваясь от конфигурационных показателей, использует необходимый вариант. То есть, возможно, решением проблемы являетя некий новый, улучшенный формат изображения (схожий с прогрессивным jpeg), предусматривающий варианты использования ресурса с различным разрешением.

В общем-то, у нас уже есть подходящие технологии — это GIF/PNG форматы и упомянутый выше прогрессивный JPEG, которые позволяют отображать изображение низкого разрешения в то время, как остальная часть файла изображения загружается, а по окончании загрузки пользователь сможет увидеть высококачественную картинку. Но проблема тогда заключается в том, что в случае медленного сетевого соединения такое поведение станет причиной затяжной загрузки изображения высокого разрешения, что может повлечь за собой блокирование или в лучшем случае замедление загрузки остальных элементов страницы. Было бы неплохо, если бы браузеры могли выявлять такие ситуации и соответствующим образом на них реагировать. То есть по истечении определенного времени (порогового значения) приостанавливать загрузку остальной части уже отображаемого с минимальным разрешением изображения и начинать загрузку остальных изображений до того же уровня, то есть до возможности их отображения с минимальным разрешением. Для этого пользовательский агент должен использовать специальный алгоритм, учитывающий приоритетность изображений и других ресурсов страницы.

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

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

По моему личному мнению необходимо со всей ответственностью подходить к вопросу оптимизации изображений вашего сайта. Иногда в ходе разработки сама оптимизация рассматривается как малоприоритетная задача, однако, на самом деле это не так. Процесс оптимизации ресурса очень важен и трудоемок и он должен начинаться намного раньше финальных тестирований. Один из разработчиков в своем комментарии к оригиналу представленной здесь статьи посоветовал делать слудующее: взять в качестве начальной точки отсчета самое медленное сетевое соединение, оптимизировать ваш ресурс под него, добившись достаточно быстрой загрузки и работы и далее продолжить процесс, добавляя другие, второстепенные компоненты сайта (и заменяя их на другие при необходимости), постоянно отслеживая при этом его быстродействие. Таким образом вы сможете последовательно достигнуть необходимой «комплектации» вашего сайта, контролируя степень его производительности.

* Примечание переводчика.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *