CSR, SSR, SSG, ISR и другие аббревиатуры

Для каждого разработчика важно понимать как оптимизировать его проект. В веб-технологиях придумали несколько паттернов, с помощью которых можно оптимизировать рендеринг приложения.

Сегодня рассмотрим этим паттерны, поговорим почему это важно и зачем это нужно.

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

Чем быстрее работает приложение, тем больше выручки можно получить. Если даже не брать выручку в расчет, то вряд ли кто-то будет пользоваться приложением, которое будет грузиться 30 секунд.Для того чтобы эффективно измерять производительность приложений инженеры придумали Web Vitals.

web.dev

Web Vitals

Essential metrics for a healthy site

На момент 2020-го года измерялось три показателя:

Задержка перед первой отрисовкой (LCP - Largest Contentful Paint): Измеряет производительность загрузки приложения;
Задержка для первого взаимодействия (FID - First Input Delay): Измеряет интерактивность веб-приложения;
Совокупный сдвиг макета (CLS - Cumulative Layout Shift): Измеряет стабильность интерфейса;

Для каждой метрики есть свои показатели.

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

CSR, SSR, SSG, ISR и другие аббревиатуры

FID это показатель времени, который указывает на то, сколько занимает времени обработать первое взаимодействие пользователя с приложением.

CLS это показатель сдвига элементов на странице. Если у приложения есть огромный скрипт, который долго грузится, а после загрузки дополняет DOM-дерево какими-то элементами в результате чего все на странице сдвигается - это плохо.

Данный показатель измеряется не по временной шкале, а по шкале перцентилей. Данная шкала измеряется следующей формулой:

Оценка смещения макета = доля воздействия * доля расстояния

Если вы более подробно хотите разобраться в том что такое "доля воздействия" и "доля расстояния", то вы можете ознакомиться с данными понятиями на странице CLS в web.dev

web.dev

Cumulative Layout Shift (CLS)

This post introduces the Cumulative Layout Shift (CLS) metric and explains how to measure it.

Оптимальные значения для CLS следующие:

Показателей Web Vitals (кроме трех упомянутых) достаточно много. Все они созданы для того чтобы эффективно измерять производительность приложения. Вот краткая памятка по ним:

Делали ли вы когда-то приложения на Vue/React/Svelte/Angular? Если да, то вы 100% использовали Client-side rendering (далее просто CSR), даже не зная о нем.

Вы наверняка видели index.html, у которого в <body> только один элемент: <div id="root"></div>. Все содержимое внутри #root будет наполняться с помощью JavaScript, это и есть CSR.

По сути CSR это паттерн, когда все компоненты в приложении рендерятся посредством JavaScript. Если отключить JavaScript в браузере, то браузер выведет просто белое полотно, так как ничего не зарендерится.

Client-side rendering содержит слово client потому что вся отрисовка происходит на стороне клиента, а если быть точнее - браузера.

CSR подарил нам гибкость в приложениях, ибо всеми компонентами которые рендерятся на странице можно управлять посредством JavaScript.

Однако, он отнял у нас SEO и подарил плохие показатели FCP (время нужное для первой отрисовки) и TTI (время, которое нужно для первого взаимодействия), ведь для того чтобы отрендерить первый видимый блок на странице браузер должен загрузить весь JavaScript и выполнить его.

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

Если вы когда-то работали с Nuxt/Next/SvelteKit, то этот паттерн вам тоже знаком.

Server-side rendering (далее SSR) предполагает, что часть верстки рендерится на сервере и отдается клиенту, реактивные состояния у клиента и сервера могут быть связаны и передаваться с помощью POST или GET запросов, а обновление интерфейса идет как на сервере, так и на клиенте (такое обновление называется гидрация, об этом подробнее позже).

У приложений с SSR более высокие показатели FCP и TTI, однако хромает TTFB (время затраченное на получение первого байта). TTFB хромает из-за рендеринга на сервере, ведь теперь сервер не отдает заранее готовый контент, а динамически генерирует его при каждом запрос GET /.

Гидрация это механизм разворачивания такого же приложения как на сервере, но уже на клиентской части. Проблема SSR без гидрации состоит в том, что сервер отдает только HTML + CSS, но для того чтобы обратывать действия пользователя нам нужен такой же фреймворк, как и на сервере.

vuejs.org

Server-Side Rendering (SSR) | Vue.js

Vue.js - The Progressive JavaScript Framework

Также, существует такой термин как "Progressive Hydration". Если говорить совсем просто, то это обычная гидрация, но отданная мелкими чанками (одна большая гидрация делится на кучу маленьких).

Такая гидрация позволяет увеличить показатель FID, так как пользователь не будет ждать покуда вся гидрация закончится, ему достаточно дождаться покуда закончится гидрация той части приложения, которая ему нужна.

Static Site Generator (далее просто SSG) - это паттерн рендеринга приложений, при котором приложение собирается на сервере один раз и просто раздается клиентам.

У SSG есть плюсы и минусы. Из плюсов то, что по сути нам не нужен JavaScript на клиенте, а значит FCP и TTI будут просто превосходными. Из минусов же то, что у нас полностью статичные данные, если мы захотим обновить данные на странице - нам придется пересобирать все приложение.

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

При первом запросе страницы она генерируется сервером на лету. Далее данная страница будет просто раздаваться. У первого пользователя во время генерации страницы появляется лоадер;
У других пользователей, которые зашли после первого пользователя страница просто раздается из кэша;
Если страница обновилась - она перегенерируется, во время генерации сервер отдает старую версию страницы;
Если пользователи перезагрузят страницу, то она обновится;

Island Architecture - архитектура, которая предполагает что часть компонентов будет статической (переданы обычным HTML + CSS), а часть будет гидрирована (так называемые острова).

Популярным фреймворком, который реализует данную архитектуру является Astro.

astro.build

Astro

Astro builds fast content sites, powerful web applications, dynamic server APIs, and everything in-between.

Под разные приложения вам понадобятся разные архитектуры для рендеринга. Выбирать архитектуру нужно исходя из плюсов, которые она дает.Вот пара примеров:

Для приложения, которому не нужно SEO, но нужна реактивность на клиенте (и возможно работа в оффлайне) стоит выбрать CSR;
Для приложения, которое не имеет множество реактивных элементов в интерфейсе или для приложения которое оперирует большим количеством статического контента можно выбрать SSG;
Для приложения, которое содержит множество реактивных элементов и важную SEO-разметку можно использовать SSR;

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

Если у вас остались вопросы - не стесняйтесь задавать их в комментариях. Хорошего времяпрепровождения! 💁🏻‍♂