Время от времени, когда идет дискуссия о путях реализации отзывчивых изображений, кто-то приходит и говорит: «Эй, ребята! Что нам действительно нужно, так это медиа-запрос, который позволяет нам отправлять изображения с высоким разрешением людям на быстром подключении и изображениясами с низким разрешением людям, наблюдавным замедленной связи». По крайней мере, на раннем этапе, многие люди согласились.
На первый взгляд, это имеет большой смысл. Изображения с высоким разрешением имеют значительную стоимость производительности, так как загрузка занимает больше времени. При медленном подключении к сети эта стоимость может негативно сказаться на опыте пользователя. Пользователи могут предпочесть изображения с низким разрешением, если это означает, что страницы будут загружаться значительно быстрее. С другой стороны, для пользователей с высокоскоростным соединением стоимость представления изображений с высоким разрешением снижается, и в этом случае пользователи, вероятно, предпочтут изображения более высокого качества.
Дальнейшее чтение на SmashingMag:
- Методы для грациозно унижающих медиа-запросы
- Breakpoints и будущее веб-сайтов
- Взгляд за рамки общих медиа-запросов Breakpoints
- Как решить адаптивные изображения в отзывчивый веб-дизайн
- Обучение CSS3: Справочник
Если бы у нас был медиа-запрос (и элемент HTML, который позволяет нам использовать этот медиа-запрос), который позволяет веб-разработчикам иметь такую степень контроля над подаваемыми изображениями как функцией пропускной способности, жизнь была бы персиковой.
Как выясняется, точно реализовать такой запрос мечты сми не намного проще, чем реализация машины, которая может точно предсказать, сколько он будет дождь две недели со следующего вторника. И даже если бы это было возможно для реализации, его побочные эффекты привели бы к худшему пользовательский опыт, а не лучше.
Что такое пропускная способность?
Поскольку мы обсуждаем пропускную способность, давайте сделаем паузу на минуту, чтобы определить ее.
Когда сетевые операторы публикуют свою скорость сети, они обычно ссылаются на количество исходных данных, которые могут быть отправлены на радиодиапазоне, как правило, в идеальных условиях.
Это число имеет мало отношения к веб-разработчикам. Пропускная способность, что мы заботимся о является «эффективной» пропускной способности. Эта пропускная способность обычно зависит от нескольких факторов: пропускной способности сети, ее задержки, скорости потери пакетов и протокола, используемого для загрузки данных. В нашем случае протоколом, о котором идет речь, является TCP.
TCP является доминирующим протоколом для надежной передачи данных в Интернете. Сам протокол имеет определенные накладные расходы, что приводит к разнице между теоретической и эффективной пропускной способностью. Но еще один фактор является причиной еще более значительного разрыва между ними. TCP не всегда использует всю доступную для нее пропускную способность, просто потому, что не знает размер пропускной способности.
Отправка большего количества данных, чем доступная пропускная способность, может привести к перегрузке сети,что имеет катастрофические последствия для сети. Таким образом, TCP использует несколько механизмов контроля заторов: медленный запуск и избегание заторов.
Каждое соединение TCP создается с очень ограниченной пропускной способностью «разрешение», называемое окном перегрузки. Окно заторов растет экспоненциально с течением времени, пока соединение TCP не направит достаточно данных для «заполнения трубы». Это этап медленного запуска, который может занять до нескольких секунд, в зависимости от задержки сети. Затем TCP периодически пытается отправить чуть больше, чтобы увидеть, если он может увеличить объем данных, которые он посылает, не вызывая перегрузки. Это фаза предотвращения заторов.
Ускоряет ли сеть проблему в гибком веб-дизайне? Чаще всего это изображения загружаются, когда они не должны. Изображение кредита: Эллиот Джей Акции.
Оба этих механизма предполагают, что потеря пакетов всегда вызвана перегрузкой; таким образом, потеря пакетов приводит к значительному сокращению к окну перегрузки, а также к скорости отправки данных. В беспроводных и мобильных сетях такое поведение не всегда идеально, поскольку они могут страдать от потери пакетов по причинам, не превышающим перегрузки (например, плохой прием), что может привести к недостаточному использованию сети.
Изменения пропускной способности
Пропускная способность, по самой своей природе, является переменной с течением времени. При загрузке одного ресурса пропускная способность мобильного пользователя может существенно измениться по нескольким причинам:
- Пользователь переключил ячейки или переместился в область с различным сотовым покрытием.
- Другие пользователи переместились в ячейку, в которую находится пользователь.
- Перегрузка сети на серверной стороне сети привела к снижению эффективной пропускной способности.
Пропускная способность пользователей Wi-Fi также может варьироваться в широких пределах. Это в основном связано с потерей пакетов, что оказывает значительное влияние на эффективную пропускную способность, поскольку TCP считает потерю пакетов результатом перегрузки.
Пропускная способность пользователей настольных компьютеров может также варьироваться в зависимости от типа соединения, хотя и не так значительно, как для мобильных пользователей и пользователей Wi-Fi. ADSL может страдать от погодных условий; кабель может пострадать от обмена uplink; и другие сети могут иметь свою собственную долю проблем.
И ещё. Когда мы думаем о пропускной способности пользователя, мы склонны думать о подключении пользователя к Интернету; но подключение веб-сервера к Интернету, его нагрузка и его близость к пользователю также могут оказать значительное влияние на эффективную пропускную способность, которую видит браузер. Итак, здесь действует еще одна переменная:сам веб-сервер. Когда мы говорим, что мы хотим измерить пропускную способность, мы говорим о пропускной способности между пользователем и веб-сервером, или просто пропускная способность радиосвязи? Все зависит от того, где полоса пропускной способности.
Эта изменчивость является основной причиной, почему делать прогнозы о будущей пропускной способности, вероятно, будет весьма неточным и подверженных ошибкам.
Измерение пропускной способности трудно
Итак, прогнозирование пропускной способности сложно, но измерение должно быть легко, не так ли? В конце концов, браузер уже загружает ресурсы. Он знает их размеры и сколько времени потребовалось, чтобы загрузить их — количество битов загружены разделены на время, необходимое для их загрузки. Как трудно это может быть?
Ну, если вы хотите измерить пропускную способность точно, это любопытное трудно. Приведенный выше расчет верен при загрузке большого файла на одно подогретое подключение TCP. Это редко бывает.
Давайте посмотрим на типичный сценарий загрузки веб-страницы, не так ли?
- Начальная страница HTML загружается На этом этапе, большую часть времени, браузер загружает начальную страницу HTML на новом подключении TCP. Это новое соединение TCP должно быть осторожным, чтобы не отправлять больше данных, чем физическая связь может обрабатывать, поэтому он использует свой механизм медленного запуска. Это означает, что на этом этапе, если браузеру необходимо измерить эффективную пропускную способность, он значительно занижает доступную пропускную способность. Когда мы обсуждаем медиа-запросы пропускной способности, этот этап является критическим. Когда браузеру необходимо решить, какие ресурсы загрузить в соответствии с запросом мультимедиа, это измерение, скорее всего, является единственным измерением пропускной способности, которое браузер будет иметь с этим конкретным сервером.
- Загружаются внешние ресурсы CSS и JavaScript. На этом этапе браузер имеет набор новых подключений TCP, все в фазе медленного запуска, и они не обязательно на один и тот же сервер назначения. Опять же, оценка пропускной способности на этом этапе не является простым.
- Изображения загружаются. Здесь браузер имеет несколько соединений, каждый из которых загружает ресурс. Проблема в том, что эти соединения не всегда находятся в одной и той же фазе жизненного цикла. Некоторые из них могут находиться в фазе медленного старта; некоторые из них, возможно, пострадали от потери пакета и, таким образом, сократили свое окно и пропускную способность, которые они пытаются заполнить; а некоторые могут быть разогретыми соединениями TCP, готовыми заполнить пропускную способность. Эти соединения TCP не обязательно все на тот же сервер назначения, и пропускная способность к различным серверам назначения может быть различным и между другими.
Таким образом, оценка пропускной способности возможна, но она далека от простой, и это возможно только для определенных этапов процесса загрузки страницы. И поскольку наличие нескольких подключений TCP к различным серверам назначения является общим (например, CDN может размещать ресурсы изображения веб-страницы), мы не можем сказать, что такое пропускная способность, который мы хотим измерить.
Медиа-запрос — это заказ
Что касается браузера, то медиа-запрос является прямым заказом, которому браузер должен соответствовать. В нем нет места для оптимизации. Он не может не повиноваться ему, даже если это не имеет абсолютно никакого смысла. Давайте рассмотрим, что это означает для медиа-запросов пропускной способности.
Давайте предположим на минуту, что браузеры на самом деле имеют точный способ измерения текущей пропускной способности и что решение для отзывчивых изображений на месте и может использовать запрос носителя полосы пропускания.
Задержка — это сетевой убийца. Это может значительно замедлить загрузку отзывчивого веб-сайта, особенно если он имеет множество изображений. Изображение кредита: Энди Чанг.
Естественно, что нужно сделать, то, было бы определить отзывчивое изображение с несколькими источниками — изображение с высоким разрешением для использования, когда пропускная способность превышает определенное значение, и изображение с низким разрешением, когда пропускная способность низкая. Браузер загрузки страницы, которая содержит изображение будет загружать сявок с высоким разрешением изображения, так как он имеет хорошие условия пропускной способности.
Допустим, через несколько секунд условия пропускной способности почему-то изменятся. Браузер (острый при обнаружении пропускной способности, как это) будет немедленно обнаружить, что пропускная способность не работает. Теперь браузер обязан загрузить изображение с низким разрешением и заменить изображение с высоким разрешением. Результатом является бесполезная загрузка изображения с низким разрешением и худший пользовательский опыт, потому что качество изображения, которое видит пользователь, хуже, чем могло бы быть. Даже если это произойдет только с низким процентом пользователей, это плохие новости.
Теперь можно утверждать, что браузер может оптимизировать и использовать версию, которая у него уже есть. Но дело в том, что он не может; не с медиа-запросов — по крайней мере, не без изменения всего смысла из них.
Итак, что альтернатива?
Ну, если медиа-запросы не могут быть использованы для обнаружения пропускной способности, нет ли надежды? Разве мы, как веб-разработчики, не должны быть в состоянии определить разрешение изображения в соответствии с доступной пропускной способностью?
Ненавижу это говорить, но мы не должны.
Веб-разработчики должны иметь возможность определять имиджевые ресурсы различных разрешений, которые впоследствии будут использоваться браузером для выполнения эвристических оптимизаций. Это может быть сделано с помощью декларативного синтаксиса, аналогичного синтаксису srcset предложения отзывчивых изображений. Синтаксис будет определять различные ресурсы и будет намекать браузеру, какие изображения использовать для различных критериев, таких как плотность экрана и размер экрана. Браузер будет использовать эти подсказки, но с пространством остается открытым для дальнейшей оптимизации (связанные с пропускной способностью, предпочтения пользователя, затраты на план данных, вы называете его).
Хотя у меня есть оговорки по поводу srcset предложения, и многие согласны с тем, что синтаксис он использует сбивает с толку, декларативная модель лучше, когда оптимизация пропускной способности (и другие авристики браузера) участвуют.
Тогда зачем нам нужны медиа-запросы?
Медиа-запросы необходимы, когда браузеру не должно быть позволено использовать эвристику, чтобы выбрать правильный ресурс изображения для представления. Одним из лучших примеров этого (и иллюстрация одного из самых больших недостатков srcset предложения) является случай использования художественного направления. Это случай использования, когда предлагаемый элемент изображения действительно сияет.
Корпус использования «Art Direction». Изображение кредита: W3C.
Именно по этой причине нам нужны оба подхода для достижения всестороннего решения для отзывчивых изображений, которое охватывает все случаи использования.
Измерения сети
Не поймите меня неправильно. Я не говорю, что мы должны отказаться от измерения сети в целом на веб-платформе.
Ведется работа над API сетевой информации, чтобы выяснить, как предоставить веб-разработчикам характеристики сети. В работе, проводимой по этой спецификации, одна из главных проблем — сюрприз! — как измерить пропускную способность.
Я считаю, что создатели браузера найдут способ в один прекрасный день для измерения пропускной способности в конце первоначальной загрузки страницы в полу-точный способ, который будет полезен для различных прогрессивных решений повышения. Но мы еще не там.
Заключение
Основная причина, по которой веб-разработчики хотят запросов на средства массовой информации пропускной способности, заключается в том, чтобы иметь возможность обслуживать разрешения изображений в соответствии с сетевыми условиями своих пользователей. В принципе, они хотят иметь право голоса в компромисс между красивыми изображениями и медленной загрузкой страницы.
К сожалению, это не похоже на то, что может быть точно реализовано в ближайшем будущем. Даже если бы он мог быть реализован, потому что медиа-запрос является заказом,это заставило бы загрузить несколько ресурсов для одного и того же изображения во многих случаях, что привело бы к ухудшению пользовательского опыта. Оптимизация пропускной способности лучше оставить на усмотрение браузера, который лучше знает пользователя, его предпочтения и сетевые условия.
Источник: smashingmagazine.com
