Az idők hajnala óta a HTML-ek képernyőre juttatásának hagyományos módja a szerveroldali renderelés volt. Ez volt az egyetlen út. Betöltötted a .html oldalaidat a szerveredre, majd a szerver elment és hasznos dokumentumokká alakította azokat a felhasználók böngészőiben.

A szerveroldali renderelés akkor is remekül működött, mivel a legtöbb weboldal többnyire csak statikus képek és szövegek megjelenítésére szolgál, kevéssé befolyásolva az interaktivitást.

Gyors előre a mai napra, és ez már nem így van. Lehet azzal érvelni, hogy a webhelyek manapság inkább olyan alkalmazásokhoz hasonlítanak, mintha weboldalak lennének. Használhatja őket üzenetek küldésére, online információk frissítésére, vásárlásra és még sok minden másra. Az internet csak sokkal fejlettebb, mint korábban.

Tehát van értelme, hogy a szerveroldali renderelés lassan kezd háttérbe szorulni a weblapok ügyféloldali renderelésének egyre növekvő módszerével.

Tehát melyik módszer a jobb megoldás? Mint a legtöbb fejlesztés alatt álló dolog, ez valóban attól függ, hogy mit tervez a webhelyével. Meg kell értenie az előnyöket és hátrányokat, majd maga döntse el, melyik útvonal a legmegfelelőbb.

Hogyan működik a szerveroldali megjelenítés

A kiszolgálóoldali megjelenítés a leggyakoribb módszer az információk képernyőn történő megjelenítésére. Úgy működik, hogy a szerver HTML-fájljait a böngésző számára használható információkká alakítja át.

Amikor meglátogat egy weboldalt, a böngészője kérést intéz a szerverhez, amely tartalmazza a weboldal tartalmát. A kérés általában csak néhány ezredmásodpercet vesz igénybe, de ez végül tényezők sokaságától függ:

• Az internet sebessége
• a szerver helye
• hány felhasználó próbál hozzáférni a webhelyhez
• és mennyire optimalizált a weboldal, hogy csak néhányat említsünk

A kérelem feldolgozása után a böngésző visszakapja a teljesen renderelt HTML-t, és megjeleníti azt a képernyőn. Ha ezután úgy dönt, hogy meglátogat egy másik oldalt a webhelyen, a böngészője ismét újabb kérést fog benyújtani az új információkhoz. Ez minden egyes alkalommal előfordul, amikor olyan oldalra látogat, amelynek böngészője nem rendelkezik gyorsítótárazott verzióval.

Nem számít, hogy az új oldalon csak néhány elem különbözik-e az aktuális oldaltól, a böngésző az egész új oldalt kéri, és mindent az alapoktól kezdve renderel.

Vegyük például ezt a HTML dokumentum került a képzeletbeli szerver egy HTTP címét example.testsite.com.

    Example Website   
My Website
This is an example of my new website
 Link  

Ha beírná a példa webhely címét a képzeletbeli böngészője URL-jébe, akkor a képzeletbeli böngészője kérést küldene az adott URL által használt kiszolgálóhoz, és arra számítana, hogy valamilyen szöveges válasz érkezik a böngészőbe. Ebben az esetben vizuálisan látná a címet, a bekezdés tartalmát és a linket.

Most tegyük fel, hogy a megjelenített oldalon a következő kódot tartalmazó linkre szeretett volna kattintani.

    Example Website   
My Website
This is an example of my new website
This is some more content from the other.html

Az egyetlen különbség az előző és ez között az, hogy ennek az oldalnak nincs linkje, ehelyett van egy másik bekezdése. A logika azt diktálná, hogy csak az új tartalmat szabad megjeleníteni, a többit pedig magára kell hagyni. Jaj, a kiszolgálóoldali megjelenítés nem így működik. Valójában az következne, hogy az egész új oldal megjelenik, és nem csak az új tartalom.

Bár ez a két példa nem tűnhet nagy ügynek, a legtöbb weboldal nem ilyen egyszerű. A modern weboldalak több száz soros kóddal rendelkeznek, és sokkal összetettebbek. Most képzelje el, hogy böngészhet egy weboldalt, és meg kell várnia, amíg minden oldal megjelenik, amikor a webhelyen navigál. Ha valaha is ellátogatott egy WordPress webhelyre, látta, milyen lassúak lehetnek. Ez az egyik oka annak.

