Angular Universal în practică – Cum să construiți aplicații de o singură pagină prietenoase cu SEO cu Angular

În ultimele luni s-a vorbit mult despre Angular și despre cum să îl folosiți pentru a construi aplicații client, dar una dintre cele mai importante inovații ale sale se întâmplă de fapt pe server.

Este o tehnologie care ar putea ajuta la crearea unui nou tip de aplicații web: Angular Universal. Haideți să aflăm mai multe despre ea! Să trecem în revistă următoarele subiecte:

• Avantajele aplicațiilor cu o singură pagină
• De ce nu folosim aplicații cu o singură pagină peste tot atunci?
• Înțelegerea implicațiilor SEO ale unei aplicații cu o singură pagină
• Ce este Angular Universal, ce permite?
• Rendarea pe partea serverului nu este de fapt doar redarea pe server
• Un demo al unei aplicații de o singură pagină redată pe partea serverului în acțiune
• Pre-redare în momentul construirii – încărcați aplicațiile pre-redate pe Amazon S3
• Caracteristica ucigătoare a Angular Universal: Dependency Injection
• Concluzii

Acest articol este o introducere în Angular Universal. Pentru un ghid mai detaliat care acoperă modul de utilizare în practică, aruncați o privire la această postare:

Angular Universal: un ghid practic complet

Avantajele aplicațiilor cu o singură pagină

Aplicațiile cu o singură pagină există de ceva timp, iar framework-uri precum Angular, React sau Ember sunt probabil bibliotecile Javascript care primesc cea mai mare atenție în lumea Javascript.

Avantajele SPA-urilor sunt de fapt doar un singur lucru

Avantajele aplicațiilor cu o singură pagină sunt potențial multe:

• când utilizatorul navighează pe pagină, doar părți ale acesteia sunt înlocuite, ceea ce face ca experiența să fie mai fluidă
• după prima încărcare a paginii, doar datele trec pe fir atunci când utilizatorul navighează în aplicație: JSON este livrat către browser și aplicat șabloanelor HTML direct în browser
• acest lucru duce la o performanță mai bună și deschide posibilitatea ca acele servicii de backend să fie folosite pentru alte lucruri, deoarece ele doar returnează date

Potem rezuma acest lucru la un singur lucru:

Single Page Apps pot oferi o experiență de utilizare mult mai bună!

Și experiența de utilizare este critică în lumea internetului public. Există numeroase studii care dovedesc dincolo de orice îndoială că abandonul paginilor și abandonul utilizatorilor cresc foarte rapid odată cu întârzierea paginii.

Dacă o pagină are nevoie de 200 ms în plus pentru a se încărca, acest lucru va avea un potențial impact ridicat asupra afacerilor și vânzărilor (vezi această cercetare realizată de Google). Acest lucru este cu atât mai mult pe dispozitivele mobile, unde aplicațiile tind să fie mai lente.

De ce să nu folosim SPA-uri peste tot atunci?

După aceste statistici și faptul că SPA-urile oferă o experiență mult îmbunătățită pentru utilizator, de ce nu folosește toată lumea aplicații cu o singură pagină pentru orice?

Ele există de ani de zile și orice site web cu un sistem de navigare ar putea beneficia de a fi construit în acest fel.

Înțelegerea implicațiilor SEO ale unei aplicații cu o singură pagină

Există un motiv major pentru care aplicațiile cu o singură pagină nu sunt folosite peste tot până acum (cu două cauze separate):

Aplicațiile cu o singură pagină nu au performanțe bune pe motoarele de căutare

Cele două motive sunt:

Motorul de căutare trebuie să „ghicească” când pagina este completă

Când o singură pagină este recuperată, un motor de căutare va vedea doar foarte puțin HTML. Abia atunci când cadrul MVC intră în funcțiune, pagina va fi de fapt redată complet folosind datele obținute de pe server.

Problema este că motorul de căutare trebuie să ghicească atunci când cadrul Javascript termină de redat pagina, astfel încât există riscul de a indexa un conținut incomplet.

Cel de-al doilea motiv pentru care SPA-urile nu au performanțe bune cu motoarele de căutare este:

Legăturile profunde ale SPA-urilor sunt greu de indexat

