На днях я проходился по своим старым проектам для портфолио и зашёл на один из сайтов, который делал более четырёх лет назад. Сайт обновился, новый дизайн, контент, страницы. Что раньше, что сейчас это — контентный сайт, он состоит из текста, картинок, формы обратной связи. Есть несколько интерактивных элементов, таких как карусель с карточками, аккордеоны, выпадающее меню. Самое сложное с точки зрения интерактива — калькулятор.
Когда я делал этот сайт, это была обычная вёрстка, интегрированная в WordPress. Клиент решил обновить сайт и обратился к веб-студии. Они разработали новый контентный сайт в виде SPA… Сайт из 5 страниц с текстом, картинками, видео и парочкой интерактивных элементов сделан как SPA. Кажется, что в индустрии стало нормой забивать гвозди микроскопом, а разработчиков с микроскопом в руках это особо не заботит.
Что плохого в SPA для сайтов?
- Контент состоит из
<div id="app"></div>. Получается, что на контентном сайте изначально нет контента. Краулеры, парсеры и прочие сканеры страниц ничего не видят. Google умеет обрабатывать такие сайты, но задействует специальный механизм, который работает дольше и хуже. С другими поисковиками ситуация сложнее. В итоге наработанные ранее позиции сайта в выдаче будут потеряны.- Контент завязан на JavaScript. Если по тем или иным причинам JavaScript недоступен, сайт вы не увидите. Золотое правило веб-разработки: HTML для контента и структуры, CSS для внешнего вида, JavaScript для интерактивности. Использование JavaScript для контента добавляет больше проблем, чем даёт плюсов. Переходы между страницами без перезагрузки не стоят того.
- Плохие метрики Core Web Vitals. Конкретно у нового сайта First Contentful Paint 2.1-2.9c, Largest Contentful Paint 7.5-8.2c. То есть усреднённый пользователь видит сайт только через 2-3 секунды, а изображение на станице через 8 секунд. И это на небольшой странице. Core Web Vitals влияют на SEO и восприятие пользователей. А в будущем у сайта начнутся проблемы с производительностью, когда маркетологи добавят туда скрипты для аналитики и рекламы.
- Лишняя сложность. Для вывода статического контента зачем-то нужен условный React, хуки, JSX, для переключения страниц нужен отдельный пакет с роутером и его настройка, для стилей нужен пакет с хитрой обработкой под капотом, для работы всего этого нужен сборщик с сложной конфигурацией. И весь этот оверхед для вывода статического контента.
- Налог на фреймворк. С фреймворком приходят мегабайты зависимостей в
node_modules, сложная сборка и ограничения экосистемы. Попробуйте вернуться с доработками на сайт через пол года. Получите кучу ошибок в консоли при попытке запустить всё это дело. Маленькие правки сайта превращаются в борьбу с зависимостями и инструментарием.- Работа в браузере. При SPA-подходе основная логика выполняется у клиента на устройстве. Это в свою очередь нагружает процессор, забивает основной поток выполнения, влияет на потребление батареи и т.д. Зачем выполнять лишний код, если можно просто отдать готовый контент?
Мой посыл: не делайте контентные сайты как SPA. Отдавайте предпочтение Static Site Generation (SSG) или Server Side Rendering (SSR). Генерируйте и отдавайте с сервера готовый HTML, подключайте внешний CSS и сверху точечно добавляйте JS для интерактивных компонентов. Это во всех смыслах работает лучше и быстрее. А SPA оставьте для комплексных приложений со сложным интерфейсом и взаимодействиями.