Прогрессивные веб-приложения (PWA) создаются и расширяются с помощью современных API-интерфейсов, обеспечивая расширенные возможности, надежность и возможность установки, обеспечивая доступ к кому угодно, где угодно и на любом устройстве с помощью единой базы кода. Чтобы помочь вам создать наилучший опыт, используйте основные и оптимальные контрольные списки и рекомендации.
Контрольный список основного прогрессивного веб-приложения
Контрольный список прогрессивных веб-приложений описывает, что делает приложение доступным для установки и использования всеми пользователями, независимо от размера или типа ввода.
Производительность играет важную роль в успехе любого онлайн-опыта, поскольку высокоэффективные сайты привлекают и удерживают пользователей лучше, чем неэффективные. Сосредоточьтесь на оптимизации показателей производительности, ориентированных на пользователя.
Почему
Скорость имеет решающее значение для того, чтобы пользователи использовали ваше приложение. Фактически, когда время загрузки страницы увеличивается с одной секунды до десяти секунд, вероятность отказа пользователя увеличивается на 123%. Производительность также не останавливается на событии load . Пользователи никогда не должны задаваться вопросом, было ли зарегистрировано их действие — например, нажатие кнопки — или нет. Прокрутка и анимация должны быть плавными. Производительность влияет на весь ваш опыт: как на поведение вашего приложения, так и на то, как его воспринимают пользователи.
Хотя все приложения имеют разные потребности, аудит производительности в Lighthouse основан на основных веб-показателях , и высокие оценки в этих аудитах повысят вероятность того, что ваши пользователи получат больше удовольствия от работы. Вы также можете использовать PageSpeed Insights или отчет об опыте пользователей Chrome , чтобы получить реальные данные о производительности вашего веб-приложения.
Как
Следуйте нашему руководству по быстрой загрузке , чтобы узнать, как заставить PWA запускаться быстро и оставаться быстрым.
Пользователи могут использовать любой браузер для доступа к вашему веб-приложению до его установки.
Почему
Прогрессивные веб-приложения — это прежде всего веб-приложения, а это означает, что они должны работать во всех браузерах.
По словам Джереми Кейта из Resilient Web Design , эффективный способ сделать это — определить основные функции, сделать эти функции доступными с использованием простейшей технологии, а затем улучшить качество обслуживания там, где это возможно. Во многих случаях это означает, что нужно начинать с HTML для создания основных функций и улучшать взаимодействие с пользователем с помощью CSS и JavaScript, чтобы сделать его более привлекательным.
Возьмем, к примеру, отправку формы. Самый простой способ реализовать это — HTML-форма, отправляющая запрос POST . После его создания вы можете улучшить работу с JavaScript, чтобы выполнять проверку формы и отправлять форму через AJAX, улучшая удобство работы для пользователей, которые могут его поддерживать.
Пользователи используют ваш сайт на разных устройствах и браузерах. Вы не можете просто нацелиться на верхнюю часть этого спектра. Используйте обнаружение функций, чтобы предоставить удобство использования максимально широкому кругу потенциальных пользователей, включая тех, кто использует браузеры и устройства, которых еще нет.
Как
Книга Джереми Кита «Отказоустойчивый веб-дизайн» — отличный ресурс, описывающий, как следует подходить к веб-дизайну с использованием этой кроссбраузерной прогрессивной методологии.
Дополнительное чтение
- Книга «Понимание прогрессивного улучшения» в List Apart — хорошее введение в эту тему.
- Прогрессивное улучшение журнала Smashing Magazine: что это такое и как его использовать? дает практическое введение и ссылки на более сложные темы.
- В статье MDN «Реализация обнаружения функций» обсуждается, как обнаружить функцию путем прямого запроса к ней.
Пользователи могут использовать PWA на экране любого размера, и весь его контент доступен при любом размере области просмотра.
Почему
Устройства бывают разных размеров, и пользователи могут использовать ваше приложение в разных размерах, даже на одном и том же устройстве. Поэтому очень важно убедиться, что не только ваш контент умещается в области просмотра, но и чтобы все функции и контент вашего сайта можно было использовать при всех размерах области просмотра.
Задачи, которые пользователи хотят выполнить, и контент, к которому они хотят получить доступ, не меняются в зависимости от размера области просмотра. Вы можете переупорядочить свой контент для разных размеров области просмотра, и все это так или иначе должно быть там. Фактически, как утверждает Люк Вроблевски в своей книге «Mobile First» , начав с малого и доработав дизайн для больших экранов, можно улучшить дизайн сайта:
Мобильные устройства требуют от команд разработчиков программного обеспечения сосредоточиться только на самых важных данных и действиях в приложении. На экране размером 320 на 480 пикселей просто нет места для посторонних, ненужных элементов. Вы должны расставить приоритеты.
Как
Существует множество ресурсов по адаптивному дизайну, в том числе оригинальная статья Итана Маркотта , сборник важных концепций, связанных с ним, а также множество книг и докладов. Чтобы сузить это обсуждение до контентных аспектов адаптивного дизайна, обратитесь к дизайну, ориентированному на содержание, и адаптивным макетам, ориентированным на содержание . Наконец, несмотря на то, что уроки из книги Джоша Кларка «Семь смертоносных мобильных мифов» ориентированы на мобильные устройства, они так же актуальны как для небольших просмотров адаптивных сайтов, так и для мобильных устройств в целом.
Когда пользователи находятся в автономном режиме, сохранение их в PWA обеспечивает более плавную работу, чем возврат к автономной странице браузера по умолчанию.
Почему
Пользователи ожидают, что установленные приложения будут работать независимо от статуса их подключения. Приложение для конкретной платформы никогда не отображает пустую страницу, когда оно находится в автономном режиме, а PWA никогда не должен показывать автономную страницу браузера по умолчанию. Предоставление индивидуального автономного опыта, как когда пользователь переходит по URL-адресу, который не был кэширован, так и когда пользователь пытается использовать функцию, требующую подключения, помогает вашему веб-интерфейсу чувствовать себя частью устройства, на котором он работает.
Как
Во время события install сервис-воркера вы можете предварительно кэшировать пользовательскую автономную страницу для последующего использования. Если пользователь отключается от сети, вы можете ответить предварительно кэшированной пользовательской автономной страницей. Вы можете воспользоваться нашим примером пользовательской автономной страницы , чтобы увидеть пример этого в действии и узнать, как реализовать его самостоятельно.
Пользователи, которые устанавливают или добавляют приложения на свои устройства, как правило, больше взаимодействуют с этими приложениями.
Почему
Установка Progressive Web App позволяет ему выглядеть, работать и вести себя так же, как и все другие установленные приложения. Он запускается из того же места, где пользователи запускают другие приложения. Он запускается в собственном окне приложения, отдельном от браузера, и отображается в списке задач, как и другие приложения.
Как и в случае с приложениями для конкретных устройств, пользователи, которые устанавливают ваши приложения, являются вашей наиболее заинтересованной аудиторией и часто имеют показатели вовлеченности, равные показателям пользователей приложений на мобильных устройствах. Эти показатели включают в себя больше повторных посещений, более длительное время пребывания на вашем сайте и более высокие коэффициенты конверсии, чем у обычных посетителей.
Как
Следуйте нашему руководству по установке , чтобы узнать, как сделать PWA доступным для установки.
Контрольный список оптимального прогрессивного веб-приложения
Чтобы создать действительно отличное PWA, которое будет выглядеть как лучшее в своем классе приложение, вам нужно нечто большее, чем просто основной контрольный список. Оптимальный контрольный список PWA заключается в том, чтобы ваше PWA чувствовало себя частью устройства, на котором оно работает, и при этом использовало преимущества того, что делает Интернет мощным.
Там, где подключение не является строго обязательным, ваше приложение работает в автономном режиме так же, как и в Интернете.
Почему
Помимо предоставления настраиваемой автономной страницы, пользователи ожидают, что PWA можно будет использовать в автономном режиме. Например, в приложениях для путешествий и авиакомпаний информация о поездке и посадочные талоны должны быть доступны в автономном режиме. Приложения для музыки, видео и подкастов должны поддерживать автономное воспроизведение. Социальные и новостные приложения должны кэшировать недавний контент, чтобы пользователи могли читать его в автономном режиме. Пользователи также ожидают, что они останутся аутентифицированными в автономном режиме, поэтому разработайте офлайн-аутентификацию. Автономное PWA обеспечивает пользователям удобство работы с приложениями.
Как
После определения того, какие функции ваши пользователи ожидают работать в автономном режиме, вам необходимо сделать свой контент доступным и адаптируемым к автономному контексту. Вы можете использовать IndexedDB , систему хранения NoSQL в браузере для хранения и извлечения данных, а также фоновую синхронизацию , чтобы позволить пользователям выполнять действия в автономном режиме и откладывать взаимодействие с сервером до тех пор, пока у пользователя снова не будет стабильное соединение. Вы также можете использовать сервис-воркеров для хранения других видов контента, таких как изображения, видеофайлы и аудиофайлы, для использования в автономном режиме, а также для реализации безопасных, долгоживущих сеансов для обеспечения аутентификации пользователей. С точки зрения пользовательского опыта вы можете использовать скелетные экраны , которые дают пользователям представление о скорости и контенте во время загрузки, а затем при необходимости могут вернуться к кэшированному контенту или индикатору автономного режима.
Все взаимодействия с пользователем соответствуют требованиям доступности WCAG 2.0 .
Почему
Большинство пользователей в какой-то момент своей жизни захотят использовать ваше PWA способом, предусмотренным требованиями доступности WCAG 2.0 . Способность людей взаимодействовать с вашим PWA и понимать его существует в широком спектре, и потребности могут быть временными или постоянными. Сделав PWA доступным, вы сделаете его доступным для всех.
Как
«Введение в веб-доступность» W3C — хорошее начало. Большую часть тестирования доступности необходимо выполнять вручную. Такие инструменты, как аудит доступности в Lighthouse, ax и Accessibility Insights , могут помочь вам автоматизировать некоторые проверки доступности. Также важно использовать семантически правильные элементы вместо того, чтобы воссоздавать их самостоятельно, например элементы a и button . Это гарантирует, что когда вам понадобится создать более продвинутые функции, ожидания доступности оправдаются (например, когда использовать стрелки, а не вкладки). В Картах питания A11Y есть отличные советы по этому поводу для некоторых распространенных компонентов.
Ваш PWA можно легко найти с помощью поиска .
Почему
Одним из самых больших преимуществ Интернета является возможность находить сайты и приложения с помощью поиска. Фактически, более половины всего трафика веб-сайта приходится на органический поиск. Чтобы потенциальные пользователи могли найти ваш PWA, крайне важно убедиться, что для контента существуют канонические URL-адреса и что поисковые системы могут индексировать ваш сайт. Это особенно актуально при рендеринге на стороне клиента.
Как
Начните с обеспечения того, чтобы каждый URL-адрес имел уникальный описательный заголовок и метаописание. Затем вы можете использовать консоль поиска Google и аудит поисковой оптимизации в Lighthouse для отладки и устранения проблем с обнаружением вашего PWA. Вы также можете использовать инструменты владельца сайта Bing или Yandex и рассмотреть возможность включения структурированных данных с использованием схем из Schema.org в ваш PWA.
PWA одинаково можно использовать с мышью, клавиатурой, стилусом или сенсорным экраном.
Почему
Устройства предлагают различные методы ввода, и пользователи должны иметь возможность плавно переключаться между ними во время использования вашего приложения. Не менее важно и то, что методы ввода не должны зависеть от размера экрана, а это означает, что большие области просмотра должны поддерживать сенсорный ввод, а маленькие области просмотра должны поддерживать клавиатуру и мышь. В меру своих возможностей убедитесь, что ваше приложение и все его функции поддерживают использование любого метода ввода, который может выбрать пользователь. При необходимости улучшите возможности взаимодействия, чтобы обеспечить возможность управления конкретными входными данными (например, обновление по запросу).
Как
API событий Pointer предоставляет унифицированный интерфейс для работы с различными параметрами ввода и особенно удобен для добавления поддержки стилуса. Для поддержки как сенсорного ввода, так и клавиатуры убедитесь, что вы используете правильные семантические элементы (привязки, кнопки, элементы управления формой и т. д.) и не перестраиваете их с помощью несемантического HTML. Добавляя взаимодействия, которые активируются при наведении курсора, убедитесь, что они также могут активироваться при нажатии или касании.
Запрашивая разрешение на использование мощных API, указывайте контекст и спрашивайте только тогда, когда API необходим.
Почему
API-интерфейсы, которые запускают запрос разрешения, такие как уведомления, геолокация и учетные данные, намеренно разработаны так, чтобы мешать пользователю, поскольку они, как правило, связаны с мощными функциями, требующими согласия. Запуск этих подсказок без дополнительного контекста, например, при загрузке страницы, снижает вероятность того, что пользователи примут эти разрешения и с большей вероятностью не будут им доверять в будущем. Вместо этого запускайте эти запросы только после предоставления пользователю контекстного обоснования того, почему вам нужно это разрешение.
Как
Статья «Разрешение UX» и «Правильные способы запроса разрешений у пользователей» на сайте UX Planet — хорошие ресурсы для понимания того, как разрабатывать запросы разрешений, которые, хотя и ориентированы на мобильные устройства, применимы ко всем PWA.
Поддержание работоспособности вашей кодовой базы облегчает достижение ваших целей и предоставление новых функций.
Почему
Создание современного веб-приложения требует очень многого. Поддержание вашего приложения в актуальном состоянии и работоспособность вашей кодовой базы облегчит вам предоставление новых функций, которые соответствуют другим целям, изложенным в этом контрольном списке.
Как
Существует ряд высокоприоритетных проверок для обеспечения работоспособности кодовой базы:
- Избегайте использования библиотек с известными уязвимостями.
- Убедитесь, что вы не используете устаревшие API.
- Удалите небезопасные методы кодирования из вашей кодовой базы (например, использование
document.write()или использование непассивных прослушивателей событий прокрутки), - Вы даже можете написать защитный код, чтобы гарантировать, что ваше PWA не сломается, если аналитика или другие сторонние библиотеки не загрузятся.
- Рассмотрите возможность статического анализа кода, такого как линтинг, а также автоматического тестирования в нескольких браузерах и каналах выпуска. Эти методы могут помочь обнаружить ошибки до того, как они попадут в производство.