Адаптивного дизайна недостаточно, нам нужна адаптивная производительность

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

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

"Зачем беспокоиться?" Вы можете спросить. «Большинство наших посетителей имеют высокопроизводительные смартфоны с последними версиями ОС. Они могут обрабатывать наши сайты. Об этом говорят аналитики».

Я прошу прощения за аргумент соломенного человека, но я думаю, что стоит заявить вслух, что люди, которые могут использовать ваш сайт, будут большинством ваших пользователей. Если вы не видите Android 2.3 в своей аналитике, значит ли это, что пользователей с этими устройствами нет? Или это означает, что вашему сайту нечего предложить этим пользователям? Учтите, что многие устройства того поколения до сих пор лежат на прилавках, их даже сегодня покупают совершенно новыми. Вы не должны полностью отвергать это как технологию прошлых лет.

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

Парадигма проектирования «кирпич-первый»

Значительная часть годовых продаж телефонов по-прежнему приходится на кнопочные телефоны. Еще большая часть населения не покупает телефоны каждый год, но, тем не менее, имеет какое-либо устройство с поддержкой Интернета. Добавьте к этим числам смартфоны последнего поколения, которые все еще используются, добавьте Kindle и другие устройства с частичной поддержкой Интернета (WAP-устройства, телевизоры, тостеры, футболки и кирпичи). Сложите их все, и вы можете получить ошеломляющую сумму.

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

Насколько сложно нам будет реализовать макет, ориентированный на субмобильные устройства, который будет предоставлять только эту информацию устройствам ниже определенного порога возможностей и производительности?

Изящное улучшение

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

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

С точки зрения этой статьи это можно было бы разбить следующим образом:

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

Мягкая деградация: если функция недоступна, она дает сбой таким образом, что все еще обеспечивает приемлемое удобство использования.

Неизящное улучшение: если функция недоступна, она эмулируется полифиллом или прокладкой.

Вот, проблема решена.

Ну, если не учитывать производительность тех самых бюджетных устройств.

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

А так внедряешь модернизр и полифиллишь все на всякий случай. Наименее компетентное устройство загружает наибольший объем данных и выполняет наибольший объем обработки. Таким образом обеспечивается «лучший» опыт конечного пользователя.

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

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

Можно, но нужно ли?

Еще одна передовая практика веб-разработки — проверка доступности функции на устройстве перед ее активацией.

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

В последнее время эта проблема начала сильно влиять на приложения Android (с точки зрения пользователя). Одно из наиболее заметных ухудшений в этом смысле коснулось обновления приложения Google Talk/Hangouts, которое превратило их сервис из самого легковесного приложения для чата в практически непригодное для использования приложение из-за проблем с производительностью на старых устройствах. (Еще раз подчеркну: «старше» здесь означает, что вы все еще можете купить его в готовом виде, абсолютно новый практически в любом магазине). Та же проблема коснулась приложения YouTube и приложения Twitter (по моему опыту) и, по-видимому, многих других.

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

Позвольте пользователям отказаться от передового опыта

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

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

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

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

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

В последнее время я стал отслеживать, сколько функций я фактически использую после включения библиотеки. И инструмент, который я использую чаще всего, это jQuery. Часто я обнаруживаю, что использовал только одну или две функции (например, $.extend или $.ready) или, что еще хуже, использовал их только для получения элементов по классу или идентификатору. Иногда я оставляю все как есть, в других случаях я возвращаюсь к коду, чтобы удалить или отделить зависимость.

Было бы неплохо, если бы вы могли автоматически анализировать, что и сколько из библиотеки в конечном итоге было использовано, и терять вес на основе результатов?

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

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

Что потребуется, так это версия библиотеки только для разработки, которая посредством модульного тестирования зависимой функциональности позволит отслеживать используемые функции и выводить минимальную зависимость или, по крайней мере, масштаб использования (например, спрашивая, включил ли я jQuery для 8% его функциональности или 80%). Затем выходные данные зависимости можно использовать для отбора, агрегирования и минимизации выходных данных для производства.

Но что я могу с этим поделать?

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

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

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

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

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

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

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