Имея так много вариантов на выбор, рендеринг — это тема, которую вам нужно держать в курсе.
Современные веб-фреймворки предлагают множество вариантов доставки сайта или приложения с сервера на клиент. Вы можете генерировать HTML на любой стороне или предварительно визуализировать его для высокоскоростного распространения через сеть доставки контента.
Решение о том, как структурировать сайт или приложение, зависит от нескольких различных факторов. Вы должны знать, как посетители будут получать доступ к вашему сайту или приложению. Вы должны понимать, что важнее: скорость загрузки при начальной загрузке или последующей навигации. Также подумайте, как часто вы будете обновлять сайт.
Имейте в виду все эти факторы, чтобы взвесить все за и против каждой парадигмы рендеринга.
Рендеринг веб-сайтов несколькими способами
Рендеринг веб-сайта относится к процессу, посредством которого веб-сайт отображается в веб-браузере. Существует множество различных подходов к процессу преобразования необработанных данных в форматированный HTML на экране пользователя.
У каждого метода есть свои плюсы и минусы, и знание преимуществ и недостатков каждого из них может помочь вам выбрать правильный вариант для вашего сайта.
CSR: браузер берет на себя ответственность
CSR означает рендеринг на стороне клиента. Когда вы визуализируете клиентскую часть приложения или сайта, сервер практически не передает HTML, за исключением небольшого фрагмента шаблонного кода. Затем страница запрашивает любые необходимые ей данные с сервера после события загрузки страницы с помощью запросов AJAX.
Когда приложение или страница рендерятся на стороне клиента, сервер передает клиенту скрипт, который генерирует HTML-код в клиентском браузере. Это позволяет использовать одностраничные приложения, которые не обновляют браузер при взаимодействии с ними.
Приложения CSR часто быстро загружаются при навигации, но изначально они могут загружаться медленно. Скорость будет во многом зависеть от фреймворка, который вы выберете для рендеринга, и от того, сколько дополнительных библиотек и надстроек вы используете. Большинство популярные современные фреймворки JavaScript включить опцию для CSR.
Страницы и приложения, отображаемые полностью на стороне клиента, страдают от невозможности перейти непосредственно на заданную страницу с помощью URL-адреса. Когда клиентское приложение, отображаемое в первый раз, запускается, независимо от введенного URL-адреса, оно переходит к одной и той же начальной точке.
SSR: рендеринг на центральном сервере
SSR означает рендеринг на стороне сервера. Это гораздо более традиционная форма рендеринга веб-страниц, при которой сайты генерируют HTML на основе шаблонов и отправляют клиенту сочетание HTML, таблиц стилей и сценариев. Большая часть чего-либо самые популярные серверные веб-фреймворки попасть в эту категорию.
Приложения и сайты с рендерингом на стороне сервера, как правило, имеют более быструю начальную загрузку, но каждая последующая навигация потребует полного обновления. Это означает, что они не только займут больше времени, но и разработчикам, работающим с SSR, придется учитывать управление сеансами.
Самым большим преимуществом сайтов и приложений, созданных с помощью SSR, является согласованность навигации по пути. Пользователь, вводящий заданный путь, попадет прямо на запрошенную страницу. Некоторые платформы управляют перенаправлением пользователей со страницы на страницу в приложении, но пользователи могут не иметь доступа к странице, которую они хотят изначально.
Многие современные фреймворки предлагают смешанные решения, которые начинаются с предоставления клиенту отображаемой сервером страницы. После загрузки страницы происходит событие, известное как гидратация, при котором события сценария на стороне клиента прикрепляются к элементам управления страницы. С этого момента клиент обрабатывает любую навигацию.
Смешанная динамика дает пользователям возможность переходить непосредственно на любую страницу в приложении, сохраняя при этом скорость и плавность одностраничного приложения. Next.js предлагает несколько парадигм рендеринга, как и Nuxt.js и Sveltekit.
SSG: Минимальный рендеринг
SSG, или создание статического сайта, позволяет избежать необходимости генерировать HTML на стороне клиента или сервера. Вместо этого сайты и приложения в стиле SSG предварительно компилируют каждую страницу, которая им может понадобиться, и передают результаты в CDN для быстрой доставки.
Это чрезвычайно эффективный метод чрезвычайно быстрого обслуживания веб-страниц. Результаты обычно собираются в простые пакеты, содержащие все HTML и таблицы стилей, необходимые для отдельной страницы. Эти пакеты максимально компактны, чтобы гарантировать, что пользователь получит их как можно быстрее.
Сайты SSG, как правило, предлагают исключительно быструю скорость загрузки, несмотря на то, что для каждой навигации требуется обновление. Однако основным недостатком статического сайта является отсутствие гибкости. Высокодинамичные системы, такие как приложения для социальных сетей или сложные платформы электронной коммерции, потребуют гораздо большего количества изменений, чем может легко выполнить SSG.
Многие статические сайты также потребуют больших накладных расходов для изменения, поскольку каждое новое изменение необходимо будет компилировать независимо. Это делает рендеринг в стиле SSG плохим выбором для сайтов, которые быстро меняются, например, цифровой магазин с быстро меняющимся ассортиментом или приложения для социальных сетей.
ISR: всего понемногу
Пожалуй, самый сложный тип рендеринга, но и самый полезный. ISR расшифровывается как Incremental Static Regeneration. ISR сочетает в себе скорость и масштабируемость статически сгенерированных сайтов с реактивностью приложений в стиле SSR и CSR.
Когда какая-либо страница запрашивается на странице или в приложении в стиле ISR, сервер сначала проверяет, есть ли кешированная версия страницы с неистекшим сроком действия. Если есть, сервер немедленно обслужит кешированную страницу.
Если кэшированная версия страницы не существует или с момента ее создания прошло достаточно времени, сервер сгенерирует новую версию. Эта новая версия будет передана клиенту и кэширована для будущего использования.
Этот тип рендеринга сложнее настроить, но он автоматизирует большинство проблем, с которыми обычно сталкиваются сайты SSG. Это позволяет приложениям предлагать как скорость, так и надежность статически сгенерированного приложения, при этом автоматизируя дополнительные накладные расходы.
Несколько современных фреймворков уже предлагают возможность рендеринга в стиле ISR. Многие другие имеют поддержку добавочной генерации в разработке. Большинство основных фреймворков вскоре будут поддерживать рендеринг ISR, если они еще этого не сделали.
Какой тип рендеринга лучше?
Существует несколько способов рендеринга веб-сайта или приложения. Каждый из этих четырех типов рендеринга имеет несколько вариаций. Ни один тип рендеринга не подходит для всех проектов, и какой тип вы выберете, будет зависеть от того, что наиболее важно на вашем сайте или в приложении.
При выборе парадигмы рендеринга для вашего проекта важно учитывать скорость, то, как ваша аудитория будет использовать ваш проект и как часто будет меняться сайт. Это будут основные принципы, которые помогут вам выбрать наилучший способ структурирования вашего сайта или приложения.