Din cauza lipsei suportului HTML5 History în browsere, aplicațiile cu o singură pagină își bazau URL-urile de navigare în ancore de marcaj HTML (URL-uri cu #, precum /home#section1). Acestea nu sunt ușor de indexat ca pagini separate de către motoarele de căutare, există modalități de a face acest lucru, dar este o bătaie de cap și întotdeauna vor exista dificultăți în a obține o indexare corectă, spre deosebire de a folosi doar HTML simplu.

Concluzia ar putea fi că nu are niciun rost să ai cel mai ușor de navigat site dacă modul în care este construit te împiedică să ai un SEO bun.

Acum veștile bune

Veștile bune sunt că niciunul dintre aceste două motive nu mai este 100% corect! Google a început să indexeze mai bine aplicațiile de o singură pagină.

Și recenta depreciere a IE9 înseamnă că istoricul HTML5 este disponibil aproape peste tot, ceea ce face ca utilizarea URL-urilor de ancorare să nu mai fie necesară pentru SPA-uri, putem folosi doar URL-uri simple (cum ar fi /home/section1).

Este o veste bună, dar există și alte motoare de căutare care generează un trafic semnificativ. Baidu, de exemplu, conduce mai mult de jumătate din traficul din China (curr. 1,3 miliarde de oameni).

De asemenea, mai există încă problema performanței: o aplicație cu o singură pagină va fi mai lentă din cauza cantităților mari de Javascript de care are nevoie și a timpului mare de pornire și, prin urmare, va avea performanțe mai slabe decât o soluție bazată pe HTML.

Și acest lucru înseamnă căderi de pagină, această problemă nu va dispărea prea curând, în special pe mobil. Există vreo modalitate de a avea ce e mai bun din toate lumile și de a obține atât navigare instantanee, cât și prietenie SEO și performanță ridicată pe mobil?

Răspunsul este Da, cu Angular Universal.

Ce este Angular Universal, ce permite?

Simplu spus, Angular Universal ne permite să construim aplicații care au atât avantajele de performanță și de implicare a utilizatorilor ale aplicațiilor cu o singură pagină, combinate cu ușurința SEO a paginilor statice.

Rendarea pe partea serverului nu este de fapt doar redarea pe server

Angular Universal are mai multe alte caracteristici în afară de a oferi o soluție pentru redarea HTML pe server. Bazându-ne pe termenul „server-side rendering”, am putea crede că ceea ce face Angular Universal este similar, de exemplu, cu un limbaj de șabloane pe server precum Jade. Dar acesta are mult mai multe funcționalități.

Cu Angular Universal, obțineți acea sarcină utilă HTML inițială redată pe server, dar, de asemenea, porniți o versiune redusă de Angular pe client și de acolo Angular preia pagina ca o aplicație cu o singură pagină, generând de acolo tot HTML-ul pe client în loc de server.

Așa că rezultatul final pe care îl obțineți este același, este o aplicație de o singură pagină care rulează, dar acum, deoarece ați primit sarcina utilă HTML inițială de pe server, obțineți un timp de pornire mult mai bun și, de asemenea, o aplicație complet indexabilă SEO.

Pre-redare la momentul construirii – încărcați aplicațiile pre-redate pe Amazon S3

O altă posibilitate pe care Angular Universal o deschide este pre-redarea conținutului care nu se schimbă frecvent la momentul construirii. Acest lucru va fi posibil folosind fie pluginurile Grunt, Gulp sau Weppack. Iată cum va arăta o configurație Gulp, care preîntoarce conținutul aplicației noastre într-un fișier:

Și apoi pur și simplu încărcăm acest lucru într-un bucket Amazon S3 folosind CLI-ul Amazon:

Dacă legăm acest bucket la o distribuție Cloudfront CDN, avem un site web foarte accesibil și scalabil.

Ce se întâmplă dacă utilizatorul începe să interacționeze cu pagina imediat?

Există un decalaj inițial între momentul în care HTML-ul simplu este redat și prezentat utilizatorului și momentul în care Angular intră în acțiune pe partea de client și preia rolul de SPA.

În acest interval de timp, utilizatorul ar putea face clic pe ceva sau chiar începe să tasteze într-o casetă de căutare. Ceea ce permite Angular Universal prin funcționalitatea sa de preboot este să înregistreze evenimentele pe care le declanșează utilizatorul și să le redea odată ce Angular intră în funcțiune.

În acest fel, Angular va putea răspunde la aceste evenimente, ca de exemplu prin afișarea rezultatelor căutării într-o listă Typeahead.

Dar cum arată acest lucru pe server în termeni de cod?

Cum se redă HTML cu Angular în server

Modul în care conținutul este redat pe server este prin utilizarea motorului de redare Express Angular Universal expressEngine :

Există, de asemenea, un motor Hapi disponibil dacă preferați să utilizați Hapi în loc de Express. Există, de asemenea, motoare de randare pe server care urmează să apară pentru tot felul de platforme: C#, Java, PHP, vedeți această postare anterioară pentru mai multe detalii.

Cum să începi cu Angular Universal?

Cel mai bun loc pentru a începe este starterul oficial universal-starter, cu starterul obținem o aplicație care rulează și care include un server Express cu randare pe partea serverului care funcționează din start.

Ceea ce este inovator la Angular Universal este simplitatea utilizării sale. Una dintre principalele caracteristici de design ale Angular Universal este modul în care utilizează injecția de dependență.

Dezvoltarea de randare pe partea serverului nu este ca și cum ai codifica doar pentru client

De cele mai multe ori dorim ca aplicația noastră să facă exact același lucru pe server ca și pe client, prin faptul că nu depinde direct de API-urile browserului.

Realitatea dezvoltării de randare pe server este că acest lucru nu este întotdeauna posibil și există anumite lucruri pe care dorim să le facem diferit pe client și pe server.

Să luăm ca exemplu randarea unei diagrame: probabil că doriți să apelați o bibliotecă terță parte care utilizează SVG. Nu o putem apela pe server, deci cum o redăm?

Un alt exemplu, cum putem reda paginile autentificate? Pentru că conținutul depinde de cine este conectat în acel moment.

Utilizarea injecției de dependență pentru a implementa autentificarea

Pentru a gestiona autentificarea, acesta este un mod de a face acest lucru:

• Pe client dorim ca identitatea utilizatorului să fie preluată dintr-un token disponibil fie pe un cookie, fie în memoria locală a browserului.

• pe server, în timpul redactării cererii, dorim ca tokenul de identitate să fie citit dintr-un antet de cerere HTTP.

Cum să avem aceeași ieșire a paginii în timp ce navigăm către acea pagină pe client prin intermediul unei tranziții a routerului față de cea de pe server prin intermediul unei reîmprospătări a browserului?

În primul rând, definiți o interfață de serviciu

Primul pas este de a defini o interfață pe care serviciul dvs. o va furniza, care este independentă de timpul de execuție:

Apoi furnizăm două implementări pentru această interfață, una pentru client și cealaltă pentru server. De exemplu, pe server nu există nicio ocazie pentru ca metoda de autentificare să fie apelată, așa că aruncăm o eroare:

În timp ce pe client, vom declanșa ecranul de blocare Auth0 (o bibliotecă terță parte numai pentru browser) pentru a oferi un formular de autentificare:

Apoi vom injecta diferite implementări ale interfeței pe server și pe client, pentru același token de injecție:

Și iată cum putem face ceva diferit pe client și pe server în Angular Universal, prin utilizarea containerului de injecție a dependențelor Angular.

De fapt, Angular Universal este construit, de asemenea, folosind această noțiune: de exemplu, modul în care este redat HTML este prin faptul că, în loc de a injecta un renderizator DOM în timpul bootstrapării cadrului, se injectează un renderizator de server care generează HTML folosind biblioteca de serializare HTML parse5.

Concluzii

Ca orice tehnologie, avantajele renderizării pe partea de server vor evolua în timp. Dar, în momentul de față, redarea pe server prezintă un mare avantaj pentru construirea de aplicații mobile, prietenoase cu motoarele de căutare, care au un grad ridicat de implicare a utilizatorilor datorită navigării instantanee fără probleme.

Este mai ușor ca niciodată astăzi să construim aceste tipuri de aplicații folosind Angular Universal și starterul universal.

Cu Angular Universal, utilizarea injecției de dependență face foarte simplu să facem ceva ușor diferit pe server față de client, dacă avem nevoie.

Getting Started With Angular

Dacă doriți să învățați mai multe despre Angular, aruncați o privire la cursul Angular for Beginners:

Alte postări despre Angular

Dacă v-a plăcut această postare, iată și alte postări populare pe blogul nostru:

• Angular Router – Cum se construiește un meniu de navigare cu Bootstrap 4 și rute imbricate
• Angular Router – Tur ghidat extins, Evitați capcanele comune
• Angular Components – The Fundamentals
• Cum să rulați Angular în producție astăzi
• Cum să construiți aplicații Angular folosind Observable Data Services – Capcanele de evitat
• Introduction to Angular Forms – Template Driven, Model Driven or In-Between
• Angular ngFor – Învățați toate caracteristicile, inclusiv trackBy, de ce nu este doar pentru Array-uri ?
• Angular Universal în practică – Cum să construiți aplicații de pagină unică prietenoase cu SEO cu Angular
• Cum funcționează cu adevărat Angular Change Detection?

.