Angular Universal a gyakorlatban – Hogyan építsünk SEO-barát egyoldalas alkalmazásokat Angularral

Az elmúlt hónapokban sok szó esett az Angularról és arról, hogyan használjuk kliensalkalmazások építéséhez, de az egyik legfontosabb újítás valójában a szerveren történik.

Ez a technológia egy teljesen új típusú webes alkalmazásokat tesz lehetővé: Angular Universal. Tudjunk meg róla többet! Vegyük át a következő témákat:

• A single page alkalmazások előnyei
• Miért nem használunk akkor mindenhol single page alkalmazásokat?
• A single page alkalmazások SEO vonatkozásainak megértése
• Mi az Angular Universal, mit tesz lehetővé?
• A szerveroldali renderelés valójában nem csak a szerveren történő renderelés
• Egy demo egy szerveroldalon renderelt egyoldalas alkalmazásról működés közben
• Előre renderelés építéskor – előre renderelt alkalmazások feltöltése az Amazon S3-ra
• Az Angular Universal gyilkos funkciója: Dependency Injection
• Következtetések

Ez a bejegyzés az Angular Universal bevezetése. Egy részletesebb útmutatót, amely a gyakorlati használatról szól, ebben a bejegyzésben találsz:

Angular Universal: A Complete Practical Guide

Advantages of Single Page Applications

Az egyoldalas alkalmazások már egy ideje léteznek, és az olyan keretrendszerek, mint az Angular, a React vagy az Ember valószínűleg azok a Javascript könyvtárak, amelyek a legnagyobb figyelmet kapják a Javascript világában.

Az SPA-k előnyei valójában csak egy dolog

Az egyoldalas alkalmazások előnyei potenciálisan számosak:

• mikor a felhasználó navigál az oldalon, annak csak egyes részei cserélődnek le, ami gördülékenyebb élményt biztosít
• az oldal első betöltése után csak adatok mennek át a vezetéken, amikor a felhasználó az alkalmazásban navigál: A JSON a böngészőhöz kerül, és a HTML-sablonokra közvetlenül a böngészőhöz alkalmazzák
• ez jobb teljesítményt eredményez, és megnyitja a lehetőséget arra, hogy ezeket a backend-szolgáltatásokat másra is használjuk, mivel csak adatokat adnak vissza

Egyetlen dologra egyszerűsíthetjük le:

Az egyoldalas alkalmazások sokkal jobb felhasználói élményt nyújthatnak!

A felhasználói élmény pedig kritikus fontosságú a nyilvános internet világában. Számos tanulmány bizonyítja minden kétséget kizáróan, hogy az oldalletöltés és a felhasználó elhagyása nagyon gyorsan növekszik az oldal késésével.

Ha egy oldal betöltése 200ms-mal tovább tart, az potenciálisan nagy hatással lehet az üzletre és az értékesítésre (lásd ezt a Google által végzett kutatást). Ez még inkább igaz a mobileszközökön, ahol az alkalmazások általában lassabbak.

Miért nem használjuk akkor mindenhol az SPA-kat?

Ezek a statisztikák és az a tény, hogy az SPA-k sokkal jobb felhasználói élményt nyújtanak, miért nem használ mindenki egyoldalas alkalmazásokat mindenre?

Ezek már évek óta léteznek, és minden navigációs rendszerrel rendelkező weboldal számára előnyös lehet, ha így épülnek fel.

A single page app SEO-következményeinek megértése

Egy fő oka van annak, hogy az egyoldalas alkalmazásokat eddig nem mindenhol használták (két külön okkal):

Az egyoldalas alkalmazások nem teljesítenek jól a keresőmotorokban

A két ok a következő:

A keresőmotornak “ki kell találnia”, hogy mikor teljes az oldal

Az egyoldalas applikáció előhívásakor a keresőmotor csak nagyon kevés HTML-t lát. Csak amikor az MVC-keretrendszer működésbe lép, az oldal ténylegesen teljesen megjelenik a kiszolgálótól kapott adatok felhasználásával.

A probléma az, hogy a keresőmotornak ki kell találnia, hogy a Javascript-keretrendszer mikor fejezi be az oldal megjelenítését, így fennáll a hiányos tartalom indexelésének kockázata.

A második ok, amiért az SPA-k nem teljesítenek jól a keresőmotoroknál, a következő:

SPA mély linkeket nehéz indexelni

