Kliendipoolne renderdamine vs serveripoolne renderdamine

Algselt olid veebiraamid vaateid serveris esitanud. Nüüd toimub see kliendil. Uurime iga lähenemisviisi eeliseid ja puudusi.

Etendus

Serveripoolse renderdamise korral peate alati välja minema ja selle saama, kui soovite uut veebilehte näha:

Serveripoolse renderdamise toimimise skeem

See on analoogne sellega, kui sõidate supermarketisse iga kord, kui soovite süüa.

Kliendipoolse renderdamisega lähete üks kord supermarketisse ja kulutate 45 minutit jalgsi ringi, et osta kuu kaupa hunnik toite. Siis, kui soovite süüa, avage lihtsalt külmkapi.

Kliendipoolse renderdamise toimimise skeem

Igal lähenemisel on jõudluse osas oma plussid ja miinused:

  • Kliendipoolse renderdamise korral läheb lehe esialgne laadimine aeglaseks. Kuna võrgu kaudu suhtlemine on aeglane ja enne kui hakkate kasutajale sisu kuvama, kulub serverisse kaks edasi-tagasi sõitu. Kuid pärast seda on iga järgmine lehe laadimine lõõmavalt kiire.
  • Serveripoolse renderdamise korral pole lehe esialgne laadimine kohutavalt aeglane. Kuid see ei saa kiiresti olema. Ja mitte ükski teie teine ​​taotlus.

Täpsemalt öeldes näeb kliendilehe renderdamise korral esimene leht välja umbes selline:


  
     
    
  
  
    
  

app.js sisaldab kõiki HTML-lehti JavaScripti kujul stringidena. Midagi sellist:

var pages = {
  '/': ' ... ',
  '/ foo': ' ... ',
  '/ bar': ' ... ',
};

Siis, kui leht on laaditud, vaatab raamistik URL-i riba, hangib stringi lehtedelt ['/'] ja sisestab selle

. Samuti lingid klõpsamisel haarab raamistik sündmuse kinni, lisab konteinerisse uue stringi (nt lehed ['/ foo']) ja takistab brauseril HTTP päringu väljalülitamist, nagu tavaliselt.

SEO

Oletame, et meie veebiandur alustab reddit.com-i päringu esitamist:

var request = nõuda ('taotlema');
request.get ('reddit.com', funktsioon (tõrge, vastus, sisu) {
  // keha näeb välja umbes selline:
  // 
  //  ... 
  // 
  //  ESPN 
  //  Hackeri uudised 
  // ... muud  sildid ...
});

Seejärel kasutab indekseerija vastuskehas asju uute taotluste genereerimiseks:

var request = nõuda ('taotlema');
request.get ('reddit.com', funktsioon (tõrge, vastus, sisu) {
  // keha näeb välja umbes selline:
  // 
  //  ... 
  // 
  //  ESPN 
  //  Hackeri uudised 
  // ... muud  sildid ...
  request.get ('espn.com', funktsioon () {...});
  request.get ('news.ycombinator.com', funktsioon () {...});
});

Pärast seda jätkab indekseerija protsessi, kasutades indekseerimise jätkamiseks linke espn.com ja news.ycombinator.com.

Siin on mõni rekursiivne kood selle tegemiseks:

var request = nõuda ('taotlema');
funktsioon indekseerimineUrl (URL) {
  request.get (URL, funktsioon (tõrge, vastus, sisu) {
    var linkUrls = getLinkUrls (keha);
    linkUrls.forEach (funktsioon (linkUrl) {
      indekseerimineUrl (linkUrl);
    });
  });
}
indekseeriUrl ('reddit.com');

Mis juhtuks, kui reageerimisasutus näeks välja selline:


  
     
    
  
  
    
  

Noh, silte pole, mida jälgida. Samuti näeb see veebileht üsna kentsakas välja, nii et me ei taha ilmselt otsingutulemite kuvamisel seda tähtsuse järjekorda seada.

Integreerija teab vähe, kliendiraamistik täidab

hunniku vinge sisuga.

Seetõttu võib kliendipoolne renderdamine SEO-le halvasti mõjuda.

Eelrenderdamine

2009. aastal tutvustas Google viisi selle saavutamiseks.

https://webmasters.googleblog.com/2009/10/proposed-for-making-ajax-crawlable.html

Kui indekseerija jõuab saidile www.example.com/page?query#!mystate, teisendab ta selle saidiks www.example.com/page?query&_escaped_fragment_=mystate. Nii saab teie server, kui taotlus on _escaped_fragment_, teada, et päring tuleb indeksoijalt, mitte inimeselt.

Pidage meeles - server soovib, et indekseerija näeks

...
(sisuga), mitte
. Nii siis:

  • Kui päring pärineb indeksoijalt, võiksime teenindada
    ...
    .
  • Kui päring on tavalise inimese käest, võiksime lihtsalt teenida
    ja lasta JavaScriptil selle sisusse lisada.

Siiski on probleem: server ei tea, mis toimub

sees. Sisemuse väljaselgitamiseks peaks ta käivitama JavaScripti, looma DOM-i ja kasutama seda DOM-i. Kuna traditsioonilised veebiserverid ei tea, kuidas seda teha, kasutavad nad selleks peata brauserina tuntud teenust.

Nutikamad indekseerijad

Kuus aastat hiljem teatas Google, et selle roomik tasandus! Kui indeksoija 2.0 näeb