Разработка фронтенда ИТ-продукта: какой подход выбрать исходя из задач бизнеса

Подход к разработке фронтенда в продукте – уже давно не прихоть разработчика, а инструмент для решения бизнес-задачи. Расскажем простыми словами, почему это так, как выбор подхода зависит от назначения продукта, и приведем примеры.

Сразу оговоримся, что в этой статье не рассматриваются варианты использования конструкторов сайтов вроде Tilda или Webflow. Мы работаем с заказчиками, запросы которых эти инструменты покрыть не в состоянии. Поэтому речь пойдет о разработке более сложных ИТ-продуктов: highload проектов, личных кабинетов в B2B и автоматизации бизнеса.

Поговорим о приложениях, в которые пользователь заходит через логин: личный кабинет, внутренняя корпоративная система, CRM, ERP. Сюда же – интернет-банк, веб-интерфейс почты, личный кабинет на Озоне или Госуслугах, лента и переписка в соцсетях. Пользователь в таких приложениях видит данные, актуальные только для него. А индексация поисковиками для этих данных не нужна, поэтому используется метод клиентского рендеринга.

Клиентский рендеринг (client side rendering) или SPA (Single Page Application) – метод, при котором браузер загружает основную структуру страницы и код приложения один раз и генерирует HTML код страницы в самом браузере на устройстве пользователя.

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

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

Когда такие приложения становятся достаточно большими, первая загрузка приложения может растянуться на несколько секунд. Это минус, если сервис вы открываете много раз день (почта или CRM).

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

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

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

Отдельно отметим Progressive web apps (PWA): набор технологий, позволяющий максимально приблизить веб-приложения к привычным мобильным приложениям. Такой подход актуален сейчас, когда приложения регулярного удаляются из App Store и Google Play, а ограничить установку PWA-приложения не может никто.

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

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

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

Статическая генерация сайта (static site generation или SSG) – подход, при котором HTML код страниц генерируется один раз в момент публикации и сохраняется на сервере. Изменения в этой публикации не появляются (либо появляются очень редко), поэтому генерация «статическая». Дальше сервер будет моментально отдавать HTML код готовой страницы пользователям и поисковикам, гарантируя быструю загрузку страницы.

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

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

Портал, предназначенный для публикации большого количества индексируемого контента, с использованием статической генерации – это хорошо. Однако контент нужно редактировать и хранить. Для этого мы используем Headless CMS. Например, Strapi.

Один и тот же контент из Headless CMS таким образом можно переиспользовать под различные каналы. Например, на сайте, в мобильном приложении или в email-рассылке.

Другой плюс – проекты на Headless CMS может делать фронтенд- разработчик целиком. В нашей команде фронтенд разработчики сами настраивают структуру контента в Headless CMS и интегрируются с ней — этому достаточно легко научиться. Не нужно дополнительно привлекать, например, PHP бекенд-разработчика, как при разработке на Битрикс или WordPress.

Контент, который часто публикуется и обновляется на портале, тоже может требовать индексации и непрерывного поддержания актуальности. Например, так происходит в онлайн-магазинах, где часто меняются цены, актуальные позиции или скидки (привет, Озон!). Другой пример – сайты, где в основе пользовательский контент — форумы и площадки с объявлениями, типа hh.ru или Авито.

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

Серверный рендеринг (server side rendering / SSR) – подход, в котором страница генерируется на сервере при каждом запросе от пользователя.

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

Из этого вытекает потребность в более опытной и дорогой команде разработки.

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

Так, на сайте нашего проекта для Crystal Palace FC большинство контента генерируется статически. При этом отдельные блоки рендерятся в браузере. Это, например, индивидуальные для пользователя блоки или очень динамические сегменты.

Другой пример – использовать статическую генерацию и клиентский рендеринг для различных разделов сайта.

На одном из наших фронтендерских проектов – Seller Drive – портале для поставщиков Emex DWC, стартовая страница портала – индексируемая и общедоступная, поэтому реализована на статическом рендеринге. А вот личный кабинет, который становится доступен пользователю после аутентификации, мы построили уже на базе клиентского рендеринга.

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

Чтобы выбрать самый эффективный подход, стоит на этапе переговоров с подрядчиком быть максимально честным. Как на приеме у доктора. И здесь главное для клиента приходить с запросом не в виде решения («Разработайте мне новый сайт»), а в виде описания своей боли («Мой старый сайт совсем не приносит денег, помогите»).

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