Partea client vs. partea server vs. pre-rendare pentru aplicații web

Se întâmplă ceva recent în comunitatea front-end. Redarea pe partea serverului capătă din ce în ce mai multă tracțiune datorită React și caracteristicii sale de hidratare încorporate pe partea serverului. Dar nu este singura soluție pentru a oferi utilizatorului o experiență rapidă cu un scor TTFB (time-to-first-byte) super rapid: pre-rendarea este, de asemenea, o strategie destul de bună. Care este diferența dintre aceste soluții și o aplicație realizată integral de client?

Aplicație oferită de client

Deoarece există cadre precum Angular, Ember.js și Backbone, dezvoltatorii front-end au avut tendința de a reda totul pe partea clientului. Datorită Google și abilității sale de a „citi” JavaScript, funcționează destul de bine și este chiar prietenos cu SEO.

Cu o soluție de randare pe partea clientului, redirecționați cererea către un singur fișier HTML, iar serverul o va livra fără niciun conținut (sau cu un ecran de încărcare) până când preluați tot JavaScript și lăsați browserul să compileze totul înainte de a randa conținutul.

Cu o conexiune la internet bună și fiabilă, este destul de rapid și funcționează bine. Dar poate fi mult mai bine și nu trebuie să fie dificil să o faci așa. Asta vom vedea în secțiunile următoare.

Redare pe partea serverului (SSR)

O soluție SSR este ceva ce obișnuiam să facem foarte mult, cu mulți ani în urmă, dar tindem să uităm în favoarea unei soluții de randare pe partea clientului.

Cu soluții vechi de randare pe partea de server, ați construit o pagină web – cu PHP, de exemplu – serverul a compilat totul, a inclus datele și a livrat clientului o pagină HTML complet populată. A fost rapid și eficient.

Dar... de fiecare dată când navigați către o altă rută, serverul trebuia să facă treaba din nou: obțineți fișierul PHP, compilați-l și livrați HTML, cu toate CSS și JS întârzierea încărcării paginii la câteva sute de ms sau chiar și secunde întregi.

Ce se întâmplă dacă ai putea face prima încărcare a paginii cu soluția SSR și apoi ai folosi un cadru pentru a face rutare dinamică cu AJAX, preluând doar datele necesare?

Acesta este motivul pentru care SSR capătă din ce în ce mai multă tracțiune în cadrul comunității, deoarece React a popularizat această problemă cu o soluție ușor de utilizat: metoda RenderToString .

Acest nou tip de aplicație web se numește aplicație universală sau aplicație izomorfă . Există încă unele controverse cu privire la semnificațiile exacte ale acestor termeni și relația dintre ei, dar mulți oameni îi folosesc interschimbabil.

Oricum, avantajul acestei soluții este de a putea dezvolta o aplicație pe partea de server și pe partea clientului cu același cod și de a oferi utilizatorului o experiență foarte rapidă cu date personalizate. Dezavantajul este că trebuie să rulați un server.

SSR este folosit pentru a prelua date și a pre-popula o pagină cu conținut personalizat, valorificând conexiunea fiabilă la internet a serverului. Adică, conexiunea la internet a serverului este mai bună decât cea a unui utilizator cu lie-fi), astfel încât este capabil să preleveze și să amalgameze datele înainte de a le livra utilizatorului.

Cu datele pre-populate, utilizarea unei aplicații SSR poate rezolva, de asemenea, o problemă pe care o au aplicațiile redate de client cu partajarea socială și sistemul OpenGraph. De exemplu, dacă aveți un singur fișier index.html de livrat clientului, acesta va avea un singur tip de metadate, cel mai probabil metadatele paginii dvs. de pornire. Acest lucru nu va fi contextualizat atunci când doriți să partajați un traseu diferit, astfel încât niciunul dintre traseele dvs. nu va fi afișat pe alte site-uri cu conținutul propriu de utilizator (descriere și imagine de previzualizare) pe care utilizatorii ar dori să îl partajeze lumii.

Pre-randare

Serverul obligatoriu pentru o aplicație universală poate fi un factor de descurajare pentru unii și poate fi exagerat pentru o aplicație mică. Acesta este motivul pentru care pre-rendarea poate fi o alternativă foarte bună.

Am descoperit această soluție cu Preact și propriul CLI care vă permite să compilați toate rutele preselectate, astfel încât să puteți stoca un fișier HTML complet populat pe un server static . Acest lucru vă permite să oferiți utilizatorului o experiență super-rapidă, datorită funcției de hidratare Preact/React, fără a fi nevoie de Node.js.

