Single-page application

Protégeons les applications !

Le modèle SPA est un réel apport pour les utilisateurs en terme de fluidité en évitant le rechargement complet des pages, tout en étant une très bonne approche pour l’éco-conception d’un site Web, mais sous certaines conditions.

Les applications web mono-page (SPA) ont été conceptualisées pour des applications Web qui peuvent fonctionner dans une seule page (une seul URL) comme une messagerie électronique, une application bureautique, un service de cartographie en ligne, etc. Mais le concept peut être utilisé pour des sites Web et s’y prête même très bien.

Un site Web est constitué de plusieurs pages (plusieurs URL), c’est donc une Multi-page application (MPA), où un lien d’une page vers une autre, engendre au clic un rechargement complet de la nouvelle page, alors que bien souvent, d’une page à une autre, il y a beaucoup d’éléments qui sont identiques.

Prenons pour exemple le site Web du journal Le Monde, c’est un site Web de facture classique : toutes les pages sont constituées grosso modo d’un entête, d’un contenu et d’un pied de page.

Regardons la composition HTML de la page d’un article au hasard :

  • La partie <head> (invisible à l’utilisateur) pèse 260 ko (🤔).
  • La partie entête avec la navigation pèse 47 ko.
  • Le contenu pèse 24 ko (10 ko pour l’article, le reste étant pour des bandeaux).
  • Le pied de page pèse 15 ko.

La page totale pèse 352 ko (il y a 6 ko en plus pour des bandeaux et l’inclusion de scripts qui sont probablement toujours les mêmes d’une page à une autre).

Ceci dit, 352 ko ce n’est rien, car en faisant défiler la page, les publicités, les contenus sponsorisés et les bandeaux se chargent et c’est plus 20 Mo de données qui sont traitées et qui correspondent à plus de 8 Mo transférés (merci à la compression).

En cliquant sur le lien d’une page du site, cette nouvelle page est entièrement chargée et vient remplacer la page courante. Hors, ce qui change visuellement entre 2 pages pour un utilisateur est uniquement le contenu, l’URL et le titre de la page (en excluant les publicités et autres bandeaux sponsorisés).

Avec l’exemple de notre page au hasard, si le site fonctionnait comme une SPA, il suffirait de changer uniquement la partie contenu de la nouvelle page et donc traiter 24 ko (voir 10 ko) de HTML et non pas 352 ko pour arriver au même résultat avec une rapidité accrue : pas de polices, de CSS ou de scripts à réinterpréter par le navigateur.

Nous voyons bien ici l’intérêt sur le plan de la consommation énergétique, le serveur pourrait produire et rendre beaucoup moins de données au client qui en aurait beaucoup moins à traiter.

Remarque : pour conserver l’aspect multipages d’un site web ainsi construit, il suffit d’utiliser l’History API présente dans tous les navigateurs depuis de nombreuses années.

Pour développer des SPA, la tendance actuelle est d’utiliser des librairies ou frameworks JavaScript qui assurent le rendu dans le navigateur en y produisant le HTML à partir de données récupérées sous le format JSON.

L’utilisation de librairies ou frameworks JavaScript a des avantages pour des applications qui n’ont réellement qu’une page, mais cette approche a de gros défauts pour des sites Web :

  • Le référencement sur les moteurs de recherche d’un site ainsi construit est problématique et nécessite d’ajouter d’autres techniques pour un référencement correct du site, ce qui ajoute de la complexité dans une architecture déjà bien complexe.
  • Le premier rendu de page peut être long à obtenir car le code JavaScript utilisé peut être lourd à transférer et à exécuter. Et ceci peut être notable si l’utilisateur dispose d’un mobile d’entrée ou moyenne gamme et d’un réseau qui n’est pas le top de la 5G.
  • L’impact environnemental est augmenté. Un navigateur Web est optimisé (code machine) pour convertir une chaîne de caractères HTML en éléments du DOM. Faire fonctionner dans un navigateur Web un script JavaScript (code interprété) sur une chaîne de caractères JSON pour la convertir en éléments du DOM consomme bien plus d’énergie.
  • Le coût et la durée de développement sont importants et augmentent aussi l’impact environnemental à cause de la complexité et de l’outillage nécessaire souvent imposé par les librairies ou frameworks JavaScript.
  • L’utilisation du site sans JavaScript devient problématique voire impossible.

En conclusion, les SPA sont bénéfiques pour les sites Web en réduisant la consommation d’énergie au niveau du serveur et des terminaux des utilisateurs. Mais les librairies ou frameworks JavaScript actuels qui produisent le HTML directement dans le terminal ne devraient pas être utilisés pour cela car ils amènent de nouveaux problèmes qui augmentent la consommation d’énergie.

Il faut donc faire des SPA basées sur d’autres approches que le « tout-JavaScript », nous en reparlerons dans de prochains articles.