Публикация была переведена автоматически. Исходный язык: Русский
В современной frontend-разработке уже мало встретишь проекты, где используется просто нативный javascript для создания производительных веб-приложений. С приходом frontend-фреймворков, таких как React, Vue, Angular, Svelte разработка интерфейсов значительно ускорилась и открыла новые возможности реализации отрисовки веб-страниц, или как привыкли говорить “рендера” страниц в вебе.
Каждый, кто интересовался frontend-разработкой слышал про критические стадии рендера (Critical Rendering Path), это последовательность необходимых действий бразуера для превращения HTML, CSS и JavaScript в пиксели на экране. Данный процесс включает следующие этапы:
- Парсинг HTML в DOM дерево (Document Object Modal)
- Парсинг CSS в CSSOM (CSS Object Modal)
- Выполнение Javascript
- Формирование Render Tree
- Layout (Вычисление размеров и позиции элементов)
- Paint (отрисовка элементов)
В зависимости от того где создается HTML, рендер страниц может заметно отличаться. Именно поэтому в разработке применяются разные стратегии рендера: CSR (Client Side Rendering), SSR (Server Side Rendering) и SSG (Static Site Generation). Для их реализации применяются фреймворки, которые объединяют серверную и клиентскую части приложения, позволяя контролировать формирование HTML. К популярным примерам таких фреймворков относятся Nuxt, Next.js и SvelteKit.
Для демонстрации различных стратегий рендера будет использоваться Nuxt и Pokemon Api. Примером будет служить небольшая страница, с информацией о покемоне (рисунок 1), созданная с применением различных типов рендеринга.
Рисунок 1 - Тестовая страница
Client Side Rendering (CSR)
При данном подходе пользователь, перейдя на страницу, не видит её содержимое сразу, так как с сервера загружается почти пустой HTML и набор JavaScript-файлов. После этого браузер выполняет полученный JavaScript-код, который формирует содержимое страницы и только после этого страница становится доступной. На рисунке 2 показано содержимое HTML-документа, полученного с сервера. Он содержит лишь минимальную разметку, а загрузку и отображение остальных данных выполняет JavaScript.
Рисунок 2 – HTML при CSR
Server Side Rendering (SSR)
SSR метод считается одним из наиболее распространённых способом рендеринга. Благодаря этому способу, пользователь видит содержимое страницы сразу после загрузки, что положительно влияет на скорость отображения контента и поисковую оптимизацию. Браузер получает от сервера сгенерированную HTML-разметку и после отображения контента загружает JavaScript-файлы приложения. Далее выполняется процесс гидратации, в ходе которого JavaScript добавляет странице интерактивность: обработчики событий, динамическое обновление данных и другие элементы логики приложения.
Рисунок 3 – HTML при SSR
Static Site Generation (SSG)
Стратегия SSG предполагает генерацию HTML-страниц заранее, на этапе сборки приложения. Во время сборки приложение получает все необходимые данные и формирует готовые HTML-файлы. При переходе пользователя на страницу браузер уже получает готовую разметку и как в SSR режиме происходит гидратация данных. Это позволяет уменьшить нагрузку на сервер и ускорить загрузку страницы. Структура HTML-разметки выглядит как на рисунке 3.
Сравнение стратегий рендеринга
| Критерий | CSR | SSR | SSG |
| Где формируется HTML | в браузере | На сервере | во время сборки |
| Скорость первого отображения | низкая | высокая | Очень высокая |
| Нагрузка на сервер | низкая | высокая | низкая |
| SEO | хуже | хорошо | хорошо |
| Подходящие типы сайтов | SPA-приложения | динамическиесайты | статическиесайты |
Вывод
Таким образом, выбор стратегии рендеринга зависит от требований к приложению, таких как скорость загрузки, SEO оптимизация и интерактивности. CSR больше всего используется для сложных веб-приложений, SSR — для динамических сайтов с требованиями к SEO, а SSG для статических страниц и сайтов с редко изменяемым контентом.
В современной frontend-разработке уже мало встретишь проекты, где используется просто нативный javascript для создания производительных веб-приложений. С приходом frontend-фреймворков, таких как React, Vue, Angular, Svelte разработка интерфейсов значительно ускорилась и открыла новые возможности реализации отрисовки веб-страниц, или как привыкли говорить “рендера” страниц в вебе.
Каждый, кто интересовался frontend-разработкой слышал про критические стадии рендера (Critical Rendering Path), это последовательность необходимых действий бразуера для превращения HTML, CSS и JavaScript в пиксели на экране. Данный процесс включает следующие этапы:
- Парсинг HTML в DOM дерево (Document Object Modal)
- Парсинг CSS в CSSOM (CSS Object Modal)
- Выполнение Javascript
- Формирование Render Tree
- Layout (Вычисление размеров и позиции элементов)
- Paint (отрисовка элементов)
В зависимости от того где создается HTML, рендер страниц может заметно отличаться. Именно поэтому в разработке применяются разные стратегии рендера: CSR (Client Side Rendering), SSR (Server Side Rendering) и SSG (Static Site Generation). Для их реализации применяются фреймворки, которые объединяют серверную и клиентскую части приложения, позволяя контролировать формирование HTML. К популярным примерам таких фреймворков относятся Nuxt, Next.js и SvelteKit.
Для демонстрации различных стратегий рендера будет использоваться Nuxt и Pokemon Api. Примером будет служить небольшая страница, с информацией о покемоне (рисунок 1), созданная с применением различных типов рендеринга.
Рисунок 1 - Тестовая страница
Client Side Rendering (CSR)
При данном подходе пользователь, перейдя на страницу, не видит её содержимое сразу, так как с сервера загружается почти пустой HTML и набор JavaScript-файлов. После этого браузер выполняет полученный JavaScript-код, который формирует содержимое страницы и только после этого страница становится доступной. На рисунке 2 показано содержимое HTML-документа, полученного с сервера. Он содержит лишь минимальную разметку, а загрузку и отображение остальных данных выполняет JavaScript.
Рисунок 2 – HTML при CSR
Server Side Rendering (SSR)
SSR метод считается одним из наиболее распространённых способом рендеринга. Благодаря этому способу, пользователь видит содержимое страницы сразу после загрузки, что положительно влияет на скорость отображения контента и поисковую оптимизацию. Браузер получает от сервера сгенерированную HTML-разметку и после отображения контента загружает JavaScript-файлы приложения. Далее выполняется процесс гидратации, в ходе которого JavaScript добавляет странице интерактивность: обработчики событий, динамическое обновление данных и другие элементы логики приложения.
Рисунок 3 – HTML при SSR
Static Site Generation (SSG)
Стратегия SSG предполагает генерацию HTML-страниц заранее, на этапе сборки приложения. Во время сборки приложение получает все необходимые данные и формирует готовые HTML-файлы. При переходе пользователя на страницу браузер уже получает готовую разметку и как в SSR режиме происходит гидратация данных. Это позволяет уменьшить нагрузку на сервер и ускорить загрузку страницы. Структура HTML-разметки выглядит как на рисунке 3.
Сравнение стратегий рендеринга
| Критерий | CSR | SSR | SSG |
| Где формируется HTML | в браузере | На сервере | во время сборки |
| Скорость первого отображения | низкая | высокая | Очень высокая |
| Нагрузка на сервер | низкая | высокая | низкая |
| SEO | хуже | хорошо | хорошо |
| Подходящие типы сайтов | SPA-приложения | динамическиесайты | статическиесайты |
Вывод
Таким образом, выбор стратегии рендеринга зависит от требований к приложению, таких как скорость загрузки, SEO оптимизация и интерактивности. CSR больше всего используется для сложных веб-приложений, SSR — для динамических сайтов с требованиями к SEO, а SSG для статических страниц и сайтов с редко изменяемым контентом.
