Клиентско срещу сървърно изобразяване: защо не всичко е черно-бяло

От зората на времето конвенционалният метод за извеждане на вашия 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 на контейнер с идентификатор на root. Имате и два елемента на скрипта точно над затварящия таг на тялото. Един, който ще зареди Vue.js JavaScript библиотеката и един, който ще зареди файл, наречен 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!