Дилемма рендеринга веб-страницы
Дискуссия о рендеринге веб-страницы появилась только в последние годы. Раньше у веб-сайтов и веб-приложений была общая стратегия. Они подготовили HTML-контент для отправки в браузеры на стороне сервера; затем это содержимое было визуализировано в браузере как HTML со стилем на основе CSS.
С появлением фреймворков JavaScript пришел совершенно другой подход к веб-разработке. Фреймворки JavaScript позволили снять нагрузку с сервера.
Благодаря мощи фреймворков JavaScript стало возможным отображать динамический контент прямо из браузера, запрашивая только тот контент, который требуется. В этом сценарии сервер обслуживается только с необходимой базовой HTML-оболочкой. Это преобразование дало посетителям беспроблемный пользовательский интерфейс, поскольку на загрузку веб-страницы уходит очень мало времени. Более того, после загрузки веб-страница не перезагружается снова.
В этой статье мы обсудим эти технически разные подходы к рендерингу веб-страниц - рендеринг на стороне клиента и рендеринг на стороне сервера. Я объясню, что это такое, основные различия между каждым подходом и предложу вам подход.
Что такое рендеринг на стороне сервера (SSR)?
Рендеринг на стороне сервера или SSR - это обычный способ рендеринга веб-страниц в браузере. Как обсуждалось выше, традиционный способ визуализации динамического веб-контента включает следующие шаги:
- Пользователь отправляет запрос на веб-сайт (обычно через браузер)
- Сервер проверяет ресурс, компилирует и подготавливает HTML-контент после прохождения серверных скриптов, лежащих на странице.
- Этот скомпилированный HTML-код отправляется в браузер клиента для дальнейшей обработки и отображения.
- Браузер загружает HTML и делает сайт видимым для конечного пользователя.
- Затем браузер загружает Javascript (JS) и, выполняя JS, делает страницу интерактивной.
В этом процессе все бремя получения динамического контента, его преобразования в HTML и отправки в браузер остается на сервере. Следовательно, этот процесс называется рендерингом на стороне сервера (SSR).
Эта ответственность за предварительную визуализацию всего HTML ложится бременем на память и вычислительную мощность на сервере. Следовательно, рендеринг на стороне сервера увеличивает время загрузки страницы по сравнению со временем загрузки страницы для статического сайта, где нет динамического контента для рендеринга.
Что такое рендеринг на стороне клиента (CSR)?
Рендеринг на стороне клиента или CSR - это другой подход к тому, как веб-страница обрабатывается для отображения в браузере. В CSR бремя компиляции динамического контента и создания для него HTML переносится на клиентский браузер.
Этот подход основан на фреймворках и библиотеках JavaScript, таких как ReactJS, VueJS и Angular. Обычный процесс отрисовки веб-страницы для сценария отрисовки на стороне клиента включает следующие шаги:
- Пользователь отправляет запрос на веб-сайт (обычно через браузер)
- Вместо сервера можно использовать CDN (сеть доставки контента) для предоставления пользователю статического HTML, CSS и вспомогательных файлов.
- Браузер загружает HTML, а затем JS, при этом пользователь видит символ загрузки.
- После того, как браузер получает JS, он делает запросы API через AJAX для получения динамического содержимого и обрабатывает его для визуализации окончательного содержимого.
- После ответа сервера окончательный контент отображается с использованием обработки DOM в клиентском браузере.
Поскольку этот процесс включает выборку и обработку данных на стороне клиента, этот процесс называется рендерингом на стороне клиента.
Рендеринг на стороне клиента (CSR) и рендеринг на стороне сервера (SSR) - Сравнение
Поскольку оба подхода различаются способом обработки контента, каждый метод имеет свои преимущества, что затрудняет принятие решения о том, что выбрать - CSR или SSR.
Давайте выясним разницу между рендерингом на стороне сервера и рендерингом на стороне клиента как с точки зрения пользователя, так и с точки зрения Интернета.
Отличие №1 - время загрузки веб-страницы
Время загрузки веб-страницы - это время, прошедшее между отправкой запроса на сервер и его отображением в браузере. Это важный аспект, когда речь идет о пользовательском опыте (UX) для вашего веб-сайта или веб-приложения. Время загрузки веб-страницы для CSR и SSR различается в двух сценариях:
Время загрузки первой страницы
Время загрузки первой страницы - это среднее время, затрачиваемое пользователем на первую загрузку вашего веб-сайта. При первой загрузке в CSR браузер загружает базовый HTML, CSS и все необходимые скрипты одновременно, а затем компилирует HTML в пригодный для использования контент в браузере.
На этот раз обычно больше, чем просто получение предварительно скомпилированного HTML и соответствующих сценариев с сервера. Таким образом, SSR обычно занимает меньше времени, когда дело доходит до времени загрузки первой страницы.
Время загрузки второй и последующих страниц
Время загрузки второй страницы - это среднее время, необходимое для перехода с одной страницы на другую. В этом сценарии, поскольку все поддерживающие скрипты загружаются заранее для CSR, время загрузки меньше для CSR (и, следовательно, более высокая производительность). Он не отправляет запрос на сервер, если не требуется загружать ленивый модуль JavaScript.
Однако для SSR повторяется полный цикл запроса, за которым следует загрузка первой страницы. Это означает, что SSR практически не влияет на время загрузки веб-страницы. Таким образом, в этом сценарии CSR реагирует быстрее.
Здесь важно отметить, что приведенный выше вывод не рассматривает подробно сетевые аспекты. Мы считаем, что клиент и сервер имеют сопоставимую пропускную способность в сети.
Отличие № 2 - Влияние кеширования
Кэширование стало необходимостью на сегодняшний день. Чтобы ускорить работу тяжелых веб-приложений, каждый браузер, а также веб-сервер, используют механизмы кэширования для кэширования повторно используемых сценариев на клиентском компьютере. Это улучшает общее время загрузки как для CSR, так и для SSR. Тем не менее, КСО имеет большое преимущество.
В CSR, пока не требуется ленивая загрузка модуля, практически веб-приложения на основе CSR могут работать и без Интернета! (если вы не вызываете API для данных). После загрузки приложению больше не нужно отправлять запросы на сервер. Это позволяет перемещаться по веб-приложению, как по простому настольному приложению.
Однако в SSR запрос к серверу всегда отправляется. Следовательно, время загрузки страницы для SSR, несомненно, больше, чем для CSR. Кэширование действительно улучшает скорость рендеринга контента даже для SSR, поскольку скрипты будут извлекаться браузером из кеша. На изображении ниже показано, как браузер обрабатывает повторный запрос кешированного скрипта.
Обратите внимание, что большинство сценариев загружаются из памяти или кеша диска. Это значительно сокращает время загрузки и предотвращает чрезмерную нагрузку на сервер.
Отличие № 3 - Влияние на SEO
Для бизнес-сайта очень важна его оптимизация для поисковых систем. Поисковые системы читают и понимают ваши веб-сайты с помощью автоматических ботов, называемых сканерами. Эти сканеры заинтересованы в метаданных вашего веб-сайта больше, чем в фактическом содержании. Следовательно, становится жизненно важным, чтобы ваша веб-страница отражала правильные метаданные для поисковых систем.
С помощью CSR содержимое веб-страницы динамически создается с помощью JavaScript. Это означает, что изменение метаданных с одной страницы на другую зависит от выполнения JavaScript. Раньше поисковые системы предпочитали не запускать JavaScript, пока сканеры просматривают сайты. Однако, когда Google соглашается использовать JavaScript, тенденция меняется.
С CSR вам нужно использовать и прилагать дополнительные усилия, чтобы гарантировать, что метаданные страницы меняются с одной страницы на другую. Это требует использования плагинов, таких как React Helmet для ReactJS, и использования библиотечных модулей, таких как Meta from @ angular / browser library для Angular framework. Вам нужно приложить дополнительные усилия, чтобы метаданные были установлены для каждой страницы и отображались на стороне клиента.
С SSR полная страница компилируется с правильными метаданными и отправляется во внешний интерфейс только после получения окончательного HTML-содержимого. Это гарантирует, что метаданные страницы всегда точны, независимо от того, разрешает ли сканер использовать JavaScript или нет. Это делает SSR лучшим решением для страниц, оптимизированных для поисковых систем, по сравнению с CSR.
Когда использовать рендеринг на стороне клиента и рендеринг на стороне сервера?
Меньший выбор всегда самый простой. Условно у вас был единственный выбор - SSR. С появлением CSR возникает вопрос, какой из них подходит для вашего приложения или веб-сайта. Разберемся, где каждому из них выгодно.
Сценарий №1 - Загрузка динамического контента
Сервер обычно находится на машине с более высокой вычислительной мощностью и значительно более высокими скоростями сети. Благодаря такой скорости и мощности у него никогда не заканчивается заряд при обработке ожидаемого количества запросов на обработку. В результате получение контента на сервере становится сравнительно быстрее.
С другой стороны, клиентские машины имеют ограниченную вычислительную мощность и могут потребовать больше времени для выборки и рендеринга динамического содержимого на стороне клиента. Это означает, что общее время, затрачиваемое на визуализацию контента, будет больше. Таким образом, если ваш веб-сайт включает повторяющуюся рендеринг динамического контента, SSR - лучший выбор, чем CSR.
Сценарий № 2 - UX веб-приложения против UX веб-сайта
Хотя они выглядят почти одинаково, веб-приложения и веб-сайты представляют собой два разных формата веб-контента. Веб-приложение - это законченное приложение, которое можно использовать для таких целей, как бухгалтерский учет, CRM, управление персоналом, управление проектами и т. Д. Веб-сайт, с другой стороны, представляет собой информативный контент о бизнесе.
Веб-приложение требует гораздо большего взаимодействия с пользователем по сравнению с веб-сайтом, поскольку пользователь выполняет ввод данных и создает отчеты в веб-приложении. В сценарии, когда взаимодействие с пользователем больше, важно, чтобы клики не занимали много времени. Итак, CSR лучше работает для веб-приложений, чем SSR.
С другой стороны, для веб-сайта клиент в порядке, если новая веб-страница загружается при каждом щелчке мышью, поскольку кеширование обычно обеспечивает ускорение рендеринга. Кроме того, SSR также обеспечивает правильные метаданные для поисковых роботов - это делает SSR лучше для веб-сайтов по сравнению с CSR.
Лучшее из обоих миров
Пройдя через все вышесказанное, вы, возможно, задаетесь вопросом, есть ли способ получить преимущества быстрой первой загрузки SSR и повышения производительности SEO с почти нативным ощущением CSR. Тебе повезло! - Есть фреймворки, работающие по гибридному подходу, такие как Гэтсби.
По сути, это то, что, хотя первая страница всегда загружается с SSR, она кэширует другие страницы после завершения загрузки. Итак, остальные страницы предварительно обрабатываются и кешируются, поэтому создается впечатление, что вы используете подход CSR на последующих страницах! Посетите наш веб-сайт, который также создан с использованием Gatsby.
Узнайте разницу между фреймворками Gatsby.JS и Next.JS для создания веб-сайтов.
Заключение
CSR и SSR имеют решающее значение для UX, который вы планируете предложить своему пользователю. Я надеюсь, что эта статья помогла вам понять эти концепции с функциональной и практической точки зрения. Окончательный выбор остается за вами. Выбирайте с умом, учитывая вышеперечисленные факторы. Неправильный выбор может стоить вам переделки всего веб-сайта или веб-приложения. Правильный выбор также может сократить ваши усилия по управлению кодом в будущем.