Problema este că, deoarece acesta nu este SSR, nu aveți date specifice utilizatorului de afișat în acest moment - este doar un fișier static (și oarecum generic) trimis direct la prima solicitare, așa cum este. Deci, dacă aveți date specifice utilizatorului, aici puteți integra un schelet frumos proiectat pentru a arăta utilizatorului că vin datele lor, pentru a evita unele frustrari din partea lor:

Există o altă captură: pentru ca această tehnică să funcționeze, mai trebuie să aveți un proxy sau ceva pentru a redirecționa utilizatorul către fișierul potrivit.

De ce?

Cu o aplicație cu o singură pagină, trebuie să redirecționați toate solicitările către fișierul rădăcină, iar apoi cadrul redirecționează utilizatorul cu sistemul său de rutare încorporat. Deci prima pagină de încărcare este întotdeauna același fișier rădăcină.

Pentru ca o soluție de pre-rendare să funcționeze, trebuie să spuneți proxy-ului că unele rute au nevoie de fișiere specifice și nu întotdeauna fișierul rădăcină index.html .

De exemplu, să presupunem că aveți patru rute ( / , /about , /jobs și blog ) și toate au aspecte diferite. Aveți nevoie de patru fișiere HTML diferite pentru a livra scheletul utilizatorului, care va lăsa apoi React/Preact/etc. rehidratează-l cu date. Deci, dacă redirecționați toate acele rute către fișierul rădăcină index.html , pagina va avea o senzație neplăcută, glitching în timpul încărcării, prin care utilizatorul va vedea scheletul paginii greșite până când se termină de încărcat și înlocuiește aspectul. De exemplu, utilizatorul ar putea vedea un schelet de pagină de pornire cu o singură coloană, atunci când a cerut o altă pagină cu o galerie asemănătoare Pinterest.

Soluția este să spuneți proxy-ului că fiecare dintre aceste patru rute are nevoie de un fișier specific:

• https://my-website.com → Redirecționați către fișierul rădăcină index.html
• https://my-website.com/about → Redirecționați către fișierul /about/index.html
• https://my-website.com/jobs → Redirecționați către fișierul /jobs/index.html
• https://my-website.com/blog → Redirecționați către fișierul /blog/index.html

Acesta este motivul pentru care această soluție poate fi utilă pentru aplicații mici - puteți vedea cât de dureros ar fi dacă ați avea câteva sute de pagini.

Strict vorbind, nu este obligatoriu să o faci în acest fel - poți doar să folosești direct un fișier static. De exemplu, https://my-website.com/about/ va funcționa fără nicio redirecționare, deoarece va căuta automat un index.html în directorul său. Dar aveți nevoie de acest proxy dacă aveți URL-uri de parametri: https://my-website.com/profile/guillaume va trebui să redirecționeze solicitarea către /profile/index.html cu propriul aspect, deoarece profile/guillaume/index.html nu există și va declanșa o eroare 404.

Pe scurt, există trei vederi de bază în joc cu strategiile de randare descrise mai sus: un ecran de încărcare, un schelet și întreaga pagină odată ce este în sfârșit redată.

În funcție de strategie, uneori folosim toate aceste trei vizualizări, iar uneori sărim direct la o pagină complet randată. Doar într-un singur caz de utilizare suntem forțați să folosim o abordare diferită:

Redarea numai pentru client este adesea insuficientă

Aplicațiile oferite de client sunt ceva ce ar trebui să evităm acum, deoarece putem face mai bine pentru utilizator. Și a face mai bine, în acest caz, este la fel de ușor ca soluția de pre-rendare. Este cu siguranță o îmbunătățire față de randarea doar pentru client și mai ușor de implementat decât o aplicație redată complet pe partea de server.

O aplicație SSR/universală poate fi cu adevărat puternică dacă aveți o aplicație mare, cu multe pagini diferite. Permite conținutului dvs. să fie concentrat și relevant atunci când vorbiți cu un crawler social. Acest lucru este valabil și pentru roboții motoarelor de căutare, care acum țin cont de performanța site-ului dvs. atunci când îl clasifică.

Rămâneți la curent pentru un tutorial de continuare, în care voi trece prin transformarea unui SPA în versiuni pre-rendate și SSR și voi compara performanța acestora.