Asiakas- ja palvelinpuolen renderöinti: miksi kaikki eivät ole mustavalkoisia

Aikojen alusta lähtien tavanomainen tapa saada HTML ylös näytölle oli palvelinpuolen renderointi. Se oli ainoa tapa. Ladasit .html-sivusi palvelimellesi, palvelimesi meni ja muutti niistä hyödyllisiä asiakirjoja käyttäjien selaimissa.

Palvelinpuolen hahmontaminen toimi myös silloin hyvin, koska useimmat verkkosivut olivat enimmäkseen vain staattisten kuvien ja tekstin näyttämistä, mutta vuorovaikutteisuus oli vähäistä.

Nopeasti eteenpäin tänään, eikä se enää ole. Voit väittää, että verkkosivustot ovat nykyään enemmän sovelluksia, jotka teeskentelevät olevansa verkkosivustoja. Voit käyttää niitä lähettämään viestejä, päivittämään online-tietoja, ostoksia ja paljon muuta. Verkko on vain paljon kehittyneempi kuin ennen.

Joten on järkevää, että palvelinpuolen renderointi alkaa hitaasti olla takana jatkuvasti kasvavalle verkkosivujen renderointimenetelmälle asiakaspuolella.

Joten mikä menetelmä on parempi vaihtoehto? Kuten useimmissa kehitysvaiheissa, se riippuu todella siitä, mitä aiot tehdä verkkosivustollasi. Sinun on ymmärrettävä hyvät ja huonot puolet ja päätettävä sitten itse, mikä reitti sopii sinulle parhaiten.

Palvelinpuolen renderointi toimii

Palvelinpuolen renderointi on yleisin tapa näyttää tietoja näytöllä. Se toimii muuntamalla palvelimen HTML-tiedostot käyttökelpoisiksi tiedoiksi selaimelle.

Aina kun vierailet verkkosivustolla, selaimesi pyytää palvelimelta pyynnön, joka sisältää sivuston sisällön. Pyyntö kestää yleensä vain muutaman millisekunnin, mutta se riippuu viime kädessä monista tekijöistä:

  • Internet-nopeutesi
  • palvelimen sijainti
  • kuinka monta käyttäjää yrittää käyttää sivustoa
  • ja kuinka verkkosivusto on optimoitu muutamia mainitakseni

Kun pyyntö on käsitelty, selaimesi palauttaa täysin renderoidun HTML-koodin ja näyttää sen näytöllä. Jos päätät sitten käydä toisella verkkosivuston sivulla, selaimesi pyytää jälleen uutta tietoa. Tämä tapahtuu joka kerta, kun vierailet sivulla, jonka selaimellasi ei ole välimuistiversiota.

Ei ole väliä, onko uudella sivulla vain muutama erilainen kohde kuin nykyisellä sivulla, selain pyytää koko uuden sivun ja renderöi kaiken uudelleen alusta asti.

Otetaan esimerkiksi tämä HTML-asiakirja, joka on sijoitettu kuvitteelliselle palvelimelle, jonka HTTP-osoite on example.testsite.com.

    Example Website   

My Website

This is an example of my new website

Link

Jos kirjoitat esimerkkisivuston osoitteen kuvitteellisen selaimesi URL-osoitteeseen, kuvitteellinen selaimesi pyytää pyyntöä kyseisen URL-osoitteen käyttämältä palvelimelta ja odottaa, että selaimeen lähetetään jonkin verran tekstiä. Tässä tapauksessa visuaalisesti näet otsikon, kappaleen sisällön ja linkin.

Oletetaan nyt, että haluat napsauttaa linkkiä renderoidulta sivulta, joka sisältää seuraavan koodin.

    Example Website   

My Website

This is an example of my new website

This is some more content from the other.html

Ainoa ero edellisen sivun ja tämän välillä on, että tällä sivulla ei ole linkkiä ja sillä on toinen kappale. Logiikka sanelisi, että vain uusi sisältö olisi renderöitävä ja loput jätettävä yksin. Valitettavasti palvelinpuolen renderointi ei toimi näin. Todellisuudessa tapahtuisi, että koko uusi sivu renderöidään eikä vain uusi sisältö.

Vaikka näillä kahdella esimerkillä ei ehkä näytä olevan iso juttu, useimmat verkkosivustot eivät ole niin yksinkertaisia. Nykyaikaisilla verkkosivustoilla on satoja koodiriviä ja ne ovat paljon monimutkaisempia. Kuvittele nyt, että selaat verkkosivua ja joudut odottamaan jokaisen sivun renderointia, kun navigoit sivustolla. Jos olet koskaan käynyt WordPress-sivustossa, olet nähnyt kuinka hitaita ne voivat olla. Tämä on yksi syy miksi.

Kirkkaalta puolelta palvelinpuolen renderointi on loistava SEO: lle. Sisältösi on läsnä ennen kuin saat sen, joten hakukoneet pystyvät indeksoimaan sen ja indeksoimaan sen hienosti. Jotain, joka ei ole niin asiakaspuolen renderöinnissä. Ainakin ei yksinkertaisesti.

Kuinka asiakaspuolen renderointi toimii

