Сравнение SPA с SSG и SSR
В чем разница между одностраничными приложениями (SPA), сайтами с визуализацией на стороне сервера (SSR) и сайтами на основе генератора статических сайтов (SSG)? Как они соотносятся по производительности, поисковой оптимизации, опыту разработчиков и гибкости? В этой статье мы даем вам подробное сравнение SPA, SSR и SSG, чтобы помочь вам принять обоснованное решение о том, какие стратегии использовать для вашего следующего фронтенд-проекта.
Три стратегии разработки приложений на JavaScript
Одностраничное приложение представляет собой оболочку HTML со сценарием, который заполняет страницу содержимым. Вместо всего, что приходит в HTML, браузеру нужно дождаться загрузки кода рендеринга JavaScript, такого как React или Vue, прежде чем он сможет отобразить контент. Фреймворки, такие как Create React App, используют этот подход, создавая шаблон, который просто связывает JavaScript со скелетом HTML, вместо того, чтобы генерировать полные HTML-страницы. Однако из-за задержки загрузки JavaScript контент часто загружается медленнее, что замедляет загрузку сайта в медленных сетях, что может ухудшить взаимодействие с пользователем и привести к тому, что некоторые люди уйдут до того, как сайт загрузится.
Чтобы преодолеть эту задержку, такие фреймворки, как Next.js, Nuxt и SvelteKit, предлагают рендеринг на стороне сервера и генерацию статического сайта. Этот подход больше похож на традиционный веб-сайт, где сервер отправляет клиенту HTML, предварительно созданный с помощью JavaScript, чтобы сделать его интерактивным/увлажнить его. Самая большая разница заключается в том, что вы можете написать приложение как SPA, и оно будет функционировать как SPA после загрузки JavaScript. Основное различие между сайтом SSG и сайтом SSR возникает при создании HTML. При использовании статически сгенерированного сайта он создается при компиляции проекта, поэтому вы получаете только статические файлы без необходимости сервера. Однако при подходе с рендерингом на стороне сервера сервер генерирует HTML-код по каждому запросу, что позволяет настраивать страницу в зависимости от пользователя без использования клиентского JavaScript, но требует наличия сервера.
Когда использовать каждый подход
Производительность
Чтобы обеспечить хорошее взаимодействие с пользователем, ваш сайт должен быть быстрым. Некоторые подходы быстрее, чем другие. В целом сайты SSG и сайты SSR быстрее, чем SPA, с точки зрения загрузки контента. SPA, как упоминалось ранее, должны загрузить JavaScript для приложения, прежде чем они смогут отображать контент. Однако в некоторых случаях SSG и SSR могут работать медленнее. Поскольку сервер отправляет HTML вместе с JavaScript, код в некоторой степени дублируется. Это означает, что общий загруженный файл больше, что замедляет время до взаимодействия (TTI). Независимо от увеличения размера файла, SSG и SSR обычно работают лучше из-за более быстрого времени загрузки контента. Следует также отметить, что сайты SSR иногда могут работать медленнее из-за того, что файлы требуют рендеринга при каждом запросе. Однако это можно смягчить, используя такие стратегии, как граничные вычисления.
- SPA: лучший TTI, но, как правило, не лучший, потому что весь JavaScript должен быть загружен, прежде чем его можно будет запустить, увеличивая наибольшее содержание и первую отрисовку содержимого (GCP/LCP). Как правило, не лучший для производительности.
- SSG: в целом лучшая производительность. Скорость ответа сервера такая же высокая, как у SPA, но вы также получаете предварительно обработанный HTML. В некоторых крайних случаях это может быть медленнее, чем SPA из-за дублирования кода, но обычно это будет быстрее.
- SSR: хорошо влияет на производительность, хотя может быть медленнее, чем SSG. Производительность эквивалентна SSG, за исключением того, что SSR может добавить некоторую задержку из-за времени обработки сервера.
SEO
Чтобы ваш веб-сайт был найден, поисковые системы должны знать, какой на нем контент. Практика помощи сканерам поисковых систем в этом называется SEO (поисковая оптимизация). Есть много способов, которыми подход, который вы используете для создания сайта с помощью JavaScript-фреймворка, может помочь или навредить SEO. Это одно из мест, где СПА находятся в крайне невыгодном положении. Для экономии ресурсов и обеспечения максимальной безопасности поисковые системы часто ограничивают или полностью отключают выполнение JavaScript. В настоящее время робот Googlebot поддерживает JavaScript, но некоторые более мелкие поисковые системы не поддерживают его. Поскольку SSR и SSG предоставляют контент, уже представленный в виде HTML, поисковые системы могут сканировать сайт без особых усилий. Однако даже с SSG и SSR вам все равно нужно делать такие вещи, как внедрение метатегов, чтобы убедиться, что ваше приложение имеет хорошее SEO.
- SPA: не очень хорошо, особенно для небольших поисковых систем. Иногда может возникнуть вопрос, сможет ли поисковая система понять ваш контент из-за необходимости выполнения JavaScript.
- SSG:Очень хорошо, потому что HTML предварительно визуализируется, а JavaScript необязателен.
- SSR: то же, что и SSG.
Гибкость
Важно начать с базы, которая позволяет делать все необходимое, не меняя подходы. Гибкость зависит от таких факторов, как то, сколько вы можете сделать на сервере, насколько легко изменить стек и насколько вы можете расширить инструменты, составляющие стек. Это одна из областей, где SSG терпит неудачу. SSG требует большого количества инструментов, что снижает мобильность. Кроме того, в отличие от SSR, вы не можете выполнять безопасные операции на сервере, не создавая общедоступный API. SSR лучше в том смысле, что вы можете выполнять безопасные операции на сервере для рендеринга данных. Тем не менее, он имеет еще большую привязку к поставщику из-за того, что вам нужно выбрать вычислительную службу, а не просто статический файловый хост. В этой области SPA работают несколько лучше, потому что они требуют наименьшего количества инструментов и конфигурации и, следовательно, имеют наименьшую привязку к поставщику. Самая большая проблема с гибкостью SPA заключается в том, что SPA не может ничего отображать на сервере.
- SPA: меньше привязка к поставщику, потому что это все статические файлы, и вам не нужны какие-либо инструменты, кроме самой платформы, но вы не можете отображать вещи на сервере, такие как SSR.
- SSG: очень ограничено из-за большей привязки к поставщику и невозможности рендеринга на сервере.
- SSR: из всех подходов наибольшая привязка к поставщику из-за того, что вам нужен сервер и часто настраиваемый код для этого сервера. Тем не менее, он позволяет вам отображать данные на сервере, что означает, что вы можете безопасно динамически отображать данные без клиентского JavaScript.
Простота разработки
Часто вам нужно быстро выпустить продукт или у вас не так много ресурсов, поэтому важна простота разработки. В целом, обычно довольно легко использовать любой из перечисленных подходов. Например, если вы используете React, вы можете быстро создать SPA с приложением Create React или создать сайт с помощью SSG или SSR с Next.js. Тем не менее, есть различия в удобстве использования. SPA почти всегда проще, потому что вы можете спроектировать свой код для работы только в браузере, а не на сервере и в браузере. SSG не так просто, как сделать SPA, но это проще, чем SSR, потому что вам не нужно использовать более продвинутый хостинг, чем простой CDN. SSR — это самое сложное, как было сказано ранее, потому что вам нужно заставить ваш код работать в двух средах и использовать хостинг с возможностью запуска кода (хотя такие сервисы, как Vercel, могут упростить хостинг).
- СПА: самый простой
- SSG: сложнее, чем SPA, потому что ваш код работает в двух средах. Кроме того, вам нужно больше инструментов для компиляции кода.
- SSR:самый сложный из всех подходов по тем же причинам, что и SSG, и поскольку он требует динамического выполнения кода на сервере.
Заключение
Каждый подход к созданию веб-сайта с помощью JavaScript-фреймворка имеет свои плюсы и минусы. SPA лучше всего подходят для сильно интерактивных приложений, где необходим JavaScript, а ресурсы разработки ограничены. Сайты SSG имеют лучшую производительность и хороши для сайтов с чисто статическим контентом, таких как маркетинговые сайты. SSR хорош для более продвинутых сайтов, которые используют больше динамических данных без использования JavaScript на стороне клиента. Я надеюсь, что вы узнали что-то из этого, и спасибо за чтение.
Вы создаете проект с помощью JavaScript, Jamstack или без сервера? Узнайте, почему базу данных Fauna выбирают тысячи строителей. Fauna — это гибкая, удобная для разработчиков транзакционная база данных, предоставляемая в виде безопасного и масштабируемого облачного API с собственным GraphQL. Никогда больше не беспокойтесь о предоставлении базы данных, масштабировании, сегментировании, репликации или корректности. Зарегистрируйтесь, чтобы изучить все возможности и начать строить!
Первоначально опубликовано на https://fauna.com.