Angular Universal en pratique – Comment construire des applications monopages adaptées au référencement avec Angular

On a beaucoup parlé d’Angular au cours des derniers mois et de la façon de l’utiliser pour construire des applications clientes, mais l’une de ses innovations les plus importantes se produit en fait sur le serveur.

C’est une technologie qui pourrait aider à permettre un tout nouveau type d’applications Web : Angular Universal. Découvrons-en davantage ! Passons en revue les sujets suivants :

• Avantages des applications à page unique
• Pourquoi n’utilisons-nous pas des applications à page unique partout alors ?
• Comprendre les implications SEO d’une application à page unique
• Qu’est-ce qu’Angular Universal, que permet-il ?
• Le rendu côté serveur n’est vraiment pas seulement un rendu sur le serveur
• Une démo d’une app à page unique rendue côté serveur en action
• Pré-rendu au moment de la construction – téléchargez les apps pré-rendues sur Amazon S3
• La fonctionnalité tueuse d’Angular Universal : Dependency Injection
• Conclusions

Ce post est une introduction à Angular Universal. Pour un guide plus détaillé couvrant comment l’utiliser en pratique, jetez un coup d’œil à ce post:

Angular Universal : un guide pratique complet

Avantages des applications à page unique

Les applications à page unique existent depuis un certain temps, et les frameworks comme Angular, React ou Ember sont probablement les bibliothèques Javascript qui reçoivent le plus d’attention dans le monde Javascript.

Les avantages des SPA ne sont en réalité qu’une seule chose

Les avantages des applications à page unique sont potentiellement nombreux :

• lorsque l’utilisateur navigue sur la page, seules des parties de celle-ci sont remplacées, ce qui rend l’expérience plus fluide
• après le premier chargement de la page, seules les données passent sur le fil lorsque l’utilisateur navigue dans l’application : JSON est livré au navigateur et appliqué aux modèles HTML directement au navigateur
• ce qui conduit à de meilleures performances et ouvre la possibilité pour ces services backend d’être utilisés pour d’autres choses, puisqu’ils ne font que retourner des données

Nous pouvons résumer cela à une seule chose :

Les applications à page unique peuvent fournir une bien meilleure expérience utilisateur !

Et l’expérience utilisateur est critique dans le monde de l’Internet public. Il existe de nombreuses études qui prouvent sans l’ombre d’un doute que le décrochage des pages et l’abandon des utilisateurs augmentent très rapidement avec le retard des pages.

Si une page prend 200ms de plus à charger, cela aura un impact potentiel élevé sur les affaires et les ventes (voir cette recherche de Google). C’est encore plus vrai sur les appareils mobiles où les apps ont tendance à être plus lentes.

Pourquoi ne pas utiliser les SPA partout alors ?

Compte tenu de ces statistiques et du fait que les SPA offrent une expérience utilisateur bien améliorée, pourquoi tout le monde n’utilise-t-il pas des apps à page unique pour tout ?

Elles existent depuis des années, et tout site Web avec un système de navigation pourrait bénéficier d’être construit de cette façon.

Comprendre les implications SEO d’une application à page unique

Il y a une raison majeure pour laquelle les applications à page unique ne sont pas utilisées partout jusqu’à présent (avec deux causes distinctes) :

Les apps à page unique ne sont pas performantes sur les moteurs de recherche

Les deux raisons à cela sont :

Le moteur de recherche doit « deviner » quand la page est complète

Lorsqu’une page unique est récupérée, un moteur de recherche ne verra que très peu de HTML. Ce n’est que lorsque le framework MVC entre en action que la page sera réellement rendue entièrement en utilisant les données obtenues du serveur.

Le problème est que le moteur de recherche doit deviner quand le framework Javascript termine le rendu de la page, il y a donc un risque d’indexer un contenu incomplet.

La deuxième raison pour laquelle les SPA n’obtiennent pas de bons résultats auprès des moteurs de recherche est :

Les liens profonds des SPA sont difficiles à indexer

