В нынешнее время почти во всем мире компьютеры и сети становятся все быстрее. И это в общем-то отлично сказывается как на веб-разработке, так и на взаимодействии с пользователями. Плюс ко всему, появилось огромное количество перспектив для людей.
И хотя во многом рост очевиден, все же есть те, кто остались позади в этой спринтерской гонке. Есть один большой вопрос: как мы можем уравнять возможности работы в сети с учетом такого цифрового неравенства и как мы можем сделать Интернет более доступным для людей, у которых не такие эффективные компьютеры и сети?
Во многом ответ заключается в том, как мы отображаем веб-страницы в браузере.
Термины, которые мы будем использовать в этой статье
Пока мы не начали, я хочу убедиться, что вы хорошо знакомы с терминами, которые будут встречаться в этой статье. Для новичков в разработке некоторые термины могут показаться особенно сложными для понимания. Если вы уже знаете эти термины, смело переходите к следующему разделу.
- Сервер. Сервер – это удаленный компьютер, который чаще всего расположен в Интернете. К его работе относится обработка запросов от клиентов и ответы на эти запросы.
- Клиент. Клиент – это любое устройство, которое взаимодействует с сервером с целью получить доступ к ресурсам. Как правило, клиент – это любое устройство с выходом в Интернет. В этой статье роль клиента играет как раз веб-браузер.
- CDN, сокращенно от Content Delivery Network (сеть доставки контента). CDN – это «сеть взаимосвязанных серверов, которая ускоряет загрузку веб-страниц в тяжелых приложениях» (от AWS).
- Время компоновки. В течение этого времени код вашего приложения подготавливается для использования в другой среде. Чаще всего эта среда находится на сервере в Интернете.
А теперь давайте поговорим о различных способах отображения веб-сайтов.
Что такое рендеринг на стороне клиента?
Рендеринг на стороне клиента (CSR – Client-Side Rendering) создает веб-страницы в браузере, при этом полностью опираясь на ваш код JavaScript. Прежде чем пользователь увидит содержимое вашей страницы, браузер должен обработать ваш JS-код от и до.
Этот JS-код помогает динамически определять архитектуру сайта, как только он загрузится. В данном случае под архитектурой понимается извлечение данных из API, навигация по сайту и простейшая бизнес-логика на вашем сайте.
Рендеринг на стороне клиента и фреймворки JavaScript
Рендеринг на стороне клиента стал набирать популярность после того, как были выпущены фреймворки и библиотеки JavaScript, в частности, React, Vue и Angular. Эти фреймворки будут работать только в том случае, если вы добавите CDN в самом начале HTML-страницы, а эти CDN, как правило, представляют собой огромный JS-код.
Ни для кого не секрет, что большие файлы увеличивают время загрузки, но здесь есть одно «но»: если большие файлы были загружены при начальной загрузке приложения, то время загрузки других страниц этого сайта будет существенно меньше.
В первую очередь веб-сайт извлекает данные из API. После чего эти данные используются для того, чтобы заполнить страницы, которые отображаются на клиенте.
Среди реальных приложений, которые используют CSR, есть большое количество прогрессивных веб-приложений, например, Spotify, Figma и Google Drive.
Что такое рендеринг на стороне сервера?
Рендеринг на стороне клиента – это событие, которое в корне изменило правила игры, и во многом это до сих пор так. Однако, если тщательнее присмотреться к качеству функционирования CSR, то можно заметить, что чем больше у веб-сайта функций, тем больше в нем JS-кода. А мы ведь помним, что чем больше JS-кода, тем больше время загрузки.
Тяжелая начальная загрузка в качестве средства для более быстрого доступа к остальным веб-страницам оказалась не тем компромиссом, на который готовы были пойти пользователи. И это поспособствовало возникновению рендеринга на стороне сервера (SSR – Server-Side Rendering).
Конечно, SSR не решил все проблемы, связанные с рендерингом в Интернете, но решил большую часть проблем, с которыми сталкивался CSR. В частности, он уменьшил время начальной загрузки. Также мы отметили некоторые другие преимущества SSR (в сравнении с CSR) в разделе «Преимущества и недостатки».
Рендеринг на стороне сервера позволяет создавать страницу на сервере сразу после того, как от браузера поступил запрос. Если вы используете SSR, то ваш сервер отобразит весь код HTML, CSS и JavaScript, который необходим для запрошенного ресурса, и отправит его обратно в браузер.
При таком подходе вы всегда можете быть уверены в том, что ваш сайт содержит самую актуальную информацию с сервера. Вы можете рассматривать это как интеграцию REST API – содержимое с сервера всегда будет самым актуальным.
Как и у любого другого метода рендеринга в Интернете, у SSR есть свои недостатки. Начать хотя бы с того, что тот факт, что для загрузки веб-страницы нужно отправить сетевой запрос на сервер, может отразиться на пользователях, чья скорость Интернет-соединения меньше, чем у других. Кроме того, для работы SSR требуется довольно большой объем вычислительной мощности.
Что такое генерация статических сайтов?
Генерация статических сайтов – довольно распространенный подход к рендерингу в Интернете. Это обусловлено тем, что до того, как появились фреймворки JavaScript, большая часть веб-сайтов (если не все) генерировались статически.
Статические сайты не потеряли своей популярности, но теперь есть более эффективные способы их создания. Это подтверждает тот факт, что они важны с точки зрения производительности в сети.
Но что же такое статический сайт?
Статический сайт отображается в браузере ровно так, как он был сгенерирован. Пользователь, который просматривает сайт, никак не может повлиять на содержимое статического сайта, что не скажешь о веб-приложении, которое отображается с помощью CSR или SSR, где каждый пользователь может посматривать содержимое, пройдя процесс аутентификации или авторизации.
Статические сайты идеальны для отображения содержимого, которое никогда не будет меняться и которое не нужно периодически обновлять.
Объясняем, что такое генерация статических сайтов
Генерация статических сайтов (SSG – Static Site Generation) в большинстве случаев включает в себя автоматизацию процесса создания веб-страниц. У фреймворков JavaScript (например, Nuxt.js, Next.js и т.д.) есть шаблонизатор, с помощью которого вы можете создать несколько статических веб-страниц, используя лишь один шаблон. Конечно, это экономит ваше время.
Отличие SSG от CSR и SSR состоит в том, что HTML-страницы вашего сайта отображаются и генерируются в процессе сборки, то есть еще до того, как пользователь попытается получить к ним доступ. Именно поэтому SSG нередко называют предварительным рендерингом. Всю трудоемкую работу он выполняет заблаговременно.
Несмотря на то, что SSG может показаться вам благодатью, у него все же есть некоторые минусы. Основной недостаток SSG-рендеринга состоит в том, что страница должна генерироваться для каждого доступного URL на вашем сайте. К тому же, этот процесс может усугубиться и стать еще более громоздким, если у вас есть динамические страницы.
Напомним, что статические сайты идеально подходят для демонстрации содержимого, которое требует довольно редких обновлений. Соответственно, такой метод рендеринга подходит далеко не для всех случаев.
Преимущества и недостатки различных методов рендеринга
Теперь, когда мы выяснили, как работают все эти методы рендеринга, давайте объединим всю эту информацию и сравним их.
Мы проанализируем три основных показателя – производительность, SEO и стоимость.
Производительность
Для того, чтобы вы могли создавать веб-сайты, которые будут доступны для пользователей независимо от скорости их Интернет-соединения или мощности их компьютера, мы должны учитывать такой показатель, как производительность. В данном случае производительность можно связать с тем, как быстро веб-сайт загружает или извлекает данные из API.
Далее продемонстрировано то, как CSR, SSR и SSG ведут себя с точки зрения производительности.
Производительность CSR
Загрузка CSR-сайта может оказаться довольно медленной. Дело в том, что, прежде чем пользователи смогут увидеть содержимое веб-сайта, необходимо, чтобы JS-код загрузился и сгенерировал это самое содержимое.
Зачастую загрузки JS-кода бывают тяжелыми, особенно если вы используете фреймворки JavaScript. Также может возникнуть ситуация, что CSR-странице нужно будет выполнить вызов API, чтобы извлечь данные с сервера. Это также может увеличить время загрузки.
Производительность SSR
SSR-страницы могут оказаться довольно быстрыми. В основном это зависит от скорости сервера и пользователя. Если и там, и там все хорошо, то SSR может с легкостью победить с точки зрения производительности.
Производительность SSG
SSG-страницы довольно быстрые, поскольку фактический рендеринг происходит вне браузера.
SSG подает браузеру содержимое, которое ему необходимо, не требуя от него никаких дополнительных действий. У SSG-страниц, как и у CSR-страниц, также может возникнуть необходимость выполнить вызов API для того, чтобы извлечь данные с сервера. Это, конечно, увеличивает время загрузки.
В принципе, производительность веб-страницы определяется количеством JavaScript в ней.
Поисковая оптимизация (SEO – Search Engine Optimization)
Каждый веб-сайт, для которого важно, чтобы его видели пользователи, должен дорожить такой вещью, как поисковая оптимизация. SEO определяет то, насколько ваш сайт будет доступен в таких поисковых системах, как Google. К тому же, от поисковой оптимизации зависит то, насколько высоко будет находиться ваш сайт на страницах результатов поиска.
Давайте посмотрим на то, как воплощаются в жизнь все эти три метода при индексации поисковыми системами.
Поисковая оптимизация CSR
На CSR-страницах, как правило, нет какого-то содержательного контента, и, к тому же, для того, чтобы создать этот контент, они полностью полагаются на JS. Но здесь есть и подводные камни – не все поисковые роботы поддерживают JS, поэтому ваш веб-сайт может быть неверно проиндексирован в поисковых системах.
Поисковая оптимизация SSR
SSR отображает полноценные веб-страницы с актуальным содержимым, полученным с сервера. Поисковые системы вполне могут просканировать и проиндексировать SSR-страницы.
Поисковая оптимизация SSG
Для поискового робота не составит труда просканировать SSG-страницы, поскольку для полного отображения они не полагаются на JS.
Стоимость
Это важно, чтобы у пользователей оставались лишь хорошие впечатления от посещения веб-сайта, но счета сами себя не оплатят. Поэтому не менее важным моментом являются суммарные затраты на это взаимодействие, которые должны быть как можно меньше.
Расходы на каждый из методов рендеринга далеко не одинаковые. Ниже мы более подробно разберем, сколько стоит каждый из них.
Стоимость CSR
CSR на 100% выполняется в браузере. А это значит, что вам не нужно будет влезать в какие-то дополнительные расходы.
Стоимость SSR
SSR генерирует полноценную веб-страницу удаленно на сервере. А это значит, что вас ожидают дополнительные расходы, как денежные, так и ресурсные.
Стоимость SSG
Это бесплатно! Статические веб-сайт генерируется в процессе сборки. А это значит, что сгенерированные веб-страницы размещаются на хосте, и никакого дополнительного рендеринга на сервере не требуется.
Заключение
Когда вы будете выбирать между различными методами рендеринга, учитывайте то, для чего вы будете его использовать и что в таком случае больше всего подходит. Для этого вы, как раз, можете использовать информацию, которую узнали из этой статьи. Для разных веб-сайтов нужны различные методы рендеринга.
Разработчик торговой онлайн-площадки может пойти путем SSR или почувствовать себя в большей безопасности с SSG. Но с другой стороны, разработчик веб-приложений может согласиться на долгую первоначальную загрузку в том случае, если в результате это повлечет за собой лучшее взаимодействие с пользователями.
Неважно, какой метод рендеринга вы выберете, убедитесь, что ваш веб-сайт всегда доступен, за исключением ситуаций, с которыми вы вряд ли когда-то столкнетесь. И последнее, не забывайте соблюдать JS-диету.