Ami a jó oldalát illeti, a szerveroldali megjelenítés nagyszerű a SEO számára. A tartalma jelen van, mielőtt megszerezné, így a keresőmotorok képesek indexelni és feltűnően feltérképezni. Valami, ami nem így van az ügyféloldali megjelenítésnél. Legalábbis nem egyszerűen.

Hogyan működik az ügyféloldali megjelenítés

Amikor a fejlesztők kliensoldali renderelésről beszélnek, akkor a böngészőben a JavaScript használatával történő megjelenítésről beszélnek. Tehát ahelyett, hogy az összes tartalmat magából a HTML-dokumentumból szerezné be, egy csupasz csontú HTML-dokumentumot kap egy JavaScript-fájllal, amely a webhely többi részét a böngésző segítségével rendereli.

Ez egy viszonylag új megközelítés a weboldalak megjelenítéséhez, és csak akkor vált népszerűvé, ha a JavaScript könyvtárak elkezdték beépíteni a fejlesztési stílusukba. Néhány figyelemre méltó példa a Vue.js és a React.js, amelyekről itt többet írtam.

Visszatérve az előző webhelyre, example.testsite.comtegyük fel, hogy mostantól rendelkezik egy index.html fájllal a következő kódsorokkal.

    Example Website 

Rögtön láthatja, hogy az index.hmtl működésében van néhány jelentős változás az ügyfél használatával történő rendereléskor.

Először is, ahelyett, hogy a tartalom benne lenne a HTML fájlban, van egy tároló div, amelynek azonosítója root. Két szkripteleme is van közvetlenül a záró törzscímke felett. Az egyik, amely betölti a Vue.js JavaScript könyvtárat, és amely az app.js nevű fájlt tölti be.

Ez gyökeresen különbözik a kiszolgálóoldali megjelenítéstől, mert a kiszolgáló már csak a weboldal puszta mínuszának betöltéséért felelős. A fő kazán. Minden mást egy kliensoldali JavaScript könyvtár kezel, ebben az esetben a Vue.js és az egyedi JavaScript kód.

Ha csak a fenti kódot igényelne az URL-re, akkor üres képernyő jelenik meg. Nincs mit betölteni, mivel a tényleges tartalmat JavaScript használatával kell megjeleníteni.

Ennek kijavításához a következő kódsorokat helyezze el az app.js fájlba.

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

Most, ha meglátogatja az URL-t, ugyanazt a tartalmat látja, mint a szerveroldali példa. A legfontosabb különbség az, hogy ha az oldal linkjére kattintva további tartalmat tölt be, a böngésző nem fog újabb kérést küldeni a szervernek. Az elemeket a böngészővel rendereli, így ehelyett a JavaScript használatával tölti be az új tartalmat, és a Vue.js biztosítja, hogy csak az új tartalmat jelenítsék meg. Minden más egyedül marad.

Ez sokkal gyorsabb, mivel a teljes oldal betöltése helyett az oldal nagyon kis részét tölti be az új tartalom letöltéséhez.

Van néhány kompromisszum az ügyféloldali megjelenítés használatával. Mivel a tartalom nem jelenik meg addig, amíg az oldal nem töltődik be a böngészőbe, a webhely keresőmotorja ütést ér el. Vannak módok ennek megkerülésére, de ez nem olyan egyszerű, mint a szerveroldali renderelésnél.

Egy másik dolog, amelyet szem előtt kell tartani, hogy webhelyét / alkalmazását csak akkor töltheti be, ha MINDEN JavaScriptet letölt a böngészőbe. Ennek van értelme, mivel minden szükséges tartalmat tartalmaz. Ha a felhasználók lassú internetkapcsolatot használnak, ez kissé meghosszabbíthatja a kezdeti betöltési idejüket.

Az egyes megközelítések előnyei és hátrányai

Tehát itt van. Ezek a fő különbségek a szerver- és az ügyféloldali megjelenítés között. Csak Ön, a fejlesztő döntheti el, hogy melyik opció a legjobb az Ön webhelyéhez vagy alkalmazásához.

Az alábbiakban bemutatjuk az egyes megközelítések előnyeit és hátrányait:

Szerveroldali profik:

1. A keresőmotorok feltérképezhetik a webhelyet a jobb SEO érdekében.
2. A kezdeti oldal betöltése gyorsabb.
3. Nagyszerű statikus helyszínekhez.

Szerveroldali hátrányok:

1. Gyakori szerverkérések.
2. Általános lassú oldalmegjelenítés.
3. A teljes oldal újratöltődik.
4. Nem gazdag webhely-interakciók.

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!