Недавно я начал сотрудничать с командой, владеющей сервисом, цель которого - сблизить местный бизнес. Я советую им, как добиться большего присутствия в Интернете, и, поскольку основной задачей команды было разделить приложение, это казалось хорошей возможностью переосмыслить технический стек и методологии.
Инжиниринг для лучшего пользовательского опыта
Конечная цель нашего развития - это люди, использующие наш веб-сайт, и преимущества, которые они могут получить как пользователи. Когда мы думаем о различных проблемах на сайте, мы можем адаптировать опыт, и по умолчанию он определяет инженерные решения. Этот этап концептуализации следует этическим рамкам, касающимся бизнес-модели и политики данных пользователей, среди прочего.
Разделение проблем и разделенная архитектура
После легкой переделки пользовательского интерфейса и пользовательского интерфейса приложения (на данном этапе мы не хотели слишком сильно менять привычки пользователей), мы решили использовать два разных веб-приложения: одно предназначено для общедоступного контента, а другое сосредоточено на бэкэнд-функции, такие как управление контентом, оплата, возможности социальных сетей. Эта архитектура ознаменовала разделение задач между страницами, на которые распространяются ограничения SEO, и страницами, обслуживающими более широкий спектр функций, но не подверженными поисковым роботам.
Чтобы решить эту проблему, было создано руководство по стилю, основанное на принципах «атомарного дизайна», которое затем было преобразовано в библиотеку сквозных веб-компонентов, живущих независимо от двух сборок. Мы разместили систему проектирования на NPM, чтобы упростить управление версиями и распространение среди разработчиков, которые могут выбрать необходимые компоненты для своей работы.
Система и методология дизайна
Вот как мы могли бы резюмировать итерационный процесс:
Как обычно, тонкий баланс заключается в выборе между глобально распределенными и локальными стилями и методами, а также между компонентами только для чтения и интерактивными компонентами - по сути, между универсальностью и производительностью. Функциональные характеристики включали перетаскивание, переупорядочивание списка, загрузку и обрезку изображений, представление 3D-объектов и многое другое.
Область видимости и современные модули CSS
Наша библиотека компонентов основана на принципах атомарного дизайна, при этом CSS написан в компонентах бок о бок с частями JS. Поскольку логика каскадирования ограничена, этот подход обеспечивает более прогрессивную загрузку ресурсов, меньшую взаимозависимость и большую стабильность.
Последние мощные модули CSS, такие как Grid и Flexbox, а также размер шрифта на основе REM сокращают количество кода и (почти) отменяют переопределения в @mediaqueries. Все в одном и с помощью имен классов, вырезанных из сценария в производственной среде, выгода составляет около 80% от созданного CSS. Система значков SVG, использование переменных CSS и особое внимание к функциям разметки и доступности завершают усилия по созданию высококачественной системы компонентов.
Загрузка и кеширование
Современное приложение предлагает усовершенствованные параметры, когда речь идет о предварительном подключении, предварительной выборке или предварительной загрузке ресурсов. Девизом могло быть «как можно меньше, как можно раньше». Мы должны доставлять только те ресурсы, которые нам нужны, и мы должны стремиться к тому, чтобы они были доставлены прямо до того, как они нам понадобятся. Скорость и бережливость передачи данных между клиентом и сервером сохраняют использование полосы пропускания, делая всю экосистему более быстрой и устойчивой. Например, чтобы улучшить отзывчивость навигации, когда ссылка на страницу отображается в области просмотра, автоматически извлекается код разделения соответствующей страницы и начинается предварительная загрузка ресурсов.
Добавление Service Workers обрабатывает автономно возможности и позволяет лучше контролировать кэширование статических ресурсов. Эти меры гарантируют быструю и бесперебойную работу асинхронных веб-компонентов.
GraphQl как язык запросов
GraphQL - это язык запросов и манипулирования данными с открытым исходным кодом для API, разработанный внутри Facebook в 2012 году до публичного выпуска в 2015 году. Сила GraphQL заключается в том, что он позволяет клиентам запрашивать именно то, что им нужно, и ничего более. Эта возможность является невероятным улучшением для обмена с API, особенно в случае фрагментированных схем данных по маршрутизации.
С другой стороны, GraphQl может значительно упростить запросы при отправке данных обратно на сервер, особенно когда следует логика.
Централизованное хранилище данных
Хранилище данных на стороне клиента (которое централизует данные и основную логику нашего приложения) отделяет запросы к различным API-интерфейсам, предлагая возможности кэширования и сохранения. После этого данные доступны в любом месте и в любое время без необходимой корреляции с отображаемыми страницами. Таким образом, хранилище данных предлагает идеально оптимизированный дизайн для персонализации, предотвращает распространение сторонних скриптов в системе компонентов, дает больше возможностей для творчества и делает все приложение умнее и удобнее в обслуживании.
Путешествие пользователей и персонализация
Наличие доступа к состояниям в любом месте приложения в любой момент времени дает невероятные перспективы для персонализации и путешествия пользователя. Будь то геолокация, привязка к определенным категориям продуктов, CRM или аналитика данных, все можно объединить для создания сценариев желаемой бизнес-логики. В нашем случае профили и предложения влиятельных лиц географически привязаны, что сокращает использование карт и локаторов, требует меньшего количества навигации и меньшего количества кликов и, таким образом, улучшает опыт и скорость преобразования.
Изоморфизм и SEO
Известная слабость веб-приложений - индексация контента. Из-за своей асинхронной природы контент не открывается для поисковых роботов во время их посещений. Затем мы выполняем рендеринг на стороне сервера для генерации каждого маршрута и вызова «изоморфных» компонентов, которые могут обрабатывать как рендеринг на сервере, так и их отображение и логику на стороне клиента. С помощью современных фреймворков javascript с SSR можно сравнительно легко справиться, и этот вид серверной автоматизации сочетает в себе лучшее из обоих миров. Тот факт, что отображается первое загруженное представление - с встроенным в него CSS над сгибом - это большое улучшение производительности, особенно в отношении первой отрисовки содержимого. Кроме того, мы решили предоставлять структурированные данные через схемы JSON-LD, доступные на schema.org, сообществе сотрудничества, которое создает, поддерживает и продвигает схемы для структурированных данных. Эти схемы могут затем использоваться поисковыми системами для устранения неоднозначности элементов и установления фактов, связанных с объектами. Эти объекты, в свою очередь, создают богатые результаты поиска. На относительно плоской карте сайта приложения мы используем схемы «Организация», «Веб-сайт», «Веб-страница» и «Местный бизнес», указывая поисковым системам такую информацию, как диапазон цен, доступность, рейтинги, геолокацию, дни работы и более.
Некоторые отзывы
"Источник"
Trivago: с тех пор, как Trivago обновила свой веб-сайт с помощью PWA, более 500 000 человек добавили ярлык Trivago на свой домашний экран, и их участие увеличилось на 150%. Push-уведомления оказались идеальным средством коммуникации и повышения конверсии - количество переходов на сайт по предложениям отелей увеличилось на 97%.
Pinterest: Затраченное время выросло на 40% по сравнению со старым мобильным веб-интерфейсом, доход от рекламы, генерируемой пользователями, вырос на 44%, а количество основных взаимодействий выросло на 60%.
Twitter: показатель отказов снизился на 20%, количество страниц за сеанс выросло на 65%, а количество отправленных твитов выросло на 75%.
Необходимый шаг в веб 4.0
Поскольку многие службы обращаются к искусственному интеллекту и машинному обучению, возможности веб-приложений должны соответствовать требованиям этой новой веб-эры. Графические интерфейсы будут использоваться реже, но, что более важно, для других целей. Веб-приложения будут все чаще пересекаться потоками данных из самых разных источников, и дизайн-системы должны будут жить и работать в более разнообразных контекстах. Также велика вероятность, что веб-приложения со временем заменят нативные приложения, превратившись в идеальное сочетание нативного приложения и веб-сайта. Все эти факторы сходятся в необходимости базировать онлайн-решения на системах модульного проектирования и асинхронной механике для создания перспективного и недорогого адаптируемого технологического стека.
Спасибо, что прочитали меня :-)