En raison de l’absence de prise en charge de l’historique HTML5 dans les navigateurs, les applications à page unique ont basé leurs URL de navigation dans des ancres de signet HTML (URL avec #, comme /home#section1). Ceux-ci ne sont pas facilement indexés comme des pages séparées par les moteurs de recherche, il y a des moyens de le faire mais c’est une douleur et il y aura toujours des difficultés à obtenir cette indexation correcte par rapport à l’utilisation du simple HTML.

La conclusion pourrait être qu’il n’y a aucun intérêt à avoir le site le plus facilement navigable si la façon dont il est construit empêche d’avoir un bon référencement.

Maintenant la bonne nouvelle

La bonne nouvelle est qu’aucune de ces deux raisons n’est plus exacte à 100% ! Google a commencé à mieux indexer les applications à page unique.

Et la récente dépréciation d’IE9 signifie que l’histoire HTML5 est disponible presque partout, ce qui rend l’utilisation des URL d’ancrage plus nécessaire pour les SPA, nous pouvons simplement utiliser des URL simples (comme /home/section1).

Ce sont de bonnes nouvelles, mais il y a d’autres moteurs de recherche qui génèrent un trafic important. Baidu, par exemple, génère plus de la moitié du trafic en Chine (actuellement 1,3 milliard de personnes).

De plus, il y a toujours la question des performances : une application à page unique sera plus lente en raison des grandes quantités de Javascript dont elle a besoin et du temps de démarrage important, et sera donc moins performante qu’une solution basée sur HTML.

Et cela signifie des chutes de pages, ce problème ne disparaîtra pas de sitôt, en particulier sur le mobile. Existe-t-il un moyen d’avoir le meilleur de tous les mondes, et d’obtenir à la fois une navigation instantanée, une convivialité SEO et des performances élevées sur mobile ?

La réponse est Oui, avec Angular Universal.

Qu’est-ce qu’Angular Universal, que permet-il ?

En termes simples, Angular Universal nous permet de construire des applications qui ont à la fois les avantages de performance et d’engagement de l’utilisateur des applications à page unique, combinés avec la convivialité SEO des pages statiques.

Le rendu côté serveur n’est vraiment pas seulement un rendu sur le serveur

Angular Universal a plusieurs autres fonctionnalités autres que de donner une solution pour rendre le HTML sur le serveur. En se basant sur le terme « server-side rendering », on pourrait penser que ce que fait Angular Universal est similaire par exemple à un langage de template côté serveur comme Jade. Mais il y a beaucoup plus de fonctionnalités.

Avec Angular Universal, vous obtenez cette charge utile HTML initiale rendue sur le serveur, mais vous démarrez également une version réduite d’Angular sur le client et à partir de là, Angular prend en charge la page comme une application à page unique, générant à partir de là tout le HTML sur le client au lieu du serveur.

Donc le résultat final que vous obtenez est le même, c’est une application à page unique en cours d’exécution, mais maintenant parce que vous avez obtenu la charge utile HTML initiale du serveur, vous obtenez un temps de démarrage bien meilleur et aussi une application entièrement indexable par SEO.

Pré-rendu au moment de la construction – télécharger les applications pré-rendues sur Amazon S3

Une autre possibilité qu’Angular Universal ouvre est le pré-rendu du contenu qui ne change pas fréquemment au moment de la construction. Cela sera possible en utilisant soit les plugins Grunt, Gulp ou Weppack. Voici à quoi ressemblera une configuration Gulp qui pré-rend le contenu de notre application dans un fichier :

Et ensuite, il suffit de le télécharger vers un seau Amazon S3 en utilisant le CLI Amazon :

Si nous lions ce seau à une distribution CDN Cloudfront, nous avons un site web très abordable et évolutif.

Et si l’utilisateur commence à interagir avec la page immédiatement ?

Il y a un décalage initial entre le moment où le HTML brut est rendu et présenté à l’utilisateur et le moment où Angular entre en action côté client et prend le relais en tant que SPA.

Dans ce laps de temps, l’utilisateur pourrait cliquer sur quelque chose ou même commencer à taper dans une boîte de recherche. Ce que permet Angular Universal via sa fonctionnalité preboot, c’est d’enregistrer les événements que l’utilisateur déclenche, et de les lire une fois qu’Angular se met en marche.

De cette façon, Angular pourra répondre à ces événements, comme par exemple en montrant les résultats de la recherche sur une liste Typeahead.

Mais à quoi cela ressemble sur le serveur en termes de code ?

Comment rendre du HTML avec Angular dans le serveur

La façon dont le contenu est rendu sur le serveur est en utilisant le moteur de rendu express Angular Universal expressEngine :

Il y a aussi un moteur Hapi disponible si vous préférez utiliser Hapi au lieu d’Express. Il y a aussi des moteurs de rendu de serveur qui arrivent pour toutes sortes de plateformes : C#, Java, PHP, voir ce post précédent pour plus de détails.

Comment commencer avec Angular Universal?

Le meilleur endroit pour commencer est le starter officiel universal-starter, avec le starter nous obtenons une application en cours d’exécution qui comprend un serveur express avec un rendu côté serveur qui fonctionne dès la boîte.

Ce qui est innovant à propos d’Angular Universal est sa simplicité d’utilisation. L’une des principales caractéristiques de conception d’Angular Universal est la façon dont il utilise l’injection de dépendance.

Le développement du rendu côté serveur n’est pas comme coder pour le client seulement

La plupart du temps, nous voulons que notre application fasse exactement la même chose sur le serveur que sur le client, en ne dépendant pas directement des API du navigateur.

La réalité du développement du rendu côté serveur est que ce n’est pas toujours possible, et il y a certaines choses que nous voulons faire différemment sur le client et sur le serveur.

Prenez par exemple le rendu d’un graphique : vous voulez probablement appeler une bibliothèque tierce qui utilise SVG. Nous ne pouvons pas l’appeler sur le serveur, alors comment le rendre ?

Autre exemple, comment rendre des pages authentifiées ? Parce que le contenu dépend de qui est actuellement connecté.

Utilisation de l’injection de dépendance pour mettre en œuvre l’authentification

Pour gérer l’authentification, voici une façon de le faire :

• Sur le client, nous voulons que l’identité de l’utilisateur soit prise à partir d’un jeton disponible soit sur un cookie, soit dans le stockage local du navigateur.

• sur le serveur, lors du rendu de la requête, nous voulons que le jeton d’identité soit lu à partir d’un en-tête de requête HTTP.

Comment avoir la même sortie de page tout en naviguant vers cette page sur le client via une transition de routeur vs sur le serveur via un rafraîchissement du navigateur ?

D’abord définir une interface de service

La première étape est de définir une interface que votre service fournira, qui est indépendante du runtime :

Puis nous fournissons deux implémentations pour cette interface, une pour le client et l’autre pour le serveur. Par exemple sur le serveur, il n’y a pas d’occasion pour que la méthode de connexion soit appelée, donc nous jetons une erreur:

Tandis que sur le client, nous allons déclencher l’écran de verrouillage Auth0 (une bibliothèque tierce uniquement pour le navigateur) pour fournir un formulaire de connexion :

Nous injectons ensuite différentes implémentations de l’interface sur le serveur et sur le client, pour le même jeton d’injection:

Et voici comment nous pouvons faire quelque chose de différent sur le client et sur le serveur dans Angular Universal, en tirant parti du conteneur d’injection de dépendances Angular.

En fait, Angular Universal est construit aussi en utilisant cette notion : par exemple, la façon dont le HTML est rendu est par au lieu d’injecter un moteur de rendu DOM pendant le bootstrapping du framework, il injecte un moteur de rendu serveur qui génère du HTML en utilisant la bibliothèque de sérialisation HTML parse5.

Conclusions

Comme toute technologie, les avantages du rendu côté serveur évolueront avec le temps. Mais à l’heure actuelle, le rendu côté serveur présente un grand avantage pour la construction d’applications conviviales pour les mobiles et les moteurs de recherche qui ont un engagement élevé des utilisateurs en raison de la navigation instantanée sans faille.

Il est plus facile que jamais aujourd’hui de construire ces types d’applications en utilisant Angular Universal et le démarreur universel.

Avec Angular Universal, l’utilisation de l’injection de dépendances rend très simple de faire quelque chose de légèrement différent sur le serveur que sur le client si nous en avons besoin.

Débuter avec Angular

Si vous voulez en savoir plus sur Angular, jetez un coup d’œil au cours Angular pour débutants :

Autres articles sur Angular

Si vous avez aimé cet article, voici d’autres articles populaires sur notre blog :

• Routeur Angulaire – Comment construire un menu de navigation avec Bootstrap 4 et des routes imbriquées
• Routeur Angulaire – Visite guidée étendue, Éviter les pièges courants
• Composants Angular – Les fondamentaux
• Comment exécuter Angular en production aujourd’hui
• Comment construire des apps Angular en utilisant les services de données observables – Pièges à éviter
• Introduction à Angular Forms – Template Driven, Model Driven ou In-Between
• Angular ngFor – Apprenez toutes les fonctionnalités y compris trackBy, pourquoi n’est-il pas seulement pour les Arrays ?
• Angular Universal en pratique – Comment construire des applications monopages adaptées au référencement avec Angular
• Comment fonctionne vraiment la détection de changement d’Angular ?