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

Одной из главных причин этой ситуации является ориентация в первую очередь на пользователей десктопов и ноутбуков. Казалось бы, достаточно сменить приоритет и при создании дизайна ориентироваться на мобильных пользователей. Но это всё-равно не является гарантией хорошей производительности. Похоже, мы чересчур увлеклись идеей постепенного ухудшения характеристик (graceful degradation), использованием всевозможных shim-библиотек и полизаполнений для компенсирования недостающего функционала. Ради ускорения разработки и обеспечения браузерной совместимости мы слишком сильно полагаемся на всевозможные библиотеки.

Наверное, многие спросят: «И в чём проблема? Большинство посетителей моего сайта пользуются нормальными смартфонами с актуальными версиями ОС. У них мой сайт работает без вопросов, об этом мне говорит аналитика». Но вполне очевидно, что аналитика расскажет именно о тех, кто может пользоваться вашим сайтом. И если в ней не упоминаются пользователи Android 2.3, то это не значит, что их нет или что на них можно не обращать внимание. Или ваш сайт просто не может им ничего предложить? Как это не удивительно, но даже сегодня можно найти в продаже устройства под управлением старых версий ОС. И вряд ли целесообразно отбрасывать всех пользователей не слишком свежих устройств и операционок.

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

Ориентация на устаревшие модели

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



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

Насколько нам, веб-разработчикам, трудно реализовать в качестве начального уровень, предназначенный для подобных «полумобильных» устройств? Уровень, на котором информация представлена с учётом определённых ограничений производительности?

Постепенное улучшение характеристик

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

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

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

Всё, проблема решена?

Ну, да, если не обращать внимание на производительность устройство нижнего ценового сегмента.

У них и процессоры слабее, и памяти меньше, но нагрузка на них только возрастает. Использование полизаполнения создаёт иллюзию доступности всего современного функционального многообразия на любых устройствах. И возникает соблазн использовать этот инструмент безо всяких ограничений. В результате наименее производительные устройства вынуждены обрабатывать очень тяжёлые вычислительные задачи. А мы пребываем в уверенности, что даём пользователям «лучший» user experience.



Что если использовать концепцию «постепенного улучшения характеристик» в противовес «постепенному ухудшению»? То есть начинать с версии сайта с наименьшими требованиями по производительности, подгружая дополнительные функциональности, пока не будет достигнут баланс удобства использования и производительности. Таким образом объём трафика и требования к вычислительной мощности будут адаптированы для использования более слабых устройств.

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

Он может, но должен ли?

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

Однако это палка о двух концах. Например, вы можете установить на старенький Android-смартфон самую свежую версию Google Chrome. Однако тот может ещё запустить CSS animations, WebGL, фоновые эффекты параллакса и многое другое. Старый же смартфон всё это просто не потянет. Браузер упадёт, а устройство вообще перестанет отвечать на действия пользователя, пока его не перезагрузишь или пока он не справится с навалившимися на него задачами.

Подобная проблема начала всё чаще возникать в различных Android-приложениях. Одним из ярких примеров заметного ухудшения характеристик стал апгрейд приложения Google Talk/Hangouts. В один момент оно превратилось из очень лёгкого мессенджера, работающего почти на всех устройствах, в неповоротливого монстра, практически непригодного для старых смартфонов.

Ещё раз напомним: эти «старые» устройства всё ещё можно купить в магазинах.

Похожая история приключилась и с приложением YouTube, и с мобильным Twitter, и со многими другими.

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

Оставьте пользователям возможность отказаться от ультрасовременного функционала

Вы когда-нибудь использовали Gmail на достаточно старых устройствах или при плохом уровне связи? В подобных случаях очень будет полезна «загрузка базового HTML-интерфейса».

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

Вам и правда нужна вся библиотека?

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



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

Многие библиотеки и приложения перед своим использованием дают возможность настроить «полезную нагрузку». Возможно, пришло время как-то стандартизировать и автоматизировать принцип построения архитектуры “use it or lose it (используй или теряй)”. Например, использовать специальные версии библиотек для разработчиков, которые смогут отслеживать все использованные функции и снижать количество зависимостей, или хотя бы степень использования. Это помогло бы уменьшить громоздкость наших продуктов, снизить требования по производительности.

«Что я могу сделать?»

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

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

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

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

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