В истории веб-платформы было несколько поворотных моментов, которые радикально изменили способ создания, развертывания и использования веб-приложений. Ajax был одним из таких поворотных моментов, которые привели к глубокому сдвигу в веб-инженерии. Это позволило веб-приложениям быть достаточно отзывчивыми, чтобы бросить вызов обычным настольным приложениям. Однако на мобильных устройствах опыт был определен нативными приложениями, и веб-приложения вряд ли были им близки, по крайней мере, до сих пор. Команда разработчиков мобильных приложений Flipkart обнаружила, что при правильном наборе возможностей в браузере мобильное веб-приложение может быть таким же производительным, как и собственное приложение.
Благодаря усилиям Extensible Web Manifesto по сокращению цикла обратной связи между редакторами веб-стандартов и веб-разработчиками поставщики браузеров начали внедрять новые низкоуровневые API-интерфейсы на основе отзывов разработчиков. С появлением этих API-интерфейсов в Интернете появились беспрецедентные возможности. Мы в Flipkart решили жить на этом переднем крае и создать действительно мощное и технически продвинутое веб-приложение, одновременно работая над дальнейшим развитием этих API.
Вот краткая информация о том, как мы создали чрезвычайно захватывающее, увлекательное и высокопроизводительное приложение.
Иммерсивный. Несмотря на то, что нативные приложения удобны, за их установку приходится платить. Хотя веб-приложения решили проблему мгновенного доступа, сетевое подключение по-прежнему играет важную роль в определении опыта работы в Интернете. В прошлом было несколько попыток включить автономные веб-приложения, такие как AppCache и использование LocalStorage / IndexedDB. Однако эти решения не смогли смоделировать сложные варианты автономного использования, описанные ниже, что затрудняет разработку и отладку проблем. Сервис-воркеры заменяют эти подходы, предоставляя в браузере сетевой прокси с поддержкой сценариев, который позволяет обрабатывать запросы программно. С помощью Service Workers мы можем перехватывать каждый сетевой запрос и обслуживать ответ из кеша, даже когда пользователь не в сети.
Мы решили использовать SW-Toolbox, библиотеку-оболочку Service Workers, которая позволяет использовать простые шаблоны, такие как NetworkFirst, CacheFirst или NetworkOnly. SW-Toolbox предоставляет кеш LRU, используемый в нашем приложении для хранения предыдущих результатов поиска на странице просмотра и нескольких последних посещенных страницах продуктов. В наборе инструментов также есть механизм недействительности кэша на основе TTL, который мы используем для очистки устаревшего содержимого. Service Workers предоставляют низкоуровневые скриптовые примитивы, которые делают это возможным.
Заставить правильное решение работать было так же сложно, как и придумать его. Мы столкнулись с широким спектром проблем, от проблем с реализацией до ошибок в инструментах разработки. Мы активно сотрудничаем с поставщиками браузеров для решения этих проблем.
Одна из таких серьезных проблем, которые возникли в результате использования нами Service Workers, заключалась в создании «аварийного выключателя». Легко получить ошибки в Service Workers и устаревшие ответы. Наличие надежного механизма очистки всех кешей помогло нам заранее подготовиться к любым непредвиденным обстоятельствам или неожиданностям.
Еще одним краеугольным камнем по-настоящему захватывающего опыта является полноэкранный автономный режим, запускаемый прямо с домашнего экрана. Это то, что позволяет нам сделать запрос Добавить на главный экран (ATHS). Когда пользователь выбирает добавление на главный экран, браузер создает высококачественный значок на главном экране на основе метаданных в Веб-манифесте. Подсказка ATHS отображается автоматически для пользователя на основе эвристики, специфичной для каждого браузера. В Chrome, если пользователь посетил сайт дважды в течение определенного периода, сработает запрос. В более новых версиях Chrome мы получаем событие после сопоставления эвристики и можем показать подсказку позже.
Хотя эвристика необходима для предотвращения спама на веб-платформе, мы сочли ее слишком консервативной и убедили команду Chrome настроить эвристику для наиболее часто встречающихся сценариев. Основываясь на наших отзывах, команда Chrome проводит эксперименты, чтобы сократить необходимую задержку между взаимодействиями.
Родные приложения используют заставку, чтобы скрыть медленную загрузку домашнего экрана. В Интернете никогда не было такой роскоши, и перед загрузкой домашнего экрана на пользователя смотрела пустая страница. Хорошая новость заключается в том, что последняя версия Chrome поддерживает создание заставки, которая радикально улучшает процесс запуска и воспринимаемую производительность веб-приложения.
Еще одна возможность, которую мы отстаиваем, - открытие внешних ссылок в автономной версии приложения, а не во вкладке браузера. В настоящее время существует ограничение для Android, но мы работаем с командой Chrome, чтобы как можно скорее реализовать этот вариант использования.
Вовлеченность: возможность повторно взаимодействовать с нашими пользователями в Интернете всегда была проблемой. С введением Web Push API у нас появилась возможность отправлять Push-уведомления нашим пользователям, даже когда браузер закрыт. Это возможно из-за Service Workers, которые живут дольше времени жизни браузера.
Высокая производительность: высокопроизводительное мобильное приложение - это приложение, которое запрашивает меньше данных по сети и требует меньше времени для обработки. Благодаря мощному прокси-серверу с поддержкой сценариев и постоянному кешу, хранящемуся в браузере, потребление данных из сети может быть значительно сокращено. Это также помогло снизить зависимость от мощности сети и устранить все задержки при повторном посещении.
Производительность рендеринга всегда была проблемой для Интернета. Мы обнаружили значительные улучшения в производительности, когда графический процессор обрабатывал растеризацию по сравнению с процессором. Поэтому мы решили использовать растеризацию графического процессора в Chrome (Project Ganesh, включив требуемый метатег в наш HTML). В то же время мы тщательно сбалансировали нужное количество композитных слоев с ускорением графического процессора, измерив композицию и стоимость краски. В-третьих, мы используем анимацию, совместимую с графическим процессором, а именно переходы Opacity и Transform.
Профилирование на различных мобильных устройствах с использованием панели временной шкалы Chrome Dev Tools и Chrome Tracing помогло нам выявить несколько узких мест и путей оптимизации. Это помогло нам максимально использовать каждый кадр во время анимации. Мы постоянно стремимся к созданию анимации и взаимодействия со скоростью 60 кадров в секунду. Мы используем модель RAIL для наших бюджетов производительности и стремимся соответствовать и превосходить ожидания по каждому из показателей.
Все это вместе дает нашим пользователям незабываемые впечатления. Это был замечательный путь создания этого веб-приложения, сотрудничества с поставщиками браузеров и расширения возможностей веб-платформы для мобильных устройств. В ближайшие недели мы планируем опубликовать более подробные посты, в которых будет подробно рассказано о технической архитектуре, шаблонах и, что наиболее важно, об извлеченных уроках.
Мы считаем, что все больше браузерных компаний и разработчиков начнут думать в этом направлении и делать веб-приложения еще лучше. Интернет - это действительно то, что вы делаете из него, и мы только начали.
