Что такое прогрессивное улучшение и почему это должно вас волновать?

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

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

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

Постепенное улучшение не означает, что веб-сайт должен работать без JavaScript. Это не означает, что вам нужно обслуживать пользователей, у которых отключен JavaScript в их браузерах.

«Прогрессивное совершенствование - это подход к разработке, а не выбор технологии».

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

Почему прогрессивное улучшение - это не то же самое, что постепенная деградация

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

Слои прогрессивного улучшения

Наиболее широко известная аналогия для описания прогрессивного улучшения - это Peanut M&M. Когда я учил студентов колледжа, я часто использовал эту аналогию как синоним торта.

Чтобы проиллюстрировать самый крайний случай этого, я разобью его следующим образом:

Чтобы сделать торт, вам нужно начать с основы и конструкции, самого торта. Это означает, что по сути вы можете создавать приложение только для HTML, в котором вся важная обработка выполняется на стороне сервера. Ваше приложение будет работать в любом браузере или мобильном устройстве, браузере Lynx и даже IE 1.0. Я понимаю, что поддержка IE 1.0 нереалистична, но я хочу лишь проиллюстрировать свою точку зрения: HTML работает везде.

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

Кроме того, вы можете добавить в макет сайта мультимедийные запросы, улучшив работу с различными устройствами. Добавление операторов @supports также может улучшить взаимодействие с браузерами, поддерживающими новые свойства CSS, такие как flexbox и сетки CSS.

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

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

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

Повышение производительности и доступности за счет прогрессивного улучшения

Как я уже упоминал ранее, сегодняшние веб-сайты больше, чем когда-либо. Согласно HTTP Archive, сайту, который отслеживает производительность веб-сайтов и используемые ими технологии, сегодня средняя веб-страница занимает около 2,35 МБ загружаемых ресурсов.

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

Производительность для растущих сайтов

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

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

Обнаружение функции

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

Проще говоря, мы можем использовать резкий подход к этому типу разработки, впервые предложенный BBC как способ легко разделить проблемы поддержки между браузерами HTML4 и браузерами HTML5. Это позволяет нам расширять возможности пользователей с новыми браузерами, используя обнаружение функций как средство прогрессивного улучшения.

if('querySelector' in document 
  && 'localStorage' in window 
  && 'addEventListener' in window) { 
  // bootstrap the javascript application
}

Доступность на первом месте

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

HTML как основа доступности

Магия Интернета в том, что HTML работает просто из-за своей простоты. Сэр Тим Бернерс Ли, создатель всемирной паутины, назвал это принципом наименьшей мощности. Даже с хорошо протестированным кодом, что случается не всегда, сложные программы, написанные на JavaScript, имеют больше возможностей для сбоя. Это потому, что HTML и CSS просто менее сложны, потому что они декларативные языки.

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

Медиа-запросы о доступности

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

<meta name="viewport" content="width=device-width, initial-scale=1.0">

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

Сервис-воркеры для офлайн и push-уведомлений

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

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

Вы можете сказать: Но, Тиффани, я создаю темы, зачем мне использовать сервис-воркера? Я бы ответил, что сервис-работники могут улучшить опыт и помочь создать офлайн-контент или даже push-уведомления, которые помогут клиентам. Для интернет-магазинов push-уведомления, вероятно, являются одним из наиболее распространенных вариантов использования. Отличным примером этого является Приложение Firepush или Aimtell для Shopify. Он использует сервис-воркеров для отправки push-уведомлений через браузер, которые можно использовать для отслеживания обновлений пакетов, уведомлений о продажах и т. Д.

Резервные варианты CSS и @supports

Обычно, когда мы говорим о прогрессивном улучшении, разговор заходит о JavaScript. И хотя в Javascript могут быть некоторые подводные камни, связанные с прогрессивным улучшением, со всеми новыми функциями CSS3, добавляемыми в браузеры и спецификациями W3C, есть некоторые передовые методы, которым мы можем следовать.

Запасные варианты

Наиболее распространенная практика постепенного улучшения CSS - использование резервных вариантов. Мы можем использовать архитектуру CSS для эффективного создания резервной копии, когда свойство CSS не найдено или не поддерживается браузером. Поскольку браузер читает CSS в хронологическом порядке, нам просто нужно поместить резервное свойство перед новым. Таким образом мы поддерживаем префиксы конкретных поставщиков для новых свойств CSS.

h1 { 
  background-color: #000;
  background-color: rgba(0,0,0,0.5);
  color: white;
}

Раньше, если браузер не поддерживал rgba() (IE8), вы могли указать перед ним альтернативный цвет, чтобы он просто «резервный» для последний цвет понял. Чаще всего мы видим использование этой техники с новыми свойствами и префиксами CSS.

.wrapper { 
  display: -webkit-box; /* OLD iOS 6-, Safari 3.1-6 */ 
  display: -moz-box; /* OLD Firefox 19- (buggy but mostly works) */ 
  display: -ms-flexbox; /* TWEENER - IE 10 */ 
  display: -webkit-flex; /* NEW - Chrome */ 
  display: flex; /* NEW, Spec - Opera 12.1, Firefox 20+ */
}

В этом примере показаны префиксы, необходимые для поддержки flexbox, со старым, промежуточным и новым синтаксисом.

@supports

В прошлом году на Smashing Conf я видел, как Джен Симмонс говорила о @supports в презентации Настоящее направление искусства в Интернете и о том, как его можно использовать для постепенного улучшения веб-сайта. @supports действует в основном как обнаружение функций для CSS, и может быть действительно мощным. Вложенность аналогична @media. Вы можете передать ему любое объявление CSS в сочетании с различными операторами, такими как not, and и or. Он также может принимать пользовательские свойства (переменные CSS) в качестве аргумента.

Базовая проверка собственности

Проверьте пары основных свойств и значений.

@supports (display: flex) {
  .wrapper {
    display: flex;
  }
}

не ключевое слово

Используйте ключевое слово not для проверки отсутствия поддержки.

@supports not (display: flex) {
  .wrapper {
    float: left; /* alternative styles */
  }
}

Множественные проверки и условные выражения

Можно выполнить несколько проверок свойств CSS, связав операторы or и and.

@supports (display: -webkit-flex) or
  (display: -moz-flex) or
  (display: flex) {
  /* styles */
}

Узнайте больше о @supports, посетив спецификацию в сети разработчиков Mozilla.

Так почему я должен волноваться?

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

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

Иллюстрации и анимация Тиффани Це.

Первоначально опубликовано на www.shopify.com/partners/blog.