Как новый элемент HTML сделает сеть быстрее

10 Сентября 2014 3568 , , ,

2351656805_2983091852_o-640x434

Сеть собирается стать быстрее в самом ближайшем будущем. Прочем для нас это не является новостью

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

Эта проблема — изображения. С августа 2014, размер средней страницы, в лучших 1000 сайтов в сети, составляет 1.7МБ., изображения составляют почти 1 МБ из этих 1.7МБ.

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

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

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

В начале был “мобильный интернет”

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

Просмотр на маленьком экране тогда требовал постоянного увеличения масштаба содержания, оптимизированного для экранов намного больше. Изображению требовалось бесконечно много времени, чтобы загрузиться на iPhone по медленной EDGE сети, а потом еще и Flash содержание… это не загружалось вообще. И это был iPhone; просматривание веб-сайтов, используя Blackberry или другие ОС калечили мобильные браузеры. Это делало ситуацию еще хуже.

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

Для решения этой проблемы, многие начали создавать второй сайт. Сейчас это звучит глупо, но всего несколько лет назад решение, для таких новых устройств как Blackberry, тогда новый iPhone, и некоторые первые телефоны на базе Android состояло в том, чтобы использовать серверные сценарии обнаружения устройства и перенаправить пользователей на специальный сайт для мобильных устройств, обычно URL как m.domain.com.

Эти специальные мобильный URL — часто называемые сайтами M-dot  — обычно испытывали недостаток во многих функциях, доступных на их «настоящих» настольных аналогах. Часто, сайты даже не перенаправляли должным образом, оставляя вас на домашней странице, когда вы хотели конкретную статью.

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

Адаптивный дизайн убил звезду MDot

В 2010 веб-разработчик Итан Маркотт написал небольшую статью о чем-то, что он назвал «Адаптивный веб-дизайн»

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

Оригинальный демо-сайт Маркотта на примере размеров телефона, планшета и настольного монитора

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

Адаптивный дизайн запустился, когда несколько более знаменитых разработчиков сделали свои персональные сайты адапативными, но он быстро взлетел, когда Маркотт и разработчики в Filament Group перепроектировали веб-сайт Boston Globe, чтобы сделать его адаптивным. Модернизация Globe показала, что адаптивный дизайн подходит не только для портфолио разработчиков и блогов. Модернизация Globe показала, что адаптивный дизайн был способом будущего.

В то время как газеты снова стали успешными с пользовательской точки зрения, Маркотт и Filament Group действительно негласно сталкивались с некоторыми проблемами, особенно с изображениями. Исходная статья Маркотта имела дело с изображениями, масштабируя их используя CSS. Эти сделанные изображения соответствуют меньшим экранам и сохраняют расположение содержания, но это также означало, что мобильные устройства загружали огромные изображения без намерения, когда-либо выводить их на экран в полном разрешении.

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

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

Представление элемента picture

История элемента Picture начинается с разработчиков, работающих над Boston Globe, включая Мэта Маркиза, который в конечном счете создал в соавторстве спецификацию HTML.

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

Как Маркиз объясняет, они думали, что у них было решение. «Мы начали с изображения для мобильного телефона и затем выборочно улучшали его оттуда. Это был hack, используя cookie и JavaScript. Это работало приблизительно неделю, пока не запустился сайт».

Примерно в это время, и Firefox и Chrome обновляли их возможности предварительной выборки, и новые инструменты предварительной выборки изображения повредили метод, используемый на прототипах Globe. Предварительная выборка браузера, оказалось, была больше, чем просто проблема для исходного решения Globe; это — фактически затруднение того, что является очень трудным в адаптивных изображениях.

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

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

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

К этому времени» Маркиз говорит, «у нас есть 10 или 15 разработчиков, и никто ничего не придумал».

Сайт  Globe так и запустился без решения. Мобильные устройства застряли, загружая огромные изображения.

Веб-сайт The Boston Globe на телефоне, планшете и настольном мониторе.

Вскоре другие знаменитые разработчики вне проекта Globe начали взвешивать решения, включая Google Пола Ириша и Opera Брюса Лоусона. Но никто не смог найти решение, которое охватывало бы все возможные случаи, которые разработчики определили.

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

Разговор скоро переместился в решения низшего уровня, включая новый элемент HTML, который мог бы так или иначе обойти проблемы предварительной выборки изображения способом, который никогда не будет JavaScript. Именно Брюс Лоусон первым предположил, что новый элемент <picture> могло бы стать решением. Хотя они и не знали этого в то время, элемент picture был уже предложен однажды, но никуда не вошел .

Добро пожаловать в джунгли стандартов (у нас есть забавы и игры)

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

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

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

В это время, W3C — то, где вторая группа, которая наблюдает за HTML, HTML WG, базируется — запустила новую идею названную «общественные группы». Общественные группы — попытка W3C включить посторонних в процесс стандартов, место, для предложения проблем и работы над их решением.

После отказа в WHATWG, кто-то сказал, чтоб разработчики запустили общественную группу. Responsive Images Community Group (RICG) родилась.

pic-ricg-site

Единственная проблема с общественными группами состоит в том, что никто фактически в рабочих группах не обращает внимания на общественные группы. Или по крайней мере они не обращали в 2011.

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

Большая часть этих усилий, благодаря Маркосу Касересу, теперь в Mozilla. В отличие от остальных членов группы, у Касереса был некоторый опыт с написанием веб-стандартов. Этот опыт позволил ему охватить разрыв между развитием двух миров — разработки стандартов и веб-разработки. Касерес организовал RICG и помог группе выработать те виды вариантов использования и тестирования, которые ищут органы стандартизации. Как Маркиз выражается, «Маркос видел, что мы крутились вокруг IRC, и помог организовать все».

