Візуалізацыя на баку кліента супраць візуалізацыі на баку сервера

Першапачаткова ў вэб-рамках былі прадстаўлены прагляды на серверы. Зараз гэта адбываецца з кліентам. Давайце вывучым перавагі і недахопы кожнага падыходу.

Прадукцыйнасць

Пры рэндэрынгу на баку сервера, калі вы хочаце паглядзець новую вэб-старонку, вам трэба выйсці і атрымаць яе:

Схема таго, як працуе рэндэрынг на баку сервера

Гэта аналаг вам, калі вы едзеце на суперрынак кожны раз, калі захочаце есці.

З рэндэрынгам на баку кліента вы ідзяце на супермаркет адзін раз і праводзіце 45 хвілін, гуляючы, купляючы кучу прадуктаў на месяц. Затым, калі хочаш есці, ты проста адкрываеш халадзільнік.

Схема таго, як працуе візуалізацыя на баку кліента

Кожны падыход мае свае перавагі і недахопы, калі гаворка ідзе пра прадукцыйнасць:

  • Пры адлюстраванні на баку кліента пачатковая загрузка старонкі будзе павольнай. Паколькі сувязь па сетцы ідзе павольна, і для гэтага патрабуецца два туры на сервер, перш чым вы зможаце паказваць карыстачу кантэнт. Аднак пасля гэтага кожнае наступнае загружанне старонак будзе вельмі хутка.
  • Пры рэндэрынгу на баку сервера пачатковая загрузка старонкі будзе не вельмі павольнай. Але гэта не будзе хутка. І ні адзін з вашых іншых просьбаў.

Калі быць больш канкрэтным, пры адлюстраванні на баку кліента пачатковая старонка будзе выглядаць прыблізна так:


  <галава>
    
    
  
  
    
  

app.js будзе мець усе старонкі HTML у JavaScript як радкі. Нешта накшталт гэтага:

var Старонкі = {
  '/': ' ... ',
  '/ foo': ' ... ',
  '/ bar': ' ... ',
};

Затым, калі старонка загружаецца, фреймворк паглядзіць на радок URL, атрымае радок на старонках ['/'] і ўставіць яе ў

. Акрамя таго, пры націску на спасылкі, структура перахоплівае падзею, устаўляе новую радок (скажам, старонкі ['/ foo']) у кантэйнер і не дазваляе браўзэру адчыняць запыт HTTP, як звычайна.

SEO

Дапусцім, наш вэб-сканер пачынае рабіць запыт на reddit.com:

var request = патрабаваць ('запыт');
request.get ('reddit.com', функцыя (памылка, адказ, цела) {
  // Цела выглядае прыблізна так:
  // 
  //  ... 
  // 
  //  ESPN 
  //  Навіны хакера 
  // ... іншыя  тэгі ...
});

Затым сканер выкарыстоўвае рэчы у целе адказу для стварэння новых запытаў:

var request = патрабаваць ('запыт');
request.get ('reddit.com', функцыя (памылка, адказ, цела) {
  // Цела выглядае прыблізна так:
  // 
  //  ... 
  // 
  //  ESPN 
  //  Навіны хакера 
  // ... іншыя  тэгі ...
  request.get ('espn.com', function () {...});
  request.get ('news.ycombinator.com', function () {...});
});

Пасля гэтага сканер працягвае працэс, выкарыстоўваючы спасылкі на espn.com і news.ycombinator.com, каб працягнуць сканіраванне.

Вось рэкурсіўны код для гэтага:

var request = патрабаваць ('запыт');
функцыя crawlUrl (url) {
  request.get (URL, функцыя (памылка, адказ, цела) {
    var linkUrls = getLinkUrls (цела);
    linkUrls.forEach (функцыя (linkUrl) {
      поўзацьUrl (linkUrl);
    });
  });
}
crawlUrl ('reddit.com');

Што было б, калі б орган рэагавання выглядаў так:


  <галава>
    
    
  
  
    
  

Ну, не існуе ніякіх тэгаў . Акрамя таго, гэтая вэб-старонка выглядае даволі мякка, таму мы, напэўна, не захочам надаваць ёй чарговы раз, калі паказваем вынікі пошуку.

Мала што сканер ведае, Client Side Framework вось-вось запоўніць

кучай дзіўнага зместу.

Вось чаму рэндэрынг на баку кліента можа быць дрэнным для SEO.

Прадстаўленне

У 2009 годзе Google прадставіў спосаб абыйсці гэта.

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

Калі сканер націсне на www.example.com/page?query#!mystate, ён пераўтварыць яго ў www.example.com/page?query&_escaped_fragment_=mystate. Такім чынам, калі ваш сервер атрымлівае запыт з _escaped_fragment_, ён ведае, што запыт прыходзіць ад гусенічнага, а не чалавека.

Памятаеце - сервер хоча, каб сканер бачыў

...
(са зместам ўнутры), а не
. Так што:

  • Калі запыт паходзіць ад гусенічнага праграма, мы можам служыць
    ...
    .
  • Калі запыт прыходзіць ад звычайнага чалавека, мы можам проста служыць
    і дазволіць JavaScript устаўляць змесціва ўнутры.

Але ёсць праблема: сервер не ведае, што будзе ісці ў

. Каб высветліць, што адбываецца ўнутры, трэба запусціць JavaScript, стварыць DOM і кіраваць гэтым DOM. Паколькі традыцыйныя вэб-серверы не ведаюць, як гэта зрабіць, яны карыстаюцца службай, вядомай як "Браўзэр без галавы".

Разумнейшыя гусеніцы

Праз шэсць гадоў Google абвясціў, што яго гусенічны падраўняўся! Калі Crawler 2.0 бачыць тэгі