A böngészők HTML5 History támogatásának hiánya miatt az egyoldalas alkalmazások a navigációs URL-eket HTML könyvjelző horgonyokban (URL-ek #-vel, például /home#section1) alapozták meg. Ezeket a keresőmotorok nem könnyen indexelik különálló oldalakként, van rá mód, de ez fájdalmas, és mindig nehézségekbe fog ütközni, hogy ezt jól indexeljék, szemben a sima HTML használatával.

A következtetés az lehet, hogy nincs értelme a legkönnyebben navigálható webhelynek, ha a felépítés módja megakadályozza a jó SEO-t.

Most a jó hír

A jó hír az, hogy e két ok közül egyik sem 100%-ig pontos már! A Google elkezdte jobban indexelni az egyoldalas alkalmazásokat.

Az IE9 közelmúltbeli elavulása pedig azt jelenti, hogy a HTML5 History szinte mindenhol elérhető, így az SPA-k esetében már nincs szükség a horgony URL-ek használatára, használhatunk egyszerű URL-eket (mint /home/section1).

Ez jó hír, de vannak más keresőmotorok is, amelyek jelentős forgalmat bonyolítanak. A Baidu például a kínai forgalom több mint felét bonyolítja le (jelenleg 1,3 milliárd ember).

Még mindig ott van a teljesítmény kérdése: egy egyoldalas alkalmazás lassabb lesz a szükséges nagy mennyiségű Javascript és a nagy indítási idő miatt, ezért rosszabbul fog teljesíteni, mint egy HTML alapú megoldás.

És ez az oldal kiesését jelenti, ez a probléma nem fog egyhamar megszűnni, különösen mobilon. Van rá mód, hogy minden világból a legjobbat kapjuk, és egyszerre legyen azonnali navigáció, SEO-barátság és nagy teljesítmény mobilon?

A válasz igen, az Angular Universal segítségével.

Mi az Angular Universal, mit tesz lehetővé?

Egyszerűen fogalmazva, az Angular Universal lehetővé teszi, hogy olyan alkalmazásokat készítsünk, amelyek az egyoldalas alkalmazások teljesítményének és felhasználói elkötelezettségének előnyeit a statikus oldalak SEO-barátságával kombinálják.

A szerveroldali renderelés valójában nem csak a szerveren történő renderelést jelenti

Az Angular Universal számos más funkcióval is rendelkezik azon kívül, hogy megoldást ad a HTML szerveren történő renderelésére. A “szerveroldali renderelés” kifejezés alapján azt gondolhatnánk, hogy amit az Angular Universal csinál, az hasonló például egy olyan szerveroldali sablonnyelvhez, mint a Jade. De ennél sokkal több funkcionalitással rendelkezik.

Az Angular Universal segítségével megkapjuk a szerveren renderelt kezdeti HTML payloadot, de a kliensen is elindítjuk az Angular egy lecsupaszított verzióját, és onnan az Angular egyoldalas alkalmazásként veszi át az oldalt, onnan generálva az összes HTML-t a kliensen, nem pedig a szerveren.

A végeredmény tehát ugyanaz, egy futó egyoldalas alkalmazás, de most mivel a kezdeti HTML payloadot a szerverről kapta, sokkal jobb indítási időt és egy teljesen SEO indexelhető alkalmazást is kap.

Előrendering építéskor – előre renderelt alkalmazások feltöltése az Amazon S3-ra

Egy másik lehetőség, amit az Angular Universal megnyit, a nem gyakran változó tartalmak előzetes renderelése építéskor. Erre a Grunt, Gulp vagy Weppack pluginok segítségével lesz lehetőség. Így fog kinézni egy Gulp konfiguráció, amely előrendezi az alkalmazásunk tartalmát egy fájlba:

Aztán ezt egyszerűen feltöltjük egy Amazon S3 vödörbe az Amazon CLI segítségével:

Ha ezt a vödröt összekötjük egy Cloudfront CDN disztribúcióval, akkor egy nagyon megfizethető és skálázható weboldalunk lesz.

Mi van, ha a felhasználó azonnal elkezd interakcióba lépni az oldallal?

Van egy kezdeti késleltetés aközött a pillanat között, amikor a sima HTML megjelenik és megjelenik a felhasználónak, és a pillanat között, amikor az Angular kliensoldalon beindul és átveszi az SPA szerepét.

Ebben az időkeretben a felhasználó esetleg rákattint valamire, vagy akár elkezd gépelni egy keresőmezőbe. Amit az Angular Universal a preboot funkcionalitásán keresztül lehetővé tesz, az az, hogy rögzítse a felhasználó által kiváltott eseményeket, és lejátssza azokat, amint az Angular elindul.

Így az Angular képes lesz reagálni ezekre az eseményekre, például a keresési eredmények megjelenítésével egy Typeahead listán.

De hogyan néz ez ki a szerveren a kód szempontjából?

Hogyan lehet a HTML-t renderelni Angularral a szerveren

A tartalom renderelésének módja a szerveren az Express Angular Universal renderelő motor expressEngine használatával történik:

Egy Hapi motor is elérhető, ha az Express helyett inkább a Hapi-t szeretné használni. Mindenféle platformra készülnek szerver renderelő motorok is: C#, Java, PHP, további részletekért lásd ezt a korábbi bejegyzést.

Hogyan kezdjünk hozzá az Angular Universalhoz?

A legjobb hely a kezdéshez a hivatalos starter universal-starter, a starterrel egy futó alkalmazást kapunk, amely tartalmaz egy express szervert, a szerveroldali rendereléssel, amely azonnal működik.

Az Angular Universal újszerűsége az egyszerű használatban rejlik. Az Angular Universal egyik fő tervezési jellemzője az, hogy függőségi injektálást használ.

A szerveroldali renderelés fejlesztése nem olyan, mintha csak a kliensre kódolnánk

A legtöbbször azt szeretnénk, ha az alkalmazásunk pontosan ugyanazt tenné a szerveren, mint a kliensen, nem függve közvetlenül a böngésző API-itól.

A szerveroldali renderelésfejlesztés valósága az, hogy ez nem mindig lehetséges, és vannak bizonyos dolgok, amelyeket másképp szeretnénk csinálni a kliensen és a szerveren.

Vegyük például egy diagram renderelését: valószínűleg egy harmadik féltől származó, SVG-t használó könyvtárat szeretnénk meghívni. A szerveren nem tudjuk meghívni, tehát hogyan rendereljük?

Egy másik példa: hogyan tudjuk a hitelesített oldalakat renderelni? Mert a tartalom attól függ, hogy ki van éppen bejelentkezve.

A függőségi injektálás használata a hitelesítés megvalósításához

A hitelesítés kezelésére ez az egyik lehetőség:

• A kliensen azt akarjuk, hogy a felhasználó identitását egy tokenből vegyük, ami vagy egy cookie-ban vagy a böngésző helyi tárolójában elérhető.

• A kiszolgálón a kérés megjelenítésekor azt szeretnénk, hogy az identitás tokent egy HTTP kérés fejlécből olvassuk ki.

Hogyan kapjuk meg ugyanazt az oldalkimenetet, miközben az adott oldalra navigálunk a kliensen egy útválasztó átmenettel vs. a szerveren a böngésző frissítésével?

Először definiáljunk egy szolgáltatás interfészt

Az első lépés egy interfész definiálása, amelyet a szolgáltatásunk nyújtani fog, és amely független a futási időtől:

Ezután két implementációt biztosítunk ehhez az interfészhez, egyet a klienshez, egyet pedig a szerverhez. A szerveren például nincs alkalom a bejelentkezési metódus meghívására, ezért hibát dobunk:

Míg a kliensen az Auth0 lock screen-t (egy harmadik féltől származó, csak a böngészőre vonatkozó könyvtár) fogjuk kiváltani, hogy egy bejelentkezési űrlapot biztosítson:

Az interfész különböző implementációit injektáljuk ezután a szerveren és a kliensen, ugyanarra az injektálási tokenre:

És így tudunk valami mást csinálni a kliensen és a szerveren az Angular Universalban, kihasználva az Angular függőségi injektálási konténerét.

Tény, hogy az Angular Universal is ezt a felfogást használja: például a HTML renderelésének módja az, hogy ahelyett, hogy a keretrendszer bootstrappingje során egy DOM renderelőt injektálna, egy szerver renderelőt injektál, amely a HTML-t a parse5 HTML szerializációs könyvtár segítségével generálja.

Következtetések

Mint minden technológia, a szerveroldali renderelés előnyei idővel fejlődni fognak. De jelenleg a szerveroldali renderelés nagy előnyt jelent mobilbarát, keresőmotorbarát alkalmazások építésében, amelyek a zökkenőmentes, azonnali navigációnak köszönhetően magas felhasználói elkötelezettséggel rendelkeznek.

Az Angular Universal és az univerzális indító használatával ma könnyebb, mint valaha, ilyen típusú alkalmazásokat építeni.

Az Angular Universal esetében a függőségi injektálás használata nagyon egyszerűvé teszi, hogy szükség esetén a szerveren kicsit mást csináljunk, mint a kliensen.

Az Angularral való kezdés

Ha többet szeretnél megtudni az Angularról, nézd meg az Angular kezdőknek tanfolyamot:

Más bejegyzések az Angularról

Ha tetszett ez a bejegyzés, íme néhány más népszerű bejegyzés a blogunkon:

• Angular Router – Hogyan építsünk navigációs menüt Bootstrap 4 és beágyazott útvonalak segítségével
• Angular Router – bővített útmutató, A gyakori buktatók elkerülése
• Angular Components – Az alapok
• How to run Angular in Production Today
• How to build Angular apps using Observable Data Services – Pitfalls to avoid
• Introduction to Angular Forms – Template Driven, Modellvezérelt vagy a kettő között
• Angular ngFor – Ismerje meg az összes funkciót, beleértve a trackBy-t, miért nem csak a tömbökhöz ?
• Angular Universal a gyakorlatban – Hogyan építsünk SEO-barát egyoldalas alkalmazásokat Angularral
• Hogyan működik valójában az Angular Change Detection?