«Я попытался согнать кошек в стадо», шутит Касерес. И стадо он сделал. Он установил Github repos, чтобы получить все в одном месте, установил пространство для адаптивных изображений сайта, и помог объединить все в первый документ вариантов использования. «Это сыграло действительно решающую роль для меня и для сообщества», говорит Касерес. «Это вынудило нас ясно сформулировать, в чем фактически заключалась проблема… и установить приоритеты».

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

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

Разработчики, понятно, раздражались.

С разработчиками, продвигающими Picture, и производителями браузеров и организациями по стандартизации, одобряющие намного более ограниченное и очень запутывающее (хотя все еще полезное) предложение по набору, после переименованного в srcset, было похоже, что ничто фактически никогда не выходило из работы RICG.

Как Пол Ириш выразился в канале WHATWG IRC, «[Маркиз] загонял в загон и возглавлял группу лучших разработчиков мобильного интернета, создал CG, выделил решение (из многих), боролся за и выиграл согласие в группе, записал черновую спецификацию и предложил ее. Он сделал вещь, которую люди стандартов действительно хотят, чтобы ‘авторы’ сделали. Именно поэтому он чувствует себя побеждающим».

Ириш не был одиноким. Протест разработчика, встретивший контрпредложение предложение WHATWG, был довольно шумным, достаточно шумным, что бы начали появляться некоторые полностью новые предложения. Но производителям браузера не удавалось договориться о чем-либо. Mozilla уничтожил идею WHATWG srcset на img. И Chrome отказался реализовывать Picture, поскольку это было определено в то время.

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

Изобретенный здесь

WHATWG группа, в конечном счете, преодолела синдром, «не изобретенный здесь». Или по крайней мере частично преодолела его.

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

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

Большой прорыв для Picture произошел благодаря  Opera Саймону Питерсу и Google Табу Аткинс. Они сделали простое, но мощное, предложение — сделать Picture оберткой для img. В таком случае не было бы два отдельных элемента для изображений в сети (который справедливо рассмотрели, путая), но все еще будет новый способ управлять тем, какое изображение браузер выводит на экран.

Это подход, используемый в окончательной версии спецификации Picture.

Когда браузер встречается с элементом Picture, он сначала оценивает любые правила, которые веб-разработчик мог бы определить. (У разработчика сайта Opera есть хорошая статья относительно всех возможностей Picture). Затем после оценки различных правил, браузер выбирает лучшее изображение на основе своих собственных критериев. Это — другая хорошая функция, так как критерии браузера могут включать параметры настроенные вами. Например, будущие браузеры могли бы предлагать загружать изображениям с высоким разрешением по 3G, независимо от того, что мог бы сказать любой элемент Picture на странице. Как только браузер знает, какое изображение является лучшим выбором, он загружает и отображает этот образ в старом добром IMG элементе.

Это решает две больших проблемы. Проблему предварительной выборки браузера: предварительная выборка все еще работает и нет никакой потери производительности. И проблему,  когда браузер не понимает Picture: теперь он возвращается к тому, что находится в IMG теге.

В финальной заявке, происходит обертывание Picture в img тег. Если браузер слишком стар, чтобы знать, что делать с элементом < picture>, то это загружает нейтрализацию img тега. Все преимущества доступности остаются, так как атрибут alt находится все еще на img элементе.

Все счастливы, и сеть победила.

Хорошая теория, но покажите мне браузер

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

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

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

Однако, как Касерес, Вейс смог устранить разрыв между миром разработчиков C++ и Веб-разработчиков. Он был в уникальной позиции, чтобы быть в состоянии знать то, что должно было сделать Picture и как заставить это произойти. После обсуждения этого с другими разработчиками Chrome Вейс начал работу на Blink, механизм рендеринга браузера Google Chrome.

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

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

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

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

Достаточно денег было собрано не только на реализацию Picture в Blink, но и также на работу Вейса по портовым операциям WebKit, таким образом, браузеры WebKit (включая версию iOS Apple Safari) могут использовать его также. Одновременно, Касерес запустил работу над Mozilla и помог управлять поддержкой Picture Firefox.

На сегодняшний день элемент Picture будет доступен в Chrome и Firefox к концу года. Это доступно теперь в канале Chrome dev и  Firefox 34+ (в Firefox, в котором вы должны будете включить его about:config). Вот тестовая страница, показывающая новый элемент Picture в действии.

Opera, также на основе Blink будет поддерживать Picture в ближайшем будущем. Apple, кажется, добавляет поддержку Safari через бэкпорт к WebKit, хотя это не было закончено как раз к предстоящему Safari 8. Microsoft аналогично рассматривает Picture для следующего выпуска IE.

Будущее сети

История элемента Picture не просто интересный рассказ о веб-разработчиках, сотрудничающих, чтобы сделать сеть лучшим местом. Это — также проблеск в будущем. Разделение между теми, кто создает сеть и теми, кто создает веб-стандарты, исчезает. Общественные группы W3C растут, и такие сайты как  Move the Web Forward  помогают устранить разрыв между идеями разработчика и организациями по стандартизации.

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

Picture может быть почти закончен, но RICG не уходит. Фактически, переименовывает себя и берет новый проект — элемент Queries. Скоро в браузере рядом с вами.

По материалам: arstechnica.com

Подписывайтесь на обновления

Читайте RSS ленту

Комментарии

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