Мы встречаемся с одним из лиц, стоящих за знаменательным проектом в эволюции адаптивного веб-дизайна, чтобы узнать, как расставить приоритеты в производительности и почему нам нужно проявлять большую ответственность
Проект Веб-сайт Boston Globe 2011 года, в котором студия дизайна и фронтенд-разработки Filament Group объединилась с Итаном Маркоттом, рассматривается как переломный момент в эволюции адаптивного веб-дизайна. Это была одна из первых крупномасштабных реализаций адаптивного дизайна, которая послужила основой для уточнения подхода и лежащих в его основе процессов. Одной из ключевых фигур в проекте был Скотт Джель, веб-дизайнер Filament Group, который также работал с такими клиентами, как Lego, Global News и eBay.
За этим переломным моментом для индустрии веб-дизайна последовало событие, изменившее жизнь самого Джеля. Он и его жена сели в самолет в Юго-Восточную Азию, где провели около восьми месяцев в путешествиях. «Я ушел после того, как закончил проект Boston Globe, и, взлетая [в Азию], я чувствовал, что нахожусь в хорошем положении. Я чувствовал, что получил много ответов », - вспоминает он.
В дороге Джель работал удаленно в Filament Group, а его жена работала волонтером в больнице. Пара пустила корни в течение нескольких месяцев, и Джель обнаружил, что ему нужно получить доступ в Интернет, используя местные службы. Это было своего рода шоком.
Другая реальность
«[В США] у нас довольно комфортно», - говорит он. Wi-Fi, 4G и новейшие гаджеты Apple - все это само собой разумеющееся. Для сравнения: доступ в Интернет через мобильные сети в Юго-Восточной Азии - как это делают многие местные жители - представлял большую проблему. Он полагался на комбинацию основных протоколов, удачи и данных, показывающих реальную решимость добраться до места назначения. «Я действительно должен был почувствовать, каково это жить на чужом месте», - добавляет Джель.
Испытание этого разрыва между цифровыми имущими и неимущими привело к новой решимости в Jehl. Покинув США полон уверенности, завоеванной успехом Boston Globe, Джель вернулся смиренно и ценив большую истину: дизайн не должен быть просто отзывчивым, он также должен быть ответственным. «Я понял, что предстоит решить еще много больших проблем», - размышляет он. «Я сосредоточился на производительности, особенно на медленных и прерывистых соединениях».
Осознание этого было настолько сильным, что Джель написал книгу на эту тему: Ответственный адаптивный дизайн, опубликованную в конце 2014 года издательством A Book Apart. Название исследует способы развития для действительно глобальной аудитории - независимо от сетевых возможностей - и уже вызывает волну в веб-сообществе.
Ответственный дизайн
Создание сайтов, предназначенных для работы с медленным подключением, может показаться морально правильным, но следует учитывать и деловую сторону. Почему клиент из США с внутренней клиентской базой должен тратить свое время и деньги на то, чтобы убедиться, что у него есть сайт, который будет работать в развивающихся странах?
«Вы должны помнить, что даже в США 3G по-прежнему является наиболее распространенной скоростью соединения», - отвечает Джель. «LTE не доминировал даже в городах. Я еду в Бостон, а там черные пятна ».
Что касается бизнес-кейса, проектирование сайтов и применение оптимизаций, которые делают работу в сети более быстрой, довольно просты: «Если человек просматривает страницы с предоплаченной SIM-картой, каждый загружаемый байт имеет реальную стоимость. И большинство сайтов в Интернете имеют размер в полтора или более мегабайта. Это довольно тяжело.
«3G по-прежнему является самой распространенной скоростью соединения в США. LTE не доминирует даже в городах »
Итак, проектирование сайтов с учетом производительности помогает всем. Однако Джель признает, что технически это может быть непросто. Чтобы сайт выглядел привлекательно, он должен отображаться за одну секунду или меньше через Wi-Fi и примерно за две секунды через 3G. Мнение о том, как добиться максимальной производительности, постоянно развивается. Джель вспоминает первые дни создания отзывчивых приложений, когда основное внимание уделялось размеру сайта. Мы создавали сайты, которые одновременно учитывали множество различных сценариев использования, и это неизбежно делало эти сайты тяжелее.
«Плавность была главной заботой, как и производительность», - уточняет он. «Одна из областей, на которую люди обратили свое внимание, - это размер необработанного файла. Насколько большим был сайт? Сколько байтов было загружено? »
В последнее время произошел сдвиг. Технический акцент сместился на изучение того, как мы можем предоставлять более легкие сайты, сохраняя при этом такой же богатый опыт. Один из приемов, по словам Джеля, заключается в расстановке приоритетов в том, что приходит первым. Управляя порядком, в котором контент отображается на экране, мы можем сильно повлиять на восприятие производительности сайта. Хотя, конечно, изменение порядка поступления контента не снижает веса самого сайта.
Проблемы с производительностью
По мере того, как мы говорим, становится очевидным, что Джель считает, что производительность должна быть звездой, которая направляет команду проекта. Производительность следует учитывать на каждом шагу, потому что она оказывает огромное влияние на способность сайта охватить аудиторию. «Если сайт не доставляется быстро, вы не можете задумываться об удобстве использования», - просто говорит Джель.
«Взаимодействие с нашими клиентами всегда начинается с того, что всех на одной волне», - продолжает он, объясняя, как сдвинуть проект с мертвой точки. «Производительность становится неотъемлемой частью всего, что мы производим на протяжении всего проекта». Опять же, Jehl подчеркивает, что убедить клиентов в необходимости сосредоточиться на производительности никогда не бывает трудным делом. Высокопроизводительный сайт, естественно, будет иметь низкие барьеры для доступа, что означает, что больше платежеспособных клиентов смогут получить к нему доступ.
Мы переходим к обсуждению бюджетов производительности. Джель объясняет, что, по его опыту, существует два общих подхода. Есть общий бюджет того, сколько кода вы хотите доставить, и есть бюджет того, сколько времени вы можете позволить себе потратить на рендеринг этого кода при различных скоростях подключения. Ни одна из метрик не идеальна.
В Filament Group основное внимание обычно уделяется показателям, основанным на времени. Бюджеты команды включаются в их инструменты сборки, поэтому, когда они вносят изменения в кодовую базу, код оптимизируется, а затем тестируется в браузере. Это тестирование показывает, повлияли ли изменения в код на снижение производительности по сравнению с бюджетом - все еще загружается в течение одной секунды в Wi-Fi и менее двух с половиной секунд в 3G?
«Если мы регрессируем, - говорит Джель, - мы должны вернуться назад и выяснить, что же произошло. Мы склонны подходить к бюджету таким образом, но я видел, что у других компаний есть очень успешные бюджеты, основанные на размерах файлов. В Etsy - я не знаю, неписаная ли это политика - но когда кто-то добавляет что-то тяжелое на страницу, они должны удалить что-то с таким же весом. Это тоже работает ».
Изучение встраивания
Наконец, мы переходим к изучению того, как команда может повысить производительность после завершения разработки и редактирования своего кода. «Есть много автоматизированных процессов, которые мы можем использовать», - говорит Джель. «Мы можем позволить нашим инструментам объединять файлы, поэтому мы делаем меньше запросов по сети. И мы можем начать развертывание встраивания ». Встраивание включает в себя обслуживание части CSS, необходимого для страницы, в том же файле, что и разметка. Благодаря объединению HTML и CSS количество запросов к серверу, необходимых для создания страницы, уменьшается.
По мнению Джеля, встраивание просто невероятно. Настолько невероятно, что Google обычно применяет эту технику, что является одной из причин высокой производительности его сайтов.
«Встраивание - сравнительно новая вещь, которая появилась в прошлом году или около того, и она действительно популярна», - с энтузиазмом говорит Джель. «Это здорово, потому что предлагает такое значительное улучшение. В некоторых случаях это может сократить время загрузки вдвое. Это потому, что сайт может совершить два, три или более циклов обращения к серверу, прежде чем он сможет начать предоставлять что-то пригодное для использования ».
«Встраивание предлагает такое значительное улучшение. В некоторых случаях это может сократить время загрузки вдвое »
Конечно, не стоит разрабатывать код, сочетая CSS и HTML. Это просто слишком беспорядочно, и, как указывает Джель, смешивать свои опасения - плохая практика. «С другой стороны, - возражает он, - если вы создаете простейший одностраничный веб-сайт, обычно - и действительно разумно - поместить элемент стиля в заголовок документа и добавить туда свой CSS».
Это умно, потому что, когда браузер встречает CSS с внешней ссылкой, он фактически останавливает все, что делает. Затем он запросит, загрузит и проанализирует CSS. Когда все это будет сделано, мы вернемся к рендерингу вашей страницы.
«Итак, да, разрабатывайте свой код изолированно, - резюмирует Джель, - но когда дело доходит до оптимизации кода, это совсем другое дело. Встраивание - это то, что мы хотим автоматизировать наши инструменты после завершения разработки. Это производственный этап ».
Методы завтрашнего дня
Неустанное стремление Джела к повышению производительности не заканчивается встраиванием - в настоящее время он изучает возможности HTTP / 2. Проблема с HTTP / 1.1 заключается в том, что, поскольку он разрешает только один запрос на TCP-соединение, эффективная загрузка нескольких ресурсов затруднена. Чтобы обойти это ограничение, браузеры могут запускать несколько TCP-запросов параллельно. Однако это ограниченное исправление, поскольку слишком большое количество TCP-запросов может привести к перегрузке сети и конфликтам ресурсов. Множественные запросы также приводят к значительному дублированию данных, что, опять же, снижает производительность.
По словам Джеля, в HTTP / 2 привлекательно то, что он делает ненужными многие современные хаки производительности. Некоторые браузеры (например, Chrome и Firefox) теперь поддерживают HTTP / 2, но он по-прежнему не является широко доступным. «Проблема в том, что серверы необходимо преобразовать, чтобы они могли общаться на этом языке», - объясняет Джель. «Так что это не произойдет в одночасье».
HTTP / 2 также предлагает новые функции. Сервер может, например, отправить ресурсы в браузер в том же цикле, что и другой запрос. «Браузер может сказать« пришлите мне этот HTML-документ », и сервер подумает:« Я знаю, что помимо этого HTML-документа вам понадобится этот CSS-файл », - взволнованно объясняет Джель. «Сервер отправит их обратно браузеру в одном запросе. Таким образом, HTTP / 2 имитирует тот же обходной путь встраивания, который мы используем ».
На этом Джель завершает нашу беседу. Несмотря на свой сложный график, он объясняет, что через несколько дней уезжает в Австралию. Неудивительно, что он говорит о производительности.
Слова Мартина Купера. Фотография сделана Чендлером Уильямсом.
Эта статья впервые появилась в 267-м номере сетевого журнала.
