Компания
42,88
рейтинг
17 сентября 2015 в 09:53

Разработка → Одного лишь адаптивного дизайна мало: нам нужна адаптивная производительность перевод



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

Одной из главных причин этой ситуации является ориентация в первую очередь на пользователей десктопов и ноутбуков. Казалось бы, достаточно сменить приоритет и при создании дизайна ориентироваться на мобильных пользователей. Но это всё-равно не является гарантией хорошей производительности. Похоже, мы чересчур увлеклись идеей постепенного ухудшения характеристик (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 (используй или теряй)”. Например, использовать специальные версии библиотек для разработчиков, которые смогут отслеживать все использованные функции и снижать количество зависимостей, или хотя бы степень использования. Это помогло бы уменьшить громоздкость наших продуктов, снизить требования по производительности.

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


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

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

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

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

И наконец, если вы обычный разработчик или дизайнер, не ограничивайтесь в своей работе «наилучшими методиками». Всегда старайтесь заглянуть за горизонт. От вашего усердия зависит распространение концепций, которые пока никем не востребованы, ничем не поддерживаются и никак не документированы. Но которые пойдут только на пользу вашим клиентам и пользователям.
Автор: @NIX_Solutions Vedran Aberle Tokić
NIX Solutions
рейтинг 42,88

Комментарии (21)

  • 0
    Добротная статья и не слова об Web Workers API
    • 0
      + конечно же Service Workers API
    • +1
      А что о нём говорить? Он может вынести тяжёлые вычисления в отдельный от интерфейса поток. Однако в современных сайтах тяжёлая для старого девайса часть — это как раз интерфейс.
      • 0
        Второй ряд воркеров включает в себя ряд технологий от кеша приложения, до нотификаций и офлайн работы, адекватной реакции на разрывы и прочее
  • –1
    Прочитал статью, но не понял связи сайтов и производительности.

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

    Приведите пример связи сайта с производительности устройства.
    • 0
      Элементарно меню может открываться с несколькосекундным лагом, потому что авторы замутили там мудреную анимацию, а все неподдерживаемые красивости сделали костылями, ой простите полифилами.
  • 0
    Никогда не понимал когда рассказывали о необходимости адаптивной вёрстки которую должна тянуть даже старая нокиа. А тут уже и функционал должен адаптивным быть. А кому это нужно? Ну правда, что это за такой сайт который должен 100% работать на всём от старого телефона до 4к телевизора? Интернет-магазин — потеряет 1-2% пользователей от силы, да и не будет никакой пользователь извращаться заказывая что-то с экрана в 2 дюйма. Какой-нибудь госсайт который должен быть доступным для всех — так там некуда тяжёлые свистоперделки крутить, и так везде работать будет. Что-то типа ютуба — ну, извольте, некоторые вещи впринципе не смогут работать на старых устройствах. Бизнес-решения? Если это не бизнес по продаже старых телефонов — то я даже не знаю зачем их сайту адаптация к странным и устаревшим устройствам. В итоге получается что вроде бы оно и хорошо если всё будет на всём работать, но в реальности трудозатраты на такую разработку сильно превысят доходы полученные от пары лишних клиентов. Ну соцсети — разве что они заинтересованны в таких вещах.
    • –1
      Вот так и появляются сайты на которые авторы решили падающий снег добавить и всё — у кого проц хуже i7 видят слайдшоу.
      • 0
        Автор коммента все верно написал, а вы бросаетесь в крайности. По вашей логике отсутствие целесообразности поддержки некоторыми сервисами медленных устройств приводит к появлению снежинок, тормозящих на i7.
        • +1
          Да, именно так неизбежно и получается — программы пухнут ровно настолько, насколько им позволяют. Снежинкоразбрасыватели тоже посмотрели у себя — не тормозит, может даже на загрузку проца глянули (10-15%, даже i3 слопает ядро, ну так их два, а более слабых процов найти в продаже сложно), только никто из них не пробовал 5-10 вкладок открыть, особенно с ноута к сети не подключенного.

          Пользуясь той же логикой «ну, сейчас у всех уже 200 мбит в квартире, чего о размере страниц париться, пять метров за полсекунды у всех вытянутся, даже на 4G за секунду». На 1-2% извращенцев на GPRS, 3G, ADSL с лимитированным трафиком почти никто уже не смотрит. Но, как где-то сказали «у вас нет пользователей со старыми браузерами не потому что их вообще нет, а потому что ваш сайт в них просто не работает.». За примером даже ходить никуда не надо — приложение хабра на медленном интернете с вероятностью 90% пишет «ой, данные не успели загрузиться». Очень знаете ли мобильное приложение вышло.

          Далее, «не будет никакой пользователь извращаться заказывая что-то с экрана в 2 дюйма» — пока вы и vlreshet верите в эту чушь, авторы DeliveryClub подумали, нашли как не заставлять извращаться с клавиатурой без нужды и стригут купоны.
          • 0
            Да, именно так неизбежно и получается — программы пухнут ровно настолько, насколько им позволяют.

            Совершенно верно, но это не плохо. И их настолько же дешевле разрабатывать, насколько они пухнут. Программы ровно такие, чтоб приемлемо работали у большинства пользователей и для их разработки не требовался супер штат программистов. Причем так было всегда (можно вспомнить, как тормозил дум на 286, какой компьютер требовала 95-я винда). Просто некоторые почему-то считают, что на их старом железе все должно летать.

            Как я выше написал, крупным сервисам, таким, как DeliveryClub, действительно может быть оправдано иметь простую версию.

            Про хабр: ну, возможно, поддержка простой версии обошлась бы дороже, чем лоялность 1-2% пользователей. Я бы всеж посоветовал обратиться в техподдержку про «ой, данные не успели загрузиться».
            • 0
              У приложения DeliveryClub нет «простой» версии, там (1) требуют один раз ввести имя-телефон заказчика (2) адрес пытаются получить через GPS + ввод с автодополнением если GPS не ловит. (3) в отличие от приложения хабра — не надеются получить за 10 секунд и текст и графику, а, как во всех браузерах, сперва грузят текст, а графику когда получится.
              Собственно, хабровое приложение и список статей грузит с пятой попытки — видимо тянут html, вместо маленького json массива на десяток килобайт.
              Суть в чём — забив на старье вы автоматом делаете минимальными требованиями компьютер разработчика (Core i7 + 10 мс пинг до сайта и прочие радости локальной разработки)
  • +2
    Иногда мне кажется что лучше вместо поддомена m. для мобильный устройств делать поддомен f. для функционала. И на этом домене должна быть версия сайта без JS, без тяжелой графики — в общем эдакий веб 1.0, который бы позволял легкий доступ к контенту и действиям. Да вы наверняка помните WAP-сайты… да они и сейчас кое где живы. Ибо когда нужно найти информацию на странице с хитрой аякс-фильтрацией, а под рукой только смарфтон или планшет, то процесс превращается в пытку.
  • 0
    За последнее время несколько раз сталкивался с очень странной ситуацией. На довольно мощном планшете стандартная версия сайта работает отлично. Но мобильная версия начинает серьезно тормозить, а то и ронять браузер. Это даже не смешно.
  • 0
    Идея поддерживать весь зоопарк устройств, конечно, отличная.

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

    И замечание по переводу
    Слово «полизаполнения» лучше не переводить, а так и оставить — «полифилы» =)
    • 0
      Уж простите, но есть и нормальные варианты перевода в районе того комментария и выше.
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    До сих пор заметная доля ежегодных продаж приходится на традиционные кнопочные мобильные телефоны.
    Как бы то ни было, некая доля имеющихся у населения устройств вполне пригодна для веб-сёрфинга.


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

    В целом, по-моему, автор статьи передергивает. Рынок сам себя регулирует. Каждый крупный сервис примерно знает кол-во своих пользователей со старыми устройствами. Менее крупным сервисам обычно невыгодно поддерживать простую версию.
    • 0
      Автор просто предлагает изначально не обвешивать сайт никому из пользователей не нужными свистоперделками.
      • 0
        Трудно спорить с домыслами «никому ненужные свистоперделки». Пока что кажется, что свистоперделки не нужны только 3.5 гикам в интернете. Под этим я подразумевая что-то действительно полезное, как в свое время аякс в gmail, а не снежинки на сайте.
        • 0
          В общем-то свистоперделки потому так и названы, что для пользователя нет особой разницы есть они, или их нет.

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

Самое читаемое Разработка