Візуалізація на стороні клієнта проти сервера: чому це не все чорно-біле

З самого початку часу звичайним методом виведення HTML-коду на екран було використання візуалізації на стороні сервера. Це був єдиний спосіб. Ви завантажили свої .html сторінки на свій сервер, а потім ваш сервер перетворив їх на корисні документи у браузерах ваших користувачів.

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

Перемотування вперед до сьогоднішнього дня, і це вже не так. Можна стверджувати, що веб-сайти в наш час більше схожі на програми, які видають себе за веб-сайти. Ви можете використовувати їх для надсилання повідомлень, оновлення інформації в Інтернеті, здійснення покупок тощо. Інтернет просто набагато прогресивніший, ніж був раніше.

Тому має сенс, що рендеринг на стороні сервера поступово починає відходити на постійно зростаючий метод рендерингу веб-сторінок на стороні клієнта.

Тож який метод є кращим варіантом? Як і більшість речей у розробці, це насправді залежить від того, що ви плануєте робити зі своїм веб-сайтом. Потрібно зрозуміти плюси і мінуси, а потім вирішити самостійно, який маршрут найкращий для вас.

Як працює візуалізація на стороні сервера

Візуалізація на стороні сервера є найпоширенішим способом відображення інформації на екрані. Це працює, перетворюючи файли HTML на сервері в корисну інформацію для браузера.

Щоразу, коли ви відвідуєте веб-сайт, ваш браузер робить запит на сервер, що містить вміст веб-сайту. Запит зазвичай займає лише кілька мілісекунд, але це врешті-решт залежить від безлічі факторів:

  • Швидкість вашого Інтернету
  • розташування сервера
  • скільки користувачів намагається отримати доступ до сайту
  • і наскільки оптимізований веб-сайт, щоб назвати декілька

Після обробки запиту ваш браузер повертає повністю відтворений HTML і відображає його на екрані. Якщо після цього ви вирішите відвідати іншу сторінку веб-сайту, ваш браузер ще раз зробить новий запит на нову інформацію. Це трапляється кожного разу, коли ви відвідуєте сторінку, у якій ваш браузер не має кешованої версії.

Неважливо, чи буде на новій сторінці лише декілька елементів, які відрізняються від поточної сторінки, браузер запитає всю нову сторінку і відтворить все з нуля.

Візьмемо для прикладу цей документ HTML, розміщений на уявному сервері з HTTP-адресою example.testsite.com.

    Example Website   

My Website

This is an example of my new website

Link

Якщо ви повинні ввести адресу веб-сайту-прикладу в URL-адресу вашого уявного браузера, ваш уявний браузер зробить запит на сервер, що використовується цією URL-адресою, і очікує відповіді деякого тексту, який відображатиметься у браузері. У цьому випадку візуально ви побачите заголовок, зміст абзацу та посилання.

Тепер припустимо, що ви хотіли натиснути на посилання на відтвореній сторінці, яка містить наступний код.

    Example Website   

My Website

This is an example of my new website

This is some more content from the other.html

Єдина різниця між попередньою сторінкою та цією полягає в тому, що ця сторінка не має посилання, а натомість має інший абзац. Логіка диктувала б, що лише новий вміст повинен бути відтворений, а решту залишити в спокої. На жаль, не так працює рендеринг на стороні сервера. Насправді сталося б так, що була б відображена вся нова сторінка, а не лише новий вміст.

Хоча для цих двох прикладів це може здатися не великою справою, більшість веб-сайтів не такі прості. Сучасні веб-сайти мають сотні рядків коду і набагато складніші. А тепер уявіть, що ви переглядаєте веб-сторінку та чекаєте, поки кожна сторінка відобразиться під час навігації по сайту. Якщо ви коли-небудь відвідували сайт WordPress, ви бачили, наскільки вони можуть бути повільними. Це одна з причин.

З іншого боку, рендеринг на стороні сервера чудово підходить для SEO. Ваш вміст присутній ще до того, як ви його отримаєте, тому пошукові системи можуть його проіндексувати та просканувати. Щось не так з візуалізацією на стороні клієнта. Принаймні не просто.

