Что делает прогрессивное веб-приложение хорошим?

Progressive Web Apps (PWA) созданы и улучшены с помощью современных API, чтобы обеспечить расширенные возможности, надежность и удобство установки, охватывая при этом любого, где угодно, на любом устройстве с единой кодовой базой. Чтобы помочь вам создать наилучший возможный опыт, используйте основные и оптимальные контрольные списки и рекомендации, которые помогут вам.

Контрольный список основных прогрессивных веб-приложений

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

Быстро стартует, быстро остается

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

Почему

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

Хотя у всех приложений разные потребности, аудиты производительности в Lighthouse основаны на Core Web Vitals , и высокие баллы по этим аудитам сделают так, что ваши пользователи с большей вероятностью получат приятный опыт. Вы также можете использовать PageSpeed ​​Insights или Chrome User Experience Report, чтобы получить реальные данные о производительности для вашего веб-приложения.

Как

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

Работает в любом браузере

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

Почему

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

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

Возьмем, к примеру, отправку формы. Самый простой способ реализовать это — HTML-форма, которая отправляет запрос POST . После ее создания вы можете улучшить опыт с помощью JavaScript, чтобы выполнить проверку формы и отправить форму через AJAX, улучшив опыт для пользователей, которые могут его поддерживать.

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

Как

Книга Джереми Кейта «Гибкий веб-дизайн» — это прекрасный ресурс, описывающий, как следует мыслить в области веб-дизайна с использованием этой кроссбраузерной, прогрессивной методологии.

Дополнительное чтение

Адаптивность к любому размеру экрана

Пользователи могут использовать ваше PWA на экранах любого размера, и весь его контент будет доступен при любом размере области просмотра.

Почему

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

Задачи, которые пользователи хотят выполнить, и контент, к которому они хотят получить доступ, не меняются с размером области просмотра. Вы можете переупорядочить свой контент для разных размеров области просмотра, и все это должно быть там, так или иначе. Фактически, как утверждает Люк Вроблевски в своей книге Mobile First , начав с малого и подстроив свой дизайн под большие экраны, можно улучшить дизайн сайта:

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

Как

Существует множество ресурсов по адаптивному дизайну, включая оригинальную статью Итана Маркотта , подборку важных концепций, связанных с ним, а также множество книг и докладов. Чтобы сузить это обсуждение до аспектов контента адаптивного дизайна, обратитесь к content-first design и content-out responsive layouts . Наконец, хотя он и сосредоточен на мобильных устройствах, уроки из Seven Deadly Mobile Myths Джоша Кларка так же актуальны для небольших видов адаптивных сайтов, как и для мобильных устройств в целом.

Предоставляет настраиваемую офлайн-страницу

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

Почему

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

Как

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

Можно установить

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

Почему

Установка Progressive Web App позволяет ему выглядеть, ощущаться и вести себя как все другие установленные приложения. Он запускается из того же места, где пользователи запускают свои другие приложения. Он работает в своем собственном окне приложения, отдельно от браузера, и отображается в списке задач, как и другие приложения.

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

Как

Следуйте нашему руководству по установке , чтобы узнать, как сделать PWA устанавливаемым.

Контрольный список оптимального прогрессивного веб-приложения

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

Обеспечивает офлайн-опыт

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

Почему

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

Как

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

Полностью доступен

Все взаимодействия с пользователем соответствуют требованиям доступности WCAG 2.0 .

Почему

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

Как

Введение в веб-доступность W3C — хорошее место для начала. Большинство проверок доступности необходимо выполнять вручную. Такие инструменты, как аудит доступности в Lighthouse, axe и Accessibility Insights, могут помочь вам автоматизировать некоторые проверки доступности. Также важно использовать семантически правильные элементы вместо того, чтобы воссоздавать эти элементы самостоятельно, например, элементы a и button . Это гарантирует, что когда вам понадобится создать более сложные функции, ожидания доступности будут выполнены (например, когда использовать стрелки, а когда вкладки). A11Y Nutrition Cards дает отличные советы по этому поводу для некоторых распространенных компонентов.

Можно найти через поиск

Ваше PWA можно легко найти с помощью поиска .

Почему

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

Как

Начните с того, что убедитесь, что каждый URL имеет уникальный, описательный заголовок и метаописание. Затем вы можете использовать Google Search Console и аудиты поисковой оптимизации в Lighthouse для отладки и исправления проблем с обнаружением в вашем PWA. Вы также можете использовать инструменты владельца сайта Bing или Yandex и рассмотреть возможность включения структурированных данных с использованием схем из Schema.org в ваш PWA.

Работает с любым типом ввода

Ваше PWA можно использовать с помощью мыши, клавиатуры, стилуса или сенсорного экрана.

Почему

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

Как

Pointer Events API предоставляет унифицированный интерфейс для работы с различными вариантами ввода и особенно хорош для добавления поддержки стилуса. Для поддержки как сенсорного ввода, так и клавиатуры убедитесь, что вы используете правильные семантические элементы (якоря, кнопки, элементы управления формами и т. д.) и не перестраиваете их с помощью несемантического HTML. При включении взаимодействий, которые активируются при наведении, убедитесь, что они также могут активироваться при щелчке или касании.

Предоставляет контекст для запросов на разрешения

Запрашивая разрешение на использование мощных API, предоставляйте контекст и спрашивайте только тогда, когда API действительно необходим.

Почему

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

Как

Статья «Разрешения UX» и статья UX Planet «Правильные способы запрашивать у пользователей разрешения» — хорошие ресурсы для понимания того, как разрабатывать запросы разрешений, которые, хотя и ориентированы на мобильные устройства, применимы ко всем PWA.

Соблюдает лучшие практики для создания здорового кода

Поддержание работоспособности кодовой базы упрощает достижение ваших целей и внедрение новых функций.

Почему

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

Как

Существует ряд высокоприоритетных проверок для обеспечения работоспособности кодовой базы:

  • Избегайте использования библиотек с известными уязвимостями.
  • Убедитесь, что вы не используете устаревшие API.
  • Удалите небезопасные методы кодирования из вашей кодовой базы (например, использование document.write() или наличие непассивных прослушивателей событий прокрутки),
  • Вы даже можете написать защитный код, чтобы гарантировать, что ваше PWA не выйдет из строя в случае сбоя загрузки аналитических или других сторонних библиотек.
  • Рассмотрите необходимость статического анализа кода, например линтинга, а также автоматизированного тестирования в нескольких браузерах и каналах релиза. Эти методы могут помочь обнаружить ошибки до того, как они попадут в производство.