Візуалізацыя на баку кліента на серверы: чаму гэта не ўсё чорна-белае

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

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

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

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

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

Як працуе рэндэрынг на баку сервера

Рэндэрынг на баку сервера - найбольш распаўсюджаны спосаб адлюстравання інфармацыі на экране. Ён працуе шляхам пераўтварэння HTML-файлаў на серверы ў карысную інфармацыю для браўзэра.

Кожны раз, калі вы наведваеце вэб-сайт, ваш браўзэр звяртаецца з просьбай да сервера, які змяшчае змесціва сайта. Запыт звычайна займае ўсяго некалькі мілісекунд, але гэта ў канчатковым выніку залежыць ад мноства фактараў:

• Ваша хуткасць у Інтэрнэце
• месцазнаходжанне сервера
• Колькі карыстальнікаў спрабуюць атрымаць доступ да сайта
• і наколькі аптымізаваны сайт, каб назваць некалькі

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

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

Возьмем для прыкладу гэты HTML-дакумент, які быў змешчаны на ўяўным серверы з HTTP-адрасам example.testsite.com.

  <галава>
    
    
  
  
    
 Мой вэб-сайт 
    
 Гэта прыклад майго новага сайта 
     Спасылка 
  

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

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

  <галава>
    
    
  
  
    
 Мой вэб-сайт 
    
 Гэта прыклад майго новага сайта 
    
 Гэта яшчэ які-небудзь кантэнт з other.html 
  

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

Хоць гэта не можа здацца вялікай справай для гэтых двух прыкладаў, большасць сайтаў не так проста. Сучасныя сайты маюць сотні радкоў кода і значна складаней. Цяпер уявіце, як вы праглядаеце вэб-старонку, і вам трэба чакаць, калі кожная старонка будзе праглядацца падчас навігацыі па сайце. Калі вы калі-небудзь наведалі сайт WordPress, вы ўбачылі, як яны могуць быць павольнымі. Гэта адна з прычын таго.

З пункту гледжання, серверная рэндэрынг выдатна падыходзіць для SEO. Ваш змест прысутнічае, перш чым яго атрымаць, таму пошукавыя сістэмы могуць яго індэксаваць і проста прайсці. Тое, што не так у рэндэрынгу на баку кліента. Прынамсі, не проста.

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

Калі распрацоўшчыкі распавядаюць пра рэндэрынг на баку кліента, яны размаўляюць пра рэндэрынг змесціва ў браўзэры з дапамогай JavaScript. Такім чынам, замест таго, каб атрымліваць увесь змест у самім HTML-дакуменце, вы атрымліваеце HTML-дакумент з голымі костамі з файлам JavaScript, які будзе аказваць астатнюю частку сайта з дапамогай браўзэра.

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

Вяртаючыся да папярэдняга сайта, example.testsite.com, выкажам здагадку, што зараз у вас ёсць файл index.html з наступнымі радкамі кода.

<галава>
  
  


  

     
  
  
  

Вы можаце зразумець, што пры рэндэрынгу з дапамогай кліента ёсць некаторыя істотныя змены ў тым, як працуе index.hmtl.

Для пачатку, замест змесціва ўнутры HTML-файла, у вас ёсць дзіва кантэйнера з ідэнтыфікатарам кораня. У вас таксама ёсць два элемента сцэнарыя прама над тэгам закрыцця цела. Той, які будзе загружаць бібліятэку JavaScript Vue.js, і той, які будзе загружаць файл, які называецца app.js.

Гэта кардынальна адрозніваецца ад выкарыстання візуалізацыі на баку сервера, таму што сервер зараз адказны толькі за загрузку голага мінусу сайта. Асноўная кацялка. Усё астатняе апрацоўваецца бібліятэкай JavaScript на баку кліента, у гэтым выпадку Vue.js, і карыстацкім кодам JavaScript.

Калі вы хацелі зрабіць запыт у URL толькі з кодам вышэй, вы атрымаеце пусты экран. Нічога нельга загружаць, бо фактычны змест трэба адлюстроўваць з дапамогай JavaScript.

Каб выправіць гэта, вы павінны змясціць наступныя радкі кода ў файл app.js.

var data = {
        назва: "Мой сайт",
        паведамленне: "Гэта прыклад майго новага сайта"
      }
  Vue.component ("прыкладанне", {
    шаблон:
    `
    

    
 {{назва}} 
    
 {{message}} 
     Спасылка 
    
    `,
    дадзеныя: function () {
      вяртанне дадзеных;
    },
    метады: {
      newContent: function () {
        var node = document.createElement ('p');
        var textNode = document.createTextNode ('Гэта яшчэ які-небудзь кантэнт з other.html');
        node.appendChild (textNode);
        document.getElementById ('moreContent'). appendChild (вузел);
      }
    }
  })
  новы Vue ({
    el: '#root',
  });

Цяпер, калі вы наведаеце URL, вы ўбачыце той жа кантэнт, які вы зрабілі на прыкладзе сервера. Ключавое адрозненне заключаецца ў тым, што калі вы павінны націснуць на спасылку на старонку, каб загрузіць больш змесціва, браўзэр не зробіць чарговы запыт на сервер. Вы прадстаўляеце элементы з дапамогай браўзэра, і замест гэтага ён будзе выкарыстоўваць JavaScript для загрузкі новага змесціва, а Vue.js будзе пераканацца, што толькі новы кантэнт будзе прадстаўлены. Усё астатняе застанецца ў спакоі.

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

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

Варта памятаць і пра тое, што ваш вэб-сайт / дадатак не зможа загружацца, пакуль у аглядальнік не загрузіцца УСЕ JavaScript. Што мае сэнс, бо ён утрымлівае ўвесь змест, які спатрэбіцца. Калі вашы карыстальнікі выкарыстоўваюць павольнае падлучэнне да Інтэрнэту, гэта можа зрабіць свой пачатковы час загрузкі трохі доўгім.

Плюсы і мінусы кожнага падыходу

Дык там у вас ёсць. У гэтым асноўныя адрозненні паміж візуалізацыяй на баку сервера і кліента. Толькі вы, распрацоўнік, можаце вызначыць, які варыянт лепш для вашага сайта або прыкладання.

Ніжэй прыведзена кароткая разборка плюсаў і мінусаў для кожнага падыходу:

Плюсы сервера:

1. Пошукавыя сістэмы могуць сканаваць сайт для лепшага SEO.
2. Пачатковая загрузка старонкі адбываецца хутчэй.
3. Выдатна падыходзіць для статычных сайтаў.

Мінусы на серверы:

1. Частыя запыты сервера.
2. Агульная павольная вынос старонкі.
3. Поўная перазагрузка старонак.
4. Небагатае ўзаемадзеянне з сайтам.

Плюсы кліентаў:

1. Багатае ўзаемадзеянне з сайтам
2. Хуткая рэндэрынг сайта пасля першапачатковай загрузкі.
3. Выдатна падыходзіць для вэб-прыкладанняў.
4. Надзейны выбар бібліятэк JavaScript.

Мінусы на кліентах:

1. Нізкі SEO, калі ён не рэалізаваны правільна.
2. Пачатковая нагрузка можа запатрабаваць больш часу.
3. У большасці выпадкаў патрабуецца знешняя бібліятэка.

Калі вы хочаце даведацца больш пра Vue.js, паглядзіце VueReactor.com. Вы таксама можаце наведаць juanmvega.com, каб быць у курсе маіх апошніх гісторый.