Як працює візуалізація на стороні клієнта

Коли розробники говорять про візуалізацію на стороні клієнта, вони говорять про візуалізацію вмісту в браузері за допомогою JavaScript. Отже, замість того, щоб отримувати весь вміст із самого HTML-документа, ви отримуєте HTML-документ з оголеними кістками з файлом JavaScript, який відображатиме решту сайту за допомогою браузера.

Це відносно новий підхід до рендерингу веб-сайтів, і він насправді не став популярним, поки бібліотеки JavaScript не почали включати його у свій стиль розробки. Деякі помітні приклади - Vue.js та React.js, про які я писав більше тут.

Повертаючись до попереднього веб-сайту, example.testsite.comприпустимо, що тепер у вас є файл index.html із наступними рядками коду.

    Example Website 

Ви можете відразу помітити, що в процесі роботи index.hmtl при отрисуванні за допомогою клієнта є деякі серйозні зміни.

Для початку, замість вмісту всередині файлу HTML, у вас є контейнер div з ідентифікатором кореня. У вас також є два елементи сценарію прямо над закриваючим тегом body. Той, який завантажить бібліотеку JavaScript Vue.js, і той, який завантажить файл app.js.

Це кардинально відрізняється від використання рендерингу на стороні сервера, оскільки сервер тепер відповідає лише за завантаження простого мінусу веб-сайту. Основний шаблон. Все інше обробляється клієнтською бібліотекою JavaScript, в даному випадку Vue.js та користувацьким кодом JavaScript.

Якщо ви хочете зробити запит на URL-адресу, використовуючи лише наведений вище код, ви отримаєте порожній екран. Завантажувати нічого, оскільки фактичний вміст потрібно відтворювати за допомогою JavaScript.

Щоб це виправити, слід розмістити наступні рядки коду у файлі app.js.

var data = { title:"My Website", message:"This is an example of my new website" } Vue.component('app', { template: ` 

{{title}}

{{message}}

Link `, data: function() { return data; }, methods:{ newContent: function(){ var node = document.createElement('p'); var textNode = document.createTextNode('This is some more content from the other.html'); node.appendChild(textNode); document.getElementById('moreContent').appendChild(node); } } }) new Vue({ el: '#root', });

Now if you visit the URL, you would see the same content as you did the server-side example. The key difference is that if you were to click on the link the page to load more content, the browser will not make another request to the server. You are rendering items with the browser, so it will instead use JavaScript to load the new content and Vue.js will make sure that only the new content is rendered. Everything else will be left alone.

This is much faster since you are only loading a very small section of the page to fetch the new content, instead of loading the entire page.

There are some trade offs with using client-side rendering, though. Since the content is not rendered until the page is loaded on the browser, SEO for the website will take a hit. There are ways to get around this, but it’s not as easy as it is with server-side rendering.

Another thing to keep in mind is that your website/application won’t be able to load until ALL of the JavaScript is downloaded to the browser. Which makes sense, since it contains all the content that will be needed. If your users are using slow internet connection, it could make their initial loading time a bit long.

The pros and cons of each approach

So there you have it. Those are the main differences between server-side and client-side rendering. Only you the developer can decide which option is best for your website or application.

Below is a quick breakdown of the pros and cons for each approach:

Server-side pros:

  1. Search engines can crawl the site for better SEO.
  2. The initial page load is faster.
  3. Great for static sites.

Server-side cons:

  1. Frequent server requests.
  2. An overall slow page rendering.
  3. Full page reloads.
  4. Non-rich site interactions.

Client-side pros:

  1. Rich site interactions
  2. Fast website rendering after the initial load.
  3. Great for web applications.
  4. Robust selection of JavaScript libraries.

Client-side cons:

  1. Low SEO if not implemented correctly.
  2. Initial load might require more time.
  3. In most cases, requires an external library.

If you want to learn more about Vue.js, check out my website at juanmvega.com for videos and articles!