Angular Universal käytännössä – Kuinka rakentaa SEO-ystävällisiä yksisivuisia sovelluksia Angularilla

Viime kuukausina on puhuttu paljon Angularista ja siitä, kuinka sitä voi käyttää asiakassovellusten rakentamiseen, mutta yksi sen tärkeimmistä innovaatioista tapahtuu itse asiassa palvelimella.

Tämä teknologia voi auttaa mahdollistamaan kokonaan uudenlaiset verkkosovellukset: Angular Universal. Tutustutaanpa siihen tarkemmin! Käydään läpi seuraavat aiheet:

  • Yksisivuisten sovellusten edut
  • Miksi emme sitten käytä yksisivuisia sovelluksia kaikkialla?
  • Yksisivuisen sovelluksen SEO-vaikutusten ymmärtäminen
  • Mikä on Angular Universal, mitä se mahdollistaa?
  • Palvelinpuolen renderöinti ei todellakaan ole pelkkää renderöintiä palvelimella
  • Demo palvelinpuolella renderöidystä yksisivuisesta sovelluksesta toiminnassa
  • Pre-renderöinti rakennusaikana – lataa valmiiksi renderöityjä sovelluksia Amazon S3:een
  • Tappava ominaisuus Angular Universalissa: Dependency Injection
  • Conclusions

Tämä postaus on johdatus Angular Universaliin. Jos haluat yksityiskohtaisemman oppaan, joka kattaa sen käytön käytännössä, katso tämä postaus:

Angular Universal: Täydellinen käytännön opas

Yksisivuisten sovellusten edut

Yksisivuiset sovellukset ovat olleet olemassa jo jonkin aikaa, ja Angularin, Reactin tai Emberin kaltaiset kehykset ovat luultavasti Javascript-kirjastoja, jotka saavat eniten huomiota Javascript-maailmassa.

Yksisivuisten sovellusten edut ovat oikeastaan vain yksi asia

Yksisivuisten sovellusten etuja on potentiaalisesti monia:

  • Kun käyttäjä navigoi sivulla, vain osia siitä vaihdetaan, mikä tekee käyttökokemuksesta sujuvamman
  • Sivun ensimmäisen latauksen jälkeen vain dataa kulkee langan yli, kun käyttäjä navigoi sovelluksessa: JSON toimitetaan selaimelle ja sitä sovelletaan HTML-malleihin suoraan selaimessa
  • Tämä johtaa parempaan suorituskykyyn ja avaa mahdollisuuden käyttää noita backend-palveluja muuhun, koska ne vain palauttavat dataa

Voidaan kiteyttää tämä vain yhteen asiaan:

Yksisivuiset sovellukset voivat tarjota paljon paremman käyttäjäkokemuksen!

Ja käyttäjäkokemus on kriittinen julkisessa Internet-maailmassa. On olemassa lukuisia tutkimuksia, jotka todistavat kiistatta, että sivupudotus ja käyttäjistä luopuminen lisääntyvät hyvin nopeasti sivun viiveen myötä.

Jos sivun latautuminen kestää 200 ms kauemmin, sillä on potentiaalisesti suuri vaikutus liiketoimintaan ja myyntiin (katso tämä Googlen tutkimus). Tämä pätee vielä enemmän mobiililaitteissa, joissa sovellukset ovat yleensä hitaampia.

Miksi ei sitten käytetä SPA-sovelluksia kaikkialla?

Kun otetaan huomioon nämä tilastot ja se tosiasia, että SPA-sovellukset antavat paljon paremman käyttäjäkokemuksen, miksi kaikki eivät käytä yksisivuisia sovelluksia kaikkeen?

Sovelluksia on ollut olemassa jo vuosia, ja mikä tahansa verkkosivusto, jossa on navigointijärjestelmä, voisi hyötyä siitä, että se rakennetaan tällä tavalla.

Yksisivuisen sovelluksen SEO-vaikutusten ymmärtäminen

