Gengivelse af klientsiden vs. rendering på serversiden

Oprindeligt havde webrammer visninger gengivet på serveren. Nu sker det på klienten. Lad os undersøge fordele og ulemper ved hver tilgang.

Ydeevne

Med rendering på serversiden skal du hver gang du ønsker at se en ny webside gå ud og hente den:

Dette er analogt med, at du kører over til supermarkedet, hver gang du vil spise.

Med gengivelse fra klientsiden går du en gang til supermarkedet og bruger 45 minutter på at gå rundt med at købe en masse mad til måneden. Derefter, når du vil spise, åbner du bare køleskabet.

Hver tilgang har sine fordele og ulemper, når det kommer til ydeevne:

• Med gengivelse fra klientsiden vil den indledende sidebelastning være langsom. Fordi kommunikationen via netværket er langsom, og det tager to rundrejser til serveren, før du kan begynde at vise indhold til brugeren. Efter dette vil hver efterfølgende sideindlæsning imidlertid glide hurtigt.
• Ved gengivelse på serversiden vil den indledende sidebelastning ikke være meget langsom. Men det vil ikke være hurtigt. Og ingen af ​​dine andre anmodninger vil heller ikke.

For at være mere specifik med rendering af klientsiden ser den første side sådan ud:

app.js har alle HTML-sider i JavaScript som strenge. Noget som dette:

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

Når siden derefter er indlæst, vil rammen se på URL-linjen, få strengen på siderne ['/'] og indsætte den i

. Når du klikker på links, vil rammerne også aflytte begivenheden, indsætte den nye streng (sig, sider ['/ foo']) i beholderen og forhindre, at browseren afbryder HTTP-anmodningen, som den normalt gør.

SEO

Antag, at vores webcrawler starter med at anmode om reddit.com:

var request = kræve ('anmodning');
request.get ('reddit.com', funktion (fejl, respons, krop) {
  // krop ser sådan ud:
  // 
  //  ... 
  // 
  //  ESPN 
  //  Hacker News 
  // ... andre  tags ...
});

Crawleren bruger derefter tingene i svarorganet til at generere nye anmodninger:

var request = kræve ('anmodning');
request.get ('reddit.com', funktion (fejl, respons, krop) {
  // krop ser sådan ud:
  // 
  //  ... 
  // 
  //  ESPN 
  //  Hacker News 
  // ... andre  tags ...

  request.get ('espn.com', funktion () {...});
  request.get ('news.ycombinator.com', funktion () {...});
});

Herefter fortsætter crawlen processen ved at bruge linkene på espn.com og news.ycombinator.com for at fortsætte med at gennemgå.

Her er en rekursiv kode til at gøre det:

var request = kræve ('anmodning');

funktion crawlUrl (url) {
  request.get (url, funktion (fejl, svar, krop) {
    var linkUrls = getLinkUrls (body);

    linkUrls.forEach (funktion (linkUrl) {
      crawlUrl (linkurl);
    });
  });
}

crawlUrl (reddit.com ');

Hvad ville der ske, hvis svarorganet så sådan ud:

Der er ikke nogen tags, der skal følges. Denne webside ser også temmelig intetsigende ud, så vi sandsynligvis ikke ønsker at prioritere den, når vi viser søgeresultater.

Lite ved crawleren, Client Side Framework er ved at udfylde

med en masse awesome indhold.

Dette er grunden til gengivelse fra klientsiden kan være dårlig for SEO.

forhåndsgengivelse

I 2009 introducerede Google en måde at omgå dette.

Når webcrawleren støder på www.example.com/page?query#!mystate, konverterede den den til www.example.com/page?query&_escaped_fragment_=mystate. På denne måde, når din server får en anmodning med _escaped_fragment_, ved den, at anmodningen kommer fra en crawler, ikke et menneske.

Husk - serveren vil, at crawlen skal se

...

(med indholdet inde), ikke

. Så:

• Når anmodningen kommer fra en crawler, kunne vi tjene
  ...
  .
• Når anmodningen kommer fra et almindeligt menneske, kunne vi bare tjene
  og lade JavaScript indsætte indhold inde.

Der er dog et problem: serveren ved ikke, hvad der vil gå inden i

. For at finde ud af, hvad der er indeni, skulle det køre JavaScript, oprette en DOM og manipulere den DOM. Da traditionelle webservere ikke ved, hvordan man gør det, bruger de en service, der er kendt som en Headless Browser for at gøre det.

Smartere gennemsøgere

Seks år senere annoncerede Google, at dens gennemsøgning var på niveau! Når Crawler 2.0 ser