- Как работает рендеринг на стороне сервера
- Как работает рендеринг на стороне клиента
- Плюсы и минусы каждого подхода
- Серверные плюсы:
Хуан Вега
С незапамятных времен обычным методом вывода HTML-кода на экран было использование рендеринга на стороне сервера. Это был единственный способ. Вы загрузили свои HTML-страницы на свой сервер, затем сервер перешел и превратил их в полезные документы в браузерах ваших пользователей.
Рендеринг на стороне сервера работал в то же время отлично, так как большинство веб-страниц были в основном только для отображения статических изображений и текста, с небольшим количеством интерактивности.
Перенесемся в будущее, и это уже не так. Вы можете утверждать, что веб-сайты в наши дни больше похожи на приложения, которые притворяются веб-сайтами. Вы можете использовать их, чтобы отправлять сообщения, обновлять информацию в Интернете, делать покупки и многое другое. Интернет намного более продвинут, чем раньше.
Поэтому имеет смысл, что рендеринг на стороне сервера постепенно начинает отодвигаться на задний план к постоянно растущему методу рендеринга веб-страниц на стороне клиента.
Так какой метод является лучшим вариантом? Как и в большинстве случаев в разработке, это действительно зависит от того, что вы планируете делать с вашим сайтом. Вы должны понять плюсы и минусы, а затем решить для себя, какой маршрут лучше для вас.
Как работает рендеринг на стороне сервера
Рендеринг на стороне сервера является наиболее распространенным способом отображения информации на экране. Он работает путем преобразования файлов HTML на сервере в полезную информацию для браузера.
Каждый раз, когда вы посещаете веб-сайт, ваш браузер отправляет запрос на сервер, который содержит содержимое веб-сайта. Запрос обычно занимает всего несколько миллисекунд, но это в конечном итоге зависит от множества факторов:
- Ваша скорость интернета
- расположение сервера
- сколько пользователей пытаются получить доступ к сайту
- и насколько оптимизирован сайт, чтобы назвать несколько
После завершения обработки запроса ваш браузер возвращает полностью отображенный HTML-код и отображает его на экране. Если вы затем решите посетить другую страницу на веб-сайте, ваш браузер еще раз сделает новый запрос новой информации. Это будет происходить каждый раз, когда вы посещаете страницу, на которой у вашего браузера нет кэшированной версии.
Не имеет значения, если на новой странице есть только несколько элементов, которые отличаются от текущей страницы, браузер запросит всю новую страницу и будет перерисовывать все с нуля.
Возьмем, к примеру, этот HTML-документ, который был размещен на воображаемом сервере с HTTP-адресом example.testsite.com.
<! DOCTYPE html> <html> <head> <meta charset = "utf-8"> <title> Пример веб-сайта </ title> </ head> <body> <h1> Мой веб-сайт </ h1> <p> This пример моего нового веб-сайта </ p> <a href="http://example.testsite.com/other.html."> ссылка </a> </ body> </ html>
Если вы введете адрес примера веб-сайта в URL вашего воображаемого браузера, ваш воображаемый браузер сделает запрос серверу, используемому этим URL, и ожидает ответа некоторого текста, который будет отображаться в браузере. В этом случае визуально вы увидите заголовок, содержание абзаца и ссылку.
Теперь предположим, что вы хотите нажать на ссылку с отображаемой страницы, которая содержит следующий код.
<! DOCTYPE html> <html> <head> <meta charset = "utf-8"> <title> Пример веб-сайта </ title> </ head> <body> <h1> Мой веб-сайт </ h1> <p> This пример моего нового веб-сайта </ p> <p> Это еще один контент из other.html </ p> </ body> </ html>
Единственная разница между предыдущей страницей и этой состоит в том, что эта страница не имеет ссылки, а вместо этого имеет другой абзац. Логика будет диктовать, что должен отображаться только новый контент, а остальное должно быть оставлено в покое. Увы, не так работает рендеринг на стороне сервера. На самом деле произойдет то, что будет отображена вся новая страница, а не только новый контент.
Хотя для этих двух примеров это может показаться не таким уж большим делом, большинство сайтов не так просты. Современные веб-сайты имеют сотни строк кода и являются гораздо более сложными. Теперь представьте, что вы просматриваете веб-страницу и должны ждать, пока каждая страница будет отображаться при навигации по сайту. Если вы когда-либо посещали сайт WordPress, вы видели, насколько медленными они могут быть. Это одна из причин, почему.
С другой стороны, рендеринг на стороне сервера отлично подходит для SEO. Ваш контент присутствует до того, как вы его получите, поэтому поисковые системы могут индексировать его и сканировать его очень хорошо. Что-то не так с рендерингом на стороне клиента. По крайней мере, не просто.
Как работает рендеринг на стороне клиента
Когда разработчики говорят о рендеринге на стороне клиента, они говорят о рендеринге контента в браузере с использованием JavaScript. Таким образом, вместо того, чтобы получать весь контент из самого документа HTML, вы получаете простой HTML-документ с файлом JavaScript, который будет отображать остальную часть сайта с помощью браузера.
Это относительно новый подход к визуализации веб-сайтов, и он действительно не стал популярным, пока библиотеки JavaScript не начали включать его в свой стиль разработки. Некоторые примечательные примеры Vue.js и React.js, которые я здесь написано больше ,
Возвращаясь к предыдущему веб-сайту example.testsite.com, предположим, что теперь у вас есть файл index.html со следующими строками кода.
<! DOCTYPE html> <html> <head> <meta charset = "utf-8"> <title> Пример веб-сайта </ title> </ head> <body> <div id = "root"> <app> </ app> </ div> <script src = "https://vuejs.org" type = "text / javascript"> </ script> <script src = "location / of / app.js" type = "text / javascript «> </ скрипт> </ body> </ html>
Вы можете сразу увидеть, что есть некоторые существенные изменения в том, как работает index.hmtl при рендеринге с использованием клиента.
Для начала, вместо того, чтобы иметь содержимое внутри HTML-файла, у вас есть контейнер div с идентификатором root. У вас также есть два элемента script прямо над закрывающим тегом body. Тот, который загрузит библиотеку JavaScript Vue.js, и тот, который загрузит файл с именем app.js.
Это радикально отличается от использования рендеринга на стороне сервера, поскольку теперь сервер отвечает только за загрузку «голого» минуса веб-сайта. Основной шаблон. Все остальное обрабатывается клиентской библиотекой JavaScript, в данном случае Vue.js и пользовательским кодом JavaScript.
Если вы сделаете запрос на URL только с кодом выше, вы получите пустой экран. Загружать нечего, так как реальный контент должен отображаться с использованием JavaScript.
Чтобы это исправить, вы должны поместить следующие строки кода в файл app.js.
var data = {title: «Мой сайт», сообщение: «Это пример моего нового сайта»} Vue.component ('app', {template: `<div> <h1> {{title}} </ h1 > <p id = "moreContent"> {{message}} </ p> <a v-on:click='newContent'> Link </a> </ div> `, data: function () {return data; }, методы: {newContent: function () {var node = document.createElement ('p'); var textNode = document.createTextNode ('Это еще немного контента из other.html'); node.appendChild (textNode) ; document.getElementById ('moreContent'). appendChild (node);}}}) new Vue ({el: '#root',});
Теперь, если вы зайдете на URL, вы увидите то же содержимое, что и на примере сервера. Основное отличие состоит в том, что если вы нажмете на ссылку на странице, чтобы загрузить больше контента, браузер не будет делать еще один запрос к серверу. Вы визуализируете элементы с помощью браузера, поэтому вместо этого он будет использовать JavaScript для загрузки нового содержимого, а Vue.js будет следить за тем, чтобы отображался только новый контент. Все остальное останется в покое.
Это намного быстрее, так как вы загружаете только очень маленький раздел страницы для загрузки нового контента, а не загружаете всю страницу.
Однако при использовании рендеринга на стороне клиента есть некоторые недостатки. Так как контент не отображается, пока страница не загружена в браузер, SEO для веб-сайта будет иметь успех. Есть способы обойти это, но это не так просто, как при рендеринге на стороне сервера.
Следует также помнить, что ваш веб-сайт / приложение не сможет загружаться, пока ВСЕ JavaScript не будет загружен в браузер. Что имеет смысл, поскольку содержит весь контент, который будет необходим. Если ваши пользователи используют медленное интернет-соединение, это может сделать их начальное время загрузки немного большим.
Плюсы и минусы каждого подхода
Так что у вас есть это. Это основные различия между рендерингом на стороне сервера и на стороне клиента. Только вы, разработчик, можете решить, какой вариант лучше всего подходит для вашего веб-сайта или приложения.
Ниже приводится краткое описание плюсов и минусов для каждого подхода:
Серверные плюсы:
- Поисковые системы могут сканировать сайт для лучшего SEO.
- Начальная загрузка страницы происходит быстрее.
- Отлично подходит для статических сайтов.
Недостатки на стороне сервера:
- Частые запросы к серверу.
- Общий медленный рендеринг страницы.
- Полная страница перезагрузится.
- Небогатые взаимодействия сайта.
Клиентские плюсы:
- Богатое взаимодействие с сайтом
- Быстрый рендеринг сайта после начальной загрузки.
- Отлично подходит для веб-приложений.
- Надежный выбор библиотек JavaScript.
Минусы на стороне клиента:
- Низкий SEO, если не реализован правильно.
- Начальная загрузка может потребовать больше времени.
- В большинстве случаев требуется внешняя библиотека.
Если вы хотите узнать больше о Vue.js, проверьте VueReactor.com , Вы также можете посетить juanmvega.com чтобы быть в курсе моих последних историй.
Так какой метод является лучшим вариантом?