On yksi merkittävä syy, miksi yksisivuisia sovelluksia ei toistaiseksi käytetä kaikkialla (kaksi erillistä syytä):

Yksisivuiset sovellukset eivät suoriudu hyvin hakukoneissa

Kaksi syytä tähän ovat:

Hakukoneen on ”arvattava”, milloin sivu on valmis

Kun yksisivuinen sivu haetaan, hakukone näkee vain hyvin vähän HTML:ää. Vasta kun MVC-kehys käynnistyy, sivu todella renderöidään kokonaan käyttäen palvelimelta saatuja tietoja.

Ongelmana on, että hakukoneen on arvattava, milloin Javascript-kehys lopettaa sivun renderöinnin, joten on olemassa vaara, että epätäydellinen sisältö indeksoidaan.

Toinen syy siihen, miksi SPA:t eivät suoriudu hyvin hakukoneiden kanssa, on:

SPA-syvälinkkejä on vaikea saada indeksoitua

Johtuen HTML5-historiatuen puuttumisesta selaimissa, yksisivuiset sovellukset perustivat navigointi-URL:nsä HTML-kirjanmerkkiankkureihin (URL-osoitteet, joissa on #, kuten /home#section1). Hakukoneet eivät indeksoi näitä helposti erillisinä sivuina, on olemassa tapoja tehdä se, mutta se on hankalaa ja tulee aina olemaan vaikeuksia saada tämä indeksoitua oikein verrattuna pelkän HTML:n käyttöön.

Johtopäätös voisi olla, että ei ole mitään järkeä pitää kaikkein helpoimmin navigoitavaa sivustoa, jos tapa, jolla se on rakennettu, estää hyvän SEO:n saamisen.

Nyt hyvät uutiset

Hyvät uutiset ovat se, että yksikään näistä kahdesta syystä ei ole enää 100-prosenttisen tarkka! Google on alkanut indeksoida paremmin yhden sivun sovelluksia.

Ja IE9:n hiljattainen poistuminen käytöstä tarkoittaa, että HTML5-historia on saatavilla lähes kaikkialla, jolloin ankkuri-URL:ien käyttöä ei enää tarvita SPA:issa, vaan voimme käyttää pelkkiä URL-osoitteita (kuten /home/section1).

Tämä on hieno uutinen, mutta on muitakin hakukoneita, jotka tuovat merkittävää liikennettä. Baidu esimerkiksi ajaa yli puolet Kiinan liikenteestä (nyk. 1,3 miljardia ihmistä).

Myös suorituskyky on edelleen ongelma: yhden sivun sovellus on hitaampi sen tarvitsemien suurten Javascript-määrien ja suuren käynnistysajan vuoksi, ja siksi se suoriutuu huonommin kuin HTML-pohjainen ratkaisu.

Ja tämä tarkoittaa sivujen putoamista, tämä ongelma ei poistu lähiaikoina, varsinkaan mobiilissa. Onko olemassa mitään keinoa saada kaikkien maailmojen parhaat puolet ja saada sekä välitön navigointi, SEO-ystävällisyys että korkea suorituskyky mobiilissa?

Vastaus on kyllä, Angular Universalilla.

Mikä on Angular Universal, mitä se mahdollistaa?

Lyhyesti sanottuna Angular Universal mahdollistaa sellaisten sovellusten rakentamisen, joissa on sekä yksisivuisten sovellusten suorituskyky- ja käyttäjämyönteisyysetuja yhdistettynä staattisten sivujen SEO-ystävällisyyteen.

Server-side rendering ei todellakaan ole pelkkää renderöintiä palvelimella

Angular Universalissa on useita muitakin ominaisuuksia kuin se, että se antaa ratkaisun HTML:n renderöintiin palvelimella. Käsitteen ”palvelinpuolen renderöinti” perusteella voisi ajatella, että se mitä Angular Universal tekee, on samanlaista kuin esimerkiksi Jaden kaltainen palvelinpuolen template-kieli. Siinä on kuitenkin paljon enemmän toiminnallisuutta.

Angular Universalilla saat tuon alkuperäisen HTML-hyötykuorman renderöityä palvelimella, mutta käynnistät myös karsitun Angular-version asiakkaalla, ja sieltä Angular ottaa sivun haltuunsa yhden sivun sovelluksena, joka generoi sieltä käsin kaiken HTML:n asiakkaalla palvelimen sijasta.

Siten lopputulos, jonka saat, on sama, se on käynnissä oleva yksisivuinen sovellus, mutta nyt, koska sait alkuperäisen HTML-hyötykuorman palvelimelta, saat paljon paremman käynnistysajan ja myös täysin SEO-indeksoitavissa olevan sovelluksen.

Pre-renderointi rakentamisajankohtana – lataa valmiiksi renderöityjä applikaatioita Amazon S3:iin

Muutama mahdollisuus, jonka Angular Universal avaa, on sisällön esirenderöintiä rakennusaikana sisällön ollessa harvoin muuttuvaa. Tämä on mahdollista joko Grunt-, Gulp- tai Weppack-liitännäisten avulla. Tältä näyttää Gulp-konfiguraatio, joka esirenderöi sovelluksemme sisällön tiedostoon:

Ja sen jälkeen lataamme tämän yksinkertaisesti Amazonin S3-ämpäriin Amazonin CLI:n avulla:

Jos linkitämme tämän ämpärin Cloudfront CDN -jakeluun, meillä on erittäin edullinen ja skaalautuva verkkosivusto.

Mitä jos käyttäjä alkaa olla vuorovaikutuksessa sivun kanssa välittömästi?

Aluksi on viive sen hetken välillä, kun pelkkä HTML renderöidään ja esitetään käyttäjälle, ja sen hetken välillä, kun Angular käynnistyy asiakaspuolella ja ottaa SPA:n tehtävät hoitaakseen.

Tässä ajassa käyttäjä saattaa napsauttaa jotakin tai jopa alkaa kirjoittaa hakukenttään. Se, mitä Angular Universal mahdollistaa preboot-toiminnallisuutensa kautta, on tallentaa käyttäjän käynnistämät tapahtumat ja toistaa ne, kun Angular käynnistyy.

Siten Angular pystyy reagoimaan näihin tapahtumiin, kuten esimerkiksi näyttämään hakutulokset Typeahead-listalla.

Mutta miltä tämä näyttää palvelimella koodin kannalta?

Miten HTML:ää renderöidään Angularilla palvelimella

Tapa, jolla sisältö renderöidään palvelimella, on käyttämällä Express Angularin universaalia renderöintimoottoria expressEngine :

Myös Hapi-moottori on saatavana, jos mieluummin käytät Hapia Expressin sijaan. Palvelinrenderöintimoottoreita on myös tulossa kaikenlaisille alustoille: C#, Java, PHP, katso lisätietoja tästä aiemmasta postauksesta.

Miten aloittaa Angular Universal?

Paras paikka aloittaa on virallinen starter universal-starter, starterin avulla saamme käynnissä olevan sovelluksen, joka sisältää Express-palvelimen, jossa palvelinpuolen renderöinti toimii suoraan laatikosta.

Uusiutuvaista Angular Universalissa on sen helppokäyttöisyys. Yksi Angular Universalin tärkeimmistä suunnitteluominaisuuksista on tapa, jolla se käyttää riippuvuusinjektiota.

Server Side Rendering Development is not like coding for the client only

Useimmiten haluamme sovelluksemme tekevän palvelimella täsmälleen saman asian kuin asiakkaalla olemalla riippuvainen suoraan selaimen API:ista.

Palvelinpuolen renderöintikehityksen todellisuus on se, että se ei aina ole mahdollista, ja on tiettyjä asioita, jotka haluamme tehdä eri tavalla asiakkaalla ja palvelimella.

Vidaan esimerkiksi kaavion renderöinti: haluat luultavasti kutsua kolmannen osapuolen kirjastoa, joka käyttää SVG:tä. Emme voi kutsua sitä palvelimella, joten miten renderöimme sen?

Toinen esimerkki: miten voimme renderöidä todennetut sivut? Koska sisältö riippuu siitä, kuka on tällä hetkellä kirjautuneena sisään.

Dependency Injectionin käyttäminen todennuksen toteuttamiseen

Todennuksen käsittelyyn on yksi tapa:

  • Clientillä haluamme, että käyttäjän identiteetti otetaan joko evästeessä tai selaimen paikallisessa tallennustilassa olevasta tokenista.

  • Palvelimella, kun pyyntöä renderöidään, haluamme identiteettitunnisteen luettavan HTTP-pyyntöotsakkeesta.

Miten saamme saman sivun tulostuksen, kun navigoimme kyseiselle sivulle asiakkaalla reitittimen siirtymän kautta vs. palvelimella selaimen päivityksen kautta?

Ensiksi määrittelemme palvelurajapinnan

Ensimmäinen askel on määritellä rajapinta, jonka palvelusi tarjoaa ja joka on riippumaton ajoajasta:

Sitten tarjoamme tälle rajapinnalle kahta toteutusta, toista asiakasta ja toista palvelinta varten. Esimerkiksi palvelimella ei ole tilaisuutta kutsua sisäänkirjautumismetodia, joten heitämme virheen:

Asiakkaalla taas käynnistämme Auth0-lukitusnäytön (kolmannen osapuolen vain selaimelle tarkoitettu kirjasto), joka tarjoaa sisäänkirjautumislomakkeen:

Silloin injektoimme rajapinnan eri toteutuksia palvelimella ja asiakkaalla samalle injektiotunnukselle:

Ja näin voimme tehdä jotain erilaista asiakkaalla ja palvelimella Angular Universalissa hyödyntämällä Angularin riippuvuusinjektiosäiliötä.

Itse asiassa Angular Universal on rakennettu myös tätä ajatusta hyödyntäen: esimerkiksi tapa, jolla HTML renderöidään, on se, että sen sijaan, että DOM-renderöijä injektoitaisiin kehystä käynnistettäessä, se injektoi palvelinrenderöijän, joka tuottaa HTML:n käyttämällä parse5 HTML-serialisointikirjastoa.

Johtopäätökset

Kuten mikä tahansa teknologia, myös palvelimen puolen renderöinnin edut tulevat kehittymään ajan myötä. Mutta juuri nyt palvelinpuolen renderöinti tarjoaa suuren edun, kun rakennetaan mobiiliystävällisiä, hakukoneystävällisiä sovelluksia, joilla on korkea käyttäjien sitoutuminen saumattomasti välittömän navigoinnin ansiosta.

Tänä päivänä on helpompaa kuin koskaan rakentaa tämäntyyppisiä sovelluksia Angular Universalin ja universaalin aloittajan avulla.

Angular Universalissa riippuvuusinjektion käyttö tekee hyvin yksinkertaiseksi sen, että voimme tehdä palvelimella jotakin hiukan erilaista palvelimella kuin asiakkaalla, jos on tarve.

Getting Started With Angular

Jos haluat oppia lisää Angularista, katso Angular for Beginners -kurssi:

Muut Angularia käsittelevät postaukset

Jos pidit tästä postauksesta, tässä muita suosittuja postauksia blogissamme:

  • Angular Router – Kuinka rakentaa navigointivalikko Bootstrap 4:llä ja sisäkkäisillä reiteillä
  • Angular Router – Laajennettu opastus, Yleisten sudenkuoppien välttäminen
  • Angular Components – The Fundamentals
  • 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, Model Driven or In-Between
  • Angular ngFor – Learn all Features including trackBy, why is it not only for Arrays ?
  • Angular Universal käytännössä – Miten rakentaa SEO-ystävällisiä yhden sivun sovelluksia Angularilla
  • Miten Angularin muutostunnistus oikeasti toimii?

Leave a Reply