Kliendipoolne vs serveripoolne renderdamine: miks see pole kõik mustvalge?

Alates aja algusest oli tavapärane meetod HTML-i kuvamiseks ekraanil serveripoolse renderdamise abil. See oli ainus viis. Laadisite oma .html lehed oma serverisse, siis läks teie server ja muutis need teie kasutajate brauserites kasulikeks dokumentideks.

Serveripoolne renderdamine toimis ka sel ajal suurepäraselt, kuna enamus veebisaite olid enamasti mõeldud ainult staatiliste piltide ja teksti kuvamiseks, vähese interaktiivsusega.

Kiirelt edasi tänasesse päeva ja see pole enam nii. Võiksite väita, et tänapäeval on veebisaidid pigem sellised rakendused, mis teesklevad end veebisaitidena. Saate neid kasutada sõnumite saatmiseks, veebiteabe värskendamiseks, ostude tegemiseks ja palju muuks. Veeb on lihtsalt palju arenenum kui varem.

Seega on mõistlik, et serveripoolne renderdamine hakkab aeglaselt taganema pidevalt kasvavale veebisaitide renderdamise meetodile kliendipoolel.

Milline meetod on siis parem variant? Nagu enamiku arendatavate asjade puhul, sõltub see ka tegelikult sellest, mida kavatsete oma veebisaidiga teha. Peate mõistma plusse ja miinuseid, seejärel otsustama ise, milline marsruut on teie jaoks parim.

Kuidas serveripoolne renderdamine töötab

Serveripoolne renderdamine on kõige levinum meetod teabe kuvamiseks ekraanil. See toimib, muutes serveris olevad HTML-failid brauseri jaoks kasutatavaks teabeks.

Kui külastate mõnda veebisaiti, esitab teie brauser serverile päringu, mis sisaldab veebisaidi sisu. Taotlus võtab tavaliselt vaid paar millisekundit, kuid see sõltub lõpuks paljudest teguritest:

  • Teie Interneti-kiirus
  • serveri asukoht
  • mitu kasutajat proovivad saidile juurde pääseda
  • ja kui optimeeritud on veebisait, kui nimetada vaid mõnda

Kui päring on töödeldud, saab teie brauser täielikult renderdatud HTML-i tagasi ja kuvab selle ekraanil. Kui otsustate seejärel veebisaidil mõnda muud lehte külastada, esitab teie brauser uuesti uue teabe saamiseks uue taotluse. See juhtub iga kord, kui külastate lehte, mille brauseril pole vahemällu salvestatud versiooni.

Pole tähtis, kas uuel lehel on ainult mõned üksused, mis erinevad praegusest lehest, brauser küsib kogu uut lehte ja renderdab kõik uuesti algusest peale.

Võtame näiteks selle HTML-dokumendi, mis on paigutatud kujuteldavasse serverisse, mille HTTP-aadress on example.testsite.com.

    Example Website   

My Website

This is an example of my new website

Link

Kui sisestate näite veebisaidi aadressi oma kujuteldava brauseri URL-i, esitab teie kujuteldav brauser taotluse selle URL-i kasutatavale serverile ja eeldab, et brauserisse saadetakse mõne teksti vastus. Sel juhul näeksite visuaalselt pealkirja, lõigu sisu ja linki.

Oletame nüüd, et soovisite klõpsata renderdatud lehe lingil, mis sisaldab järgmist koodi.

    Example Website   

My Website

This is an example of my new website

This is some more content from the other.html

Ainus erinevus eelmise ja selle vahel on see, et sellel lehel pole linki ja selle asemel on teine ​​lõik. Loogika näeks ette, et renderdada tuleks ainult uut sisu ja ülejäänu tuleks jätta rahule. Paraku serveripoolne renderdamine nii ei käi. Mis tegelikult juhtuks, oleks renderdatud kogu uus leht ja mitte ainult uus sisu.

Ehkki nende kahe näite puhul ei pruugi see eriti suur asi tunduda, pole enamik veebisaite nii lihtsad. Kaasaegsetel veebisaitidel on sadu koodiridu ja need on palju keerukamad. Kujutage nüüd ette, et sirvite mõnda veebisaiti ja peate saidil navigeerimisel ootama iga lehe renderdamist. Kui olete kunagi WordPressi saiti külastanud, olete näinud, kui aeglased need võivad olla. See on üks põhjus, miks.

Hele külg on serveripoolne renderdamine SEO jaoks suurepärane. Teie sisu on olemas enne selle saamist, nii et otsingumootorid saavad seda indekseerida ja roomata. Midagi, mis pole nii kliendipoolsel renderdamisel. Vähemalt mitte lihtsalt.

Kuidas kliendipoolne renderdamine töötab

Kui arendajad räägivad kliendipoolsest renderdamisest, räägivad nad brauseris sisu renderdamisest JavaScripti abil. Nii et selle asemel, et kogu sisu HTML-dokumendist ise hankida, saate selle asemel JavaScripti failiga paljaste kontidega HTML-dokumendi, mis renderdab brauseri abil ülejäänud saidi.

See on suhteliselt uus lähenemisviis veebisaitide renderdamisel ja see ei saanud tegelikult populaarseks enne, kui JavaScripti teegid hakkasid seda oma arendusstiili kaasama. Mõned märkimisväärsed näited on Vue.js ja React.js, millest olen siin rohkem kirjutanud.

Eelmisele veebisaidile tagasi tulles example.testsite.comeeldame, et teil on nüüd fail index.html järgmiste koodiridadega.

    Example Website 

Kohe näete, et kliendi abil renderdamisel on index.hmtl toimimises mõned olulised muudatused.

Alustuseks on teil HTML-failis sisu asemel konteiner div, mille juur ID on. Sul on ka kaks skriptielementi otse sulgeva kehamärgendi kohal. Üks, mis laadib Vue.js JavaScripti teegi ja teine, mis laadib faili nimega app.js.

See erineb radikaalselt serveripoolse renderdamise kasutamisest, sest server vastutab nüüd ainult veebisaidi tühja miinuse laadimise eest. Põhikatla. Kõige muuga tegeleb kliendipoolne JavaScripti teek, antud juhul Vue.js ja kohandatud JavaScripti kood.

Kui teete URL-ile taotluse ainult ülaltoodud koodiga, saate tühja ekraani. Pole midagi laadida, sest tegelik sisu tuleb renderdada JavaScripti abil.

Selle parandamiseks paigutate järgmised koodiread faili 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.

Kliendipoolsed plussid:

  1. Rikkad saidisuhted
  2. Kiire veebisaidi renderdamine pärast esmast laadimist.
  3. Suurepärane veebirakenduste jaoks.
  4. Tugev valik JavaScripti teeke.

Kliendipoolsed miinused:

  1. Madal SEO, kui seda pole õigesti rakendatud.
  2. Esialgne laadimine võib vajada rohkem aega.
  3. Enamasti nõuab välist teeki.

Kui soovite Vue.js-i kohta rohkem teada saada, vaadake videoid ja artikleid minu veebisaidilt juanmvega.com!