Kun kehittäjät puhuvat asiakaspuolen renderoinnista, he puhuvat sisällön renderoinnista selaimessa JavaScriptin avulla. Joten sen sijaan, että saisit kaiken sisällön itse HTML-dokumentista, saat paljain luut HTML-asiakirjan JavaScript-tiedostolla, joka renderöi muun sivuston selaimen avulla.

Tämä on suhteellisen uusi lähestymistapa verkkosivustojen renderoinnissa, ja siitä ei tullut oikeastaan ​​suosittua ennen kuin JavaScript-kirjastot alkoivat sisällyttää sen kehitystyyliinsä. Joitakin merkittäviä esimerkkejä ovat Vue.js ja React.js, joista olen kirjoittanut lisää täällä.

Palataan edelliseen verkkosivuilla, example.testsite.comoletetaan, että teillä on nyt Index.html seuraavalla riviä koodia.

    Example Website 

Voit heti nähdä, että index.hmtl: n toimintatapaan on tehty joitain suuria muutoksia renderoitaessa asiakasta käyttämällä.

Ensinnäkin, sen sijaan että sinulla olisi sisältöä HTML-tiedostossa, sinulla on kontti div, jonka tunnus on root. Sinulla on myös kaksi komentosarjaelementtiä suoraan sulkevan rungon tagin yläpuolella. Yksi, joka lataa Vue.js-JavaScript-kirjaston ja toinen, joka lataa tiedoston nimeltä app.js.

Tämä on täysin erilainen kuin palvelinpuolen hahmonnuksen käyttö, koska palvelin on nyt vastuussa vain sivuston pelkän miinuksen lataamisesta. Pääkattilevy. Kaikkea muuta hoitaa asiakaspuolen JavaScript-kirjasto, tässä tapauksessa Vue.js ja mukautettu JavaScript-koodi.

Jos pyytäisit URL-osoitetta vain yllä olevalla koodilla, saat tyhjän ruudun. Ei ole mitään ladattavaa, koska todellinen sisältö on renderöitävä JavaScriptin avulla.

Voit korjata tämän asettamalla seuraavat koodirivit app.js-tiedostoon.

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', });

Nyt kun käyt URL-osoitteessa, näet saman sisällön kuin palvelinpuolen esimerkissä. Tärkein ero on, että jos lataat lisää sisältöä napsauttamalla sivun linkkiä, selain ei tee uutta pyyntöä palvelimelle. Renderöit kohteita selaimella, joten se käyttää sen sijaan JavaScriptiä uuden sisällön lataamiseen, ja Vue.js varmistaa, että vain uusi sisältö renderöidään. Kaikki muu jätetään yksin.

Tämä on paljon nopeammin, koska lataat vain hyvin pienen osan sivusta uuden sisällön noutamiseksi koko sivun lataamisen sijaan.

On kuitenkin joitain kompromisseja asiakaspuolen renderoinnin käytöstä. Koska sisältöä ei renderöidä ennen kuin sivu on ladattu selaimeen, verkkosivuston hakukoneoptimointi saa osuman. On olemassa tapoja kiertää tämä, mutta se ei ole niin helppoa kuin palvelinpuolen renderöinnissä.

Toinen mielessä pidettävä asia on, että verkkosivustoasi / sovellustasi ei voi ladata ennen kuin KAIKKI JavaScript on ladattu selaimeen. Mikä on järkevää, koska se sisältää kaiken tarvittavan sisällön. Jos käyttäjät käyttävät hidasta Internet-yhteyttä, se saattaa pidentää heidän alkuperäistä latausaikaa.

Kunkin lähestymistavan edut ja haitat

Joten sinulla on se. Nämä ovat tärkeimmät erot palvelin- ja asiakaspuolen renderoinnissa. Vain sinä kehittäjä voi päättää, mikä vaihtoehto on paras verkkosivustollesi tai sovelluksellesi.

Alla on nopea erittely kunkin lähestymistavan eduista ja haitoista:

Palvelinpuolen ammattilaiset:

  1. Hakukoneet voivat indeksoida sivuston parempaa hakukoneoptimointia varten.
  2. Sivun alkuperäinen lataus on nopeampaa.
  3. Erinomainen staattisille sivustoille.

Palvelinpuolen haitat:

  1. Usein palvelinpyynnöt.
  2. Yleinen hidas sivun renderointi.
  3. Koko sivu ladataan uudelleen.
  4. Rikkaiden sivustojen vuorovaikutukset.

Asiakaspuolen ammattilaiset:

  1. Monipuoliset sivustovaikutukset
  2. Nopea verkkosivustojen renderointi ensimmäisen latauksen jälkeen.
  3. Erinomainen verkkosovelluksiin.
  4. Vankka JavaScript-kirjastojen valinta.

Asiakaspuolen haitat:

  1. Matala SEO, jos sitä ei ole otettu käyttöön oikein.
  2. Alkukuorma voi vaatia enemmän aikaa.
  3. Useimmissa tapauksissa vaatii ulkoisen kirjaston.

Jos haluat oppia lisää Vue.js: stä, katso videoita ja artikkeleita verkkosivustoltani osoitteessa juanmvega.com!