Технология SPA: почему вместо обычных сайтов нужно делать веб-приложения
Три года назад в команде panfilov.digital мы произвели переход в разработке веб-проектов от монолитной архитектуры к Single Page Application. В статье расскажу, как это помогает нам делать сайты клиентов быстрее и удобнее для пользователей.
Single Page Application (SPA) — архитектура, которая позволяет создавать гибкие веб-приложения с высокой скоростью работы.
Удобство SPA обусловлено тем, что это приложение открывается в любом браузере, как и обычный сайт. Но пользовательский опыт отличается. Посетитель при навигации по сайту фактически остаётся на одной странице, на которой по его запросу меняется контент. Это заметно ускоряет работу сайта.
Чем SPA отличается от обычного сайта
Как работают обычные сайты: когда пользователь кликает по ссылкам, направляется запрос на сервер, тот в ответ присылает страницы и их показывает браузер. Каждый раз при переходе между страницами весь код сайта загружается полностью с нуля: шапка, контент, подвал.
SPA работает иначе: когда сайт впервые открывается, браузер загружает весь код веб-приложения. А если пользователь кликнет на ссылку, чтобы перейти к другой странице, то в браузер подгружается только новый контент и вся страница полностью не перезагружается.
Поскольку загрузка кода происходит один раз, обмен данными с сервером получается экономичным с точки зрения трафика. Часть данных можно кэшировать — тогда загрузка будет ещё быстрее.
Чтобы увидеть SPA на практике, откройте почту Gmail. Походите по разным папкам: «Входящие», «Отправленные», «Черновики». Содержимое страницы меняется, но она не грузится каждый раз заново. Почта работает быстро. Точно так же увидеть SPA можно увидеть на сайте соцсетей, например, VK. При переходе между разделами страница не перезагружается.
Плюсы и минусы SPA
- SPA быстрые. Пользователи не ждут, когда загрузится очередная страница веб-приложения, а быстро получают контент.
- Скорость выше и с точки зрения разработки. Неважно, многостраничный это сайт, лендинг, визитка или блог. SPA быстрее сверстать и запустить с использованием JavaScript-фреймворков. Для компании, где сидит больше одного разработчика, это выгодно.
- SPA универсальные. Для работы сайта нужна только поддержка JavaScript в браузере. Проект проще масштабировать, можно даже использовать код веб-приложения для запуска мобильного приложения.
- SPA гибкие. Архитектура подразумевает разделение на фронтенд и бэкенд.
Бэкендерам не нужно думать о том, как вывести данные для пользователей. Они концентрируются на бизнес-логике и работе с базой данных.
У фронтендеров появляется больше возможностей для управления сайтом. Например, они могут быстро и без костылей реализовать в интернет-магазине корзину неавторизованного пользователя или применение бонусной карты.
- Увеличивается трафик — пользователям приходится загружать больше на свои устройства.
- Для разработки SPA требуются фронтендеры, а не верстальщики. Недостаточно накидать HTML-теги и стилизовать их. Нужно знать фреймворки и понимать, что происходит на сервере.
Со всеми недостатками можно справиться. На примере своих проектов расскажем, как переходили от монолита к SPA, чему научились и как изменилась команда.
Как мы перешли от монолитной архитектуры к SPA
Команда panfilov.digital много лет работала с CMS 1С-Битрикс. Из-за особенностей этого движка у нас не было разделения на фронтенд и бэкенд. Верстальщик отдавал HTML-шаблоны, программист интегрировал их в компоненты. Но мы видели, что технологии идут вперёд, и понимали, что такая монолитная архитектура в долгосрочной перспективе нежизнеспособна.
В 2018 году издательство «Эксмо», один из наших давних клиентов, пришёл с задачей ускорить чекаут на Book24.ru. Интернет-магазин работал на Битриксе, у него было очень много интеграций: скидки, бонусы, доставка. Когда всё это выгружалось на одну страницу, движок зависал, портился UX, снижалась конверсия. Чтобы сделать подгрузки асинхронными, мы применили на фронте Vue.js.
Если вы хотите с нуля освоить профессию frontend-разработчика на Vue.js и получить гарантированное трудоустройство — приглашаю вас на программу обучения panfilov.academy.
Выбрали Vue.js потому, что это прогрессивный фреймворк, у которого устоявшаяся экосистема и низкий порог входа. Если простыми словами, не нужно подключать сторонние библиотеки для разработки полноценного веб-приложения. Мы попробовали фреймворк на проекте «Эксмо», получилось хорошо — повысилась конверсия в заказ из-за ускорения и асинхронной загрузки модулей в корзине.
SSR для SEO
Чтобы подружить SPA-сайты с поисковыми системами и ускорить загрузку, используется Server Side Rendering (SSR). Сервер генерирует код страницы и отдаёт его поисковым роботам и пользователю. Рендеринг страницы на стороне сервера — это хорошо для SEO, потому что поисковики сразу видят и индексируют контент.
Интернет-магазин Tervolina — наш главный старт в разработке SSR-приложений. Сайт собрали на Nuxt.js (это фреймворк для универсальных приложений Server Side Rendering на Vue). Получился интернет-магазин, который выводит новые товары без перезагрузки страницы и длительного ожидания. Мы показали, что такой подход работает быстрее, улучшает UX, позволяет асинхронно загружать данные из внешних источников.
Процесс технологического перехода на SPA сопровождался организационными изменениями. Начиная с проекта для Tervolina, фронтендеры берут на себя больше обязательств. Они не верстальщики, а программисты, которые занимаются в том числе обработкой данных. Разделение на фронтендеров и бэкендеров позволило отказаться от Битрикса и перейти на более современные фреймворки на бэкенде.
Оптимизируем загрузку
Следующий знаковый проект — Zyfra, сайт для интегратора промышленного интернета вещей. Его уникальность в том, что у всех страниц разные стили, отличается анимация. Чтобы увеличить скорость загрузки, реализовали сервер, который отдаёт картинки и другие данные каждой странице по отдельности.
Кроме того, мы научились отдавать видео потоком, как на YouTube. Пользователь прогружает видео, только когда начинает его смотреть. Также начали использовать форматы изображений WebP и видео WebM. Это помогло уменьшить трафик и оптимизировать работу сайта. Теперь используем эти подходы во всех проектах Single Page Application по умолчанию. Это заметно ускоряет скорость загрузки сайтов.
Разбираемся с SEO на SPA сайтах
Один из последних проектов — интернет-магазин стройматериалов Akvilon. Здесь мы в том числе решали задачи, связанные с SEO.
Нужно очень осторожно работать с тем, что веб-приложение показывает пользователю при SSR. Можно переоптимизовать страницы, расставив везде шиммеры — блоки, которые отображаются до загрузки контента. Это убивает SEO: поисковики получают набор пустых блоков. Почему SPA для SEO не очень: основные поисковики умеют парсить нативные сайты, но делают это с трудом.
При решении проблемы SEO на SPA на выручку приходит концепция гибридного приложения. Когда пользователь заходит на сайт, мы отрисовываем страницу на сервере и отдаём ему готовую вёрстку. Когда пользователь дальше идёт по сайту, это уже происходит в режиме SPA. Благодаря этому SEO работает отлично, все поисковики индексируют страницы, а пользователь наслаждается быстрой работой сайта.
Фактически мы сами решаем, что показать пользователю и поисковикам в первую очередь. Если какие-то блоки нужны только пользователям, но не важны для SEO, можем подгружать их позже.
Что дальше
Мы продолжаем совершенствовать технологии, применяя SPA: например, начали использовать в программировании TypeScript.
Некоторые последние проекты мы пишем полностью на TypeScript. Он не даёт разработчикам совершать глупые ошибки, характерные для JavaScript, когда, например, программа ожидает один тип данных, а получает другой. Это уменьшает затраты на тестирование.
Ещё мы начали применять веб-технологии для разработки гибридных мобильных приложений. Архитектура SPA здесь очень помогает, потому что методы API, которые используются на сайте, можно без изменений подключать в мобильное приложение.
Есть несколько решений для мобильной разработки. Самое передовое — React Native. Зная React, можно писать на React Native приложения для мобильных устройств.
Такие фреймворки, как React Native, удешевляют разработку на другие устройства. Десктопные приложения тоже можно писать на Vue и на React, есть готовые решения Nuxt.js. По факту, используя один фреймворк, можно писать для веба, смартфона и компьютера.
Вывод: почему следует выбирать SPA
Архитектура Single Page Application даёт гибкость. Не имеет значения, что на бэкенде. Можно использовать одни и те же подходы при создании приложений для веба, смартфона, компьютера. При этом скорость разработки SPA приложений повышается за счёт того, что мы используем лучшие практики, адаптируя их под разные проекты.
Переход от монолита к SPA потребовал от нас организационных изменений. Но это было необходимо, чтобы решать новые сложные задачи при разработке. Клиентам нужны быстрые сайты, которыми комфортно пользоваться. SPA помогает достигнуть такого результата.
- Как примерно оценить стоимость разработки
- Как написать техническое задание на разработку
- Как запустить объемную фичу по частям
Автор — Максим Панфилов, предприниматель, основатель и директор студии разработки panfilov.digital. Компания с 2013 работает с крупными заказчиками в России и Казахстане: выводит на рынок и развивает ИТ-проекты.
Подписаться в Telegram → @panfilovonline
Связаться с автором → @mpanfilov