MPA, SPA, PWA, kézako ? Faisons le point !

par | Déc 1, 2020 | Technologie

Partagez
Tweetez
Partagez

Depuis quelques années, nous avons vu apparaître les termes SPA, PWA ou même MPA. Qu’est-ce que cela signifie ? Est-ce que c’est compliqué ? Est-ce compatibles ensemble ? Dans tous les cas, on parle d’application web.

MPA

Pour comprendre la suite, notamment les SPA, il nous faut revenir un petit peu en arrière ; même si le terme MPA est finalement apparu assez récemment, parce qu’il fallait bien nommer ce qui n’était pas SPA !

Il y a fort longtemps, on ne parlait pas de MPA, puisqu’il n’y avait que cela ; c’est ce qui a toujours été fait quand on faisait un site web.

Un site dit statique, avec simplement des pages html, sans rien de plus, est un site MPA. Même si le site est dit dynamique, c’est-à-dire pouvant générer du contenu ou des pages en fonction des actions de l’utilisateur, il restera un site MPA à plusieurs pages.

Le point commun des MPA ? A chaque interaction de l’utilisateur, telle une soumission de formulaire, toute la page est rechargée, même s’il n’y a qu’une petite partie du qui doit changer. Selon les cas, cela peut rendre l’expérience utilisateur assez mauvaise.

Techniquement, le client (le navigateur) charge une page HTML générée par le serveur, et à chaque action utilisateur, une nouvelle page est générée et affichée par le client.

Afin d’améliorer un petit peu l’expérience utilisateur, les développeurs web ont commencé à intégrer un peu de JavaScript (qui ne sert pas uniquement pour faire tomber de la neige) et des requêtes AJAX.

Cela a permis d’ajouter un peu de dynamisme côté client et de ne mettre à jour que la partie de la page concernée par l’action utilisateur. Le cas d’usage le plus courant est la grille de donnée : un changement de critères de tri, de filtre ou de pagination recharge uniquement la grille et non pas toute la page. C’est une première étape et, pour l’utilisateur, c’est déjà bien plus agréable. Cela peut se faire via des librairies de contrôles génériques (Kendo par exemple) ou spécifiques (DataTables), ou « à la main ».

C’est également une majeure partie des sites aujourd’hui : du MPA avec du plus ou moins de dynamique dans chaque page ; par exemple la plupart des sites d’e-commerce.

Le développement d’une MPA se fait assez simplement avec un langage et librairie web côté serveur : C# Asp.Net, PHP, Python…

Les pages HTML sont générées côté serveur par le moteur de template du langage avant d’être transmises au client. Il n’est pas obligatoire ni nécessaire de faire du JavaScript, même s’il est toujours plus agréable pour l’utilisateur d’avoir un peu plus de dynamisme dans les pages.
Finalement les MPA sont assez classiques, avec un processus de développement maîtrisé.

SPA

Une SPA, ou Single Page Application, est, comme son nom l’indique, une application à page unique.

Pourquoi à “page unique” ? Tout simplement parce que le navigateur va charger une seule page web (avec ses CSS et JS nécessaires) qui est capable de se modifier en tout ou en partie, en fonction des actions de l’utilisateur, sans jamais se recharger complètement. Et pourtant, cela n’empêche pas que visuellement tout (ou presque, car en général la barre de navigation reste) le contenu puisse changer, pour simuler un changement de page ; dans ce cas, on parle plutôt de changement de “vue”.

Probablement une des plus ancienne et connue est Gmail. Ce n’est maintenant plus la seule : à peu près tous les réseaux sociaux sont des SPA (ou ont une grosse partie de SPA combinée dans un gros site MPA).

Techniquement, tout le chargement se fait via des requêtes AJAX, via faisant appel à des API pour récupérer les données, les traiter côté client. Il n’y a plus d’échange de pages ou de parties de pages, mais uniquement de données, et c’est le moteur de template côté client qui fait le travail de rendu.

Nous avons maintenant un back-end fournissant uniquement des API, couplé à un front-end qui n’est rien d’autre qu’une application cliente de ces API. Le gros avantage, est que si demain nous souhaitons développer une application mobile, il est tout à fait possible et rapide d’utiliser ces mêmes API pour la construire.

Côté technique, lorsque l’on parle développement d’une SPA, on entre dans le monde du front-end. Ici, tout est JavaScript, que ce soit à la main ou via des librairies. Car oui il est possible de faire une SPA « à la main », aucun problème à cela. Cependant nous aurons probablement à recoder des choses qui sont déjà fournies par les principales librairies/frameworks que sont Angular, React et Vue.js (liste non exhaustive).

Tout est JavaScript ?! C’était effectivement le cas jusqu’à il y a environ 2 ans, où Microsoft a lancé Blazor : un framework permettant de faire du dynamique côté client, tout en ne faisant que du C#.

Nous en parlons ici par rapport aux SPA, cependant il n’est absolument pas cantonné aux SPA : il peut très bien, à l’instar des Angular, React et Vue.js, s’insérer dans une page d’une MPA pour profiter de leurs avantages et rendre cette page dynamique et réactive.

Il y a plusieurs mécanismes qui entrent en jeu dans une SPA avec une librairie : du data binding automatique, du routing pour afficher de jolies URLs dans la barre d’adresse, du cache…

MPA/SPA – Avantages / Inconvénients

MPA SPA
SEO X Mais des techniques existent pour l’améliorer

Accessibilité

(lecteurs d’écran…)

 X
Temps de chargement

+ Initial plus court

– Chaque page chargée en entier

– Initial plus long

+ Réactivité à chaque action
Développement + Process éprouvés – Librairies/frameworks moins stables
Réutilisabilité + Composants, API
UX X

SEO

Meilleur avec les MPA : la page étant générée côté serveur, toutes les données arrivent au navigateur (ou au moteur de recherche). Il n’y a pas besoin d’interpréter de JavaScript pour générer la page demandée.

Pour les SPA, il existe cependant des outils, notamment la génération côté serveur, pour améliorer cela. Ils permettent de générer directement la page demandée. Elles nécessitent cependant toujours JavaScript pour fonctionner côté client, même si les moteurs de recherche commencent à savoir les indexer correctement.

Accessibilité

Mêmes avantages, pour les mêmes raisons.

Temps de chargement

Les MPA ne chargeant qu’une page (et un peu de JS/CSS), le temps initial est plus court ; ce qu’il faut contrebalancer à chaque action car il faut rafraichir toute la page.

Pour les SPA, c’est le chargement initial qui est plus long : chargement d’une page HTML vide (sauf si génération côté serveur) et les JS/CSS associés, puis analyse de l’URL pour connaître la « vue » à afficher et récupération des données nécessaires pour afficher cette vue. En revanche, à chaque action utilisateur, seule la partie de page concernée est mise à jour.

Développement

Les MPA existant depuis longtemps, les outils sont donc maîtrisés et relativement stables.

Les SPA étant plus récentes, les changements des librairies/frameworks sont plus réguliers et parfois critiques : rappelez-vous le passage de AngularJS (v1) à Angular (v2), où tout le fonctionnement et la structure étaient différents ! Elles ont néanmoins tendance à se stabiliser avec le temps.

Réutilisabilité

Du fait de l’architecture des librairies/frameworks SPA, le découpage en composants est standard, presque obligatoire ; il est donc plus aisé qu’avec les MPA. Les composants fonctionnant quasi indépendamment, il est bien plus facile de les réutiliser d’un projet à l’autre.
De plus, le fait de n’utiliser que des API aide le passage à une appli mobile par exemple.

UX

Nous l’avons déjà évoqué : le fait de ne recharger que la partie de page concernée par l’action utilisateur rend notre application bien plus fluide, ce qui améliore l’expérience utilisateur.

MPA/SPA – Que choisir ?

Eh bien le choix n’est pas aussi simple, et il n’y a pas de « meilleure » technologie adaptée à tous les cas d’usage : tout dépend du projet, du besoin d’UX, du profil des développeurs…

Prenons trois exemples.

Un blog ou site institutionnel…

… avec du contenu plutôt statique et peu d’interaction utilisateur.

Bien qu’il soit possible de faire une SPA, les avantages qu’elle apporte ne vont être que peu utiles, et, sauf si l’équipe est habituée aux SPA, cela risque d’apporter de complexité dans le développement qui ne sera pas compensée par les avantages.

Un produit client avec une bonne UX

Si l’UX et la réactivité priment, bien qu’il soit possible de le faire avec une MPA, il sera plus aisé de le faire avec une SPA.

Un backoffice

Certes l’expérience utilisateur n’est pas au cœur du produit, cependant il peut être utile de faire une SPA, notamment pour simplifier tout le code JS que l’on pourrait faire manuellement pour rendre les pages dynamiques. Et puis la réutilisabilité des composants est également un avantage dont il faut tenir compte.

Il est également possible de faire de l’hybride : utiliser un framework SPA dans une page d’une MPA, pour dynamiser cette page complexe dans laquelle l’UX est importante.

Autres techniques pour « améliorer » l’UX d’un site MPA.

PWA

Dernier sigle pour cet article : PWA, pour Progressive Web Application.

Il s’agit ici plutôt d’un concept que d’une ou de plusieurs technologies, car celles utilisées par les PWA existent depuis longtemps : ce sont HTML, CSS et JavaScript. Alors qu’est-ce qui fait qu’un site devient une PWA, ou que proposent-elles de si particulier ?

Le but d’une PWA est de fournir une expérience utilisateur la plus proche possible de celle d’une application native. Cela est d’autant plus vrai sur mobile. Ces sites dits “PWA” peuvent donc s’installer et apparaître comme des applications natives ; ils peuvent également utiliser des API système, proposer un fonctionnement hors ligne, des notifications…

L’inconvénient est que pour le menu pour les « installer » est en général peu visible, ce qui n’est pas à leur avantage. Cela est malheureusement dépendant de ce que veulent bien mettre en avant les navigateurs.

Techniquement, donc, il y a deux choses absolument nécessaires pour “faire” une PWA : un manifest et un service worker.

Le manifest

C’est de fichier JSON qui décrit l’application et qui permet aux navigateurs de la découvrir et de proposer aux utilisateurs « d’installer » l’application.

On y retrouve notamment le nom de l’application, ses icônes (en différentes tailles), le code couleur à appliquer à la fenêtre de navigateur…

Plus d’infos https://www.w3.org/TR/appmanifest/

Exemple de fichier manifest :

{
    "name": "AccessSchool - Portail de Notation",
    "short_name": "Portail Notation",
    "theme_color": "#164D73",
    "background_color": "#164D73",
    "display": "standalone",
    "orientation": "landscape",
    "Scope": "/",
    "start_url": "/",
    "icons": [
        {
            "src": "../images/icons/icon-72x72.png",
            "sizes": "72x72",
            "type": "image/png"
        },
        // ...
        {
            "src": "../images/icons/icon-512x512.png",
            "sizes": "512x512",
            "type": "image/png"
        }
    ]
}

Le service worker

Les service workers, sont des “job” JavaScript qui s’exécutent dans le navigateur séparément du site, tout en communiquant avec lui, agissant comme une sorte de proxy entre le site (dans le navigateur) et internet. Cela leur permet de gérer une stratégie de mise en cache d’éléments (pages, images…) ou de données (résultat d’appel d’API, ou en attente d’envoi), pour permettre un fonctionnement hors ligne.

Pas d’exemples ici, il y a tellement de possibilités.

N’hésitez pas à aller par exemple sur PWA Builder.

Peut-on faire une PWA avec une SPA ou une MPA ?

Tout à fait ! Il est possible de faire une PWA avec une MPA ; il est également possible de le faire avec une SPA.

Il suffit simplement de définir correctement son manifest et les règles de mise en cache (si l’on souhaite un mode hors ligne). Notons qu’il sera plus simple de proposer un fonctionnement hors ligne complet avec une SPA.

Plus d’articles :

Le paiement mobile

Le paiement mobile

par | 22 Sep 2022 |

Quels sont les pros et les cons de ce nouveau mode de paiement ? Quelles sont les technologies d’intelligences artificielles derrière cette révolution de paiement ? Quels enjeux envisage-t-on dans un futur proche ?