Comment créer une application Web progressive A + avec React

Progressive Web Apps (PWA) suscite actuellement beaucoup d'enthousiasme, car les fournisseurs de navigateurs (y compris Safari) ajoutent des agents de service et d'autres API d'amélioration progressive. Qu'est-ce qui rend les applications Web progressives?

Google définit les PWA comme des expériences combinant le meilleur du Web et le meilleur des applications. Ils devraient être:

  • Rapide - répond rapidement aux interactions de l'utilisateur
  • Intégré - l'utilisateur n'a pas besoin de passer par le navigateur
  • Fiable - charge instantanément, même si le réseau est hors ligne / défectueux
  • Engager - inciter les utilisateurs à revenir avec une excellente expérience utilisateur

Tout cela est excellent mais vague. Google propose également une liste de contrôle pratique pour les applications Web progressives, mais il n’existe pas encore de réponse définitive quant à ce qu’est un PWA et à ce qui en fait un excellent.

Le PWA de base

Au niveau le plus élémentaire, un PWA est défini par les propriétés techniques qui permettent au navigateur de détecter que le site répond à certains critères et mérite d'être ajouté à l'écran d'accueil. Si les critères sont remplis, une invite de bannière «Ajouter à l'écran d'accueil» peut être affichée.

Exemple Ajouter à la bannière de l'écran d'accueil

Les trois règles d'or permettant d'afficher la bannière «Installation de l'application» sont les suivantes:

  1. L'application doit provenir d'une origine sécurisée
    Donc, il doit être servi sur SSL / HTTPS.
  2. L'application doit être chargée en mode hors connexion
    Il devrait fonctionner hors connexion (même s'il ne s'agit que d'une page hors connexion personnalisée ou d'une mise en cache de base). Cela signifie qu'un agent de service doit être installé.
  3. L'application doit référencer un manifeste d'application Web
    Un simple fichier JSON décrivant votre application.

L’ajout de cette fonctionnalité à votre application Web existante est une tâche relativement facile. Techniquement, vous disposez d’un PWA. Malheureusement, cela ne correspond pas nécessairement à la définition initiale de rapide, intégrée, fiable et attrayante. Si vous exécutez votre application via la liste de contrôle Google ou l'outil d'audit Google Lighthouse, vous trouverez probablement une liste énorme de problèmes.

Si vous avez un site Web avec un rendu de serveur, vous réaliserez alors que vous aurez des problèmes pour résoudre la liste des problèmes que Lighthouse vous rapporte. Dans une application Web rendue par le serveur lorsqu'un utilisateur appuie sur un bouton ou sur un lien, une attente commence à l'écran actuel avant de passer soudainement à un nouvel écran de contenu. Cela est inacceptable pour un PWA, car il trahit l’idée que l’application elle-même est exécutée localement sur l’appareil.

Si vous voulez vraiment transformer votre application Web en un PWA, vous devez déplacer le rapport de puissance entre une application Web rendue sur serveur et une application Web rendue sur un client. En bref, une nouvelle architecture d'application est requise.

Shell d'application

Le modèle App Shell réplique l'architecture d'une application native, fournissant ainsi un ensemble de code similaire à celui que vous téléchargeriez depuis l'App Store dans une application native.

La principale différence est que cet ensemble doit être téléchargé par un agent de service la première fois qu'un utilisateur visite l'application plutôt qu'indirectement depuis un magasin d'applications. Cela signifie que votre PWA doit être rapide. En fait, très rapide, car vous ne voulez pas que vos utilisateurs regardent un écran vide pendant 5 à 10 secondes pendant que votre PWA télécharge l’évier de la cuisine pour afficher le premier écran.

Un shell d'application doit contenir une interface utilisateur squelette et les principaux composants nécessaires au fonctionnement de l'application. Il est généralement responsable du routage mais il ne doit contenir aucune donnée.

Modèle de shell d'application

États de chargement

Une fois que vous avez un shell d'application où les données sont séparées de la présentation et que le client est responsable du rendu de l'interface utilisateur, le concept de chargement des états devient un modèle de conception naturel.

Lorsqu'une URL est demandée, le client peut initialement générer un état de chargement qui se charge instantanément car il fait partie de l'app Shell. En même temps, le client effectue une demande d’extraction des données. Une fois reçu, le client crée l’écran terminé et remplace l’état de chargement.

États de chargement

Le résultat final est une expérience bien meilleure pour l'utilisateur que d'appuyer sur un lien, de rester sur une page pendant 3 à 4 secondes, de voir un éclair de blanc et une page s'afficher lentement comme dans une application Web rendue par le serveur.

Division de code

Le modèle App Shell va de pair avec le fractionnement du code. Dans une application React standard, votre code est regroupé dans un seul fichier JavaScript. Dans un PWA, nous devons charger le premier écran le plus rapidement possible. Nous avons donc besoin d'un paquet plus petit, nous devons également mettre en cache chaque route séparément. En bref, nous devons diviser notre code JavaScript par code. Webpack peut vous aider ou vous pouvez utiliser quelque chose comme Preact, qui offre une division automatique du code.

Le code App Shell étant divisé et séparé du contenu, vous pouvez commencer à tirer pleinement parti des avantages dont bénéficient les travailleurs des services. Des fonctions auparavant peu pratiques peuvent être facilement proposées, par exemple:

  • Support hors ligne
  • Interface utilisateur de l'application pré-cache
  • Mettre en cache de manière dynamique les données / actifs réseau

Service Workers avec Workbox

Pour mettre en œuvre ces fonctionnalités, vous devez approfondir vos connaissances dans Service Workers. Il est tout à fait possible d’écrire à la main avec les prestataires de services. Cependant, Google a beaucoup travaillé pour vous avec Workbox.

Le juste milieu consiste à utiliser le plugin InjectManifest avec WebPack. Cela vous permettra de combiner votre propre code d'opérateur de service avec Workbox. Au minimum, vous devez implémenter:

  • Mise en cache préalable de votre shell d'application
  • Mise en cache d'exécution des données demandées et des actifs

Il y a beaucoup plus de travailleurs de service peuvent faire cependant, y compris:

  • Synchronisation en arrière-plan
  • Notifications push
  • Analyse hors ligne

Les ouvriers de service avec Workbox sont un sujet important. Si vous voulez en savoir plus, j’ai écrit un article séparé sur Workbox avec Preact.

Modèle PRPL

Votre application devrait maintenant être rapide à charger. Il dispose d’un shell d’application, d’une division du code et tout est mis en cache par un agent de service. En effet, nous avons mis en œuvre le modèle PRPL recommandé par Google pour PWA. PRPL met l'accent sur les performances de la livraison et du lancement de l'application. Ça signifie:

  • Pousser des ressources critiques pour le chemin initial
  • Rendre la route initiale
  • Pré-cache les itinéraires restants
  • Lazy-charger et créer des itinéraires restants à la demande

Bien que cela fonctionne avec HTTP / 1, il est probable que vous souhaiterez rechercher un hôte Web compatible HTTP / 2. HTTP / 2 permet les téléchargements multiplexés sur une seule connexion, de sorte que plusieurs petits fichiers peuvent être téléchargés plus efficacement.

Rendu côté serveur vs pré-rendu & CDN

Vous pouvez rendre côté serveur un itinéraire initial complet avec des données et laisser le client prendre en charge le rendu par la suite. Cela peut fournir un gain de vitesse initial, mais sa configuration peut être complexe. En général, je ne suis pas un fan en raison de la complexité qu’il ajoute à une base de code.

À mon avis, une meilleure solution consiste à pré-afficher un site Web statique et à l’héberger sur un réseau de diffusion de contenu (CDN) compatible HTTP / 2, offrant une vitesse incroyable et une simplicité de base de code. En prime, vous venez de réduire la complexité de votre hébergement car vous n'avez besoin que d'un hébergement Web statique!

Il existe de nombreuses options pour le pré-rendu, notamment:

  • Pré-agir
  • Réagir statique
  • Gatsby

Pour obtenir la meilleure vitesse, vous pouvez ensuite déployer votre site Web statique à l'aide d'un fournisseur de CDN tel que Netlify.

Emballer

Si vous utilisez votre application dans Lighthouse avec une architecture comme celle-ci, vous devriez obtenir un score bien meilleur. Vous remarquerez également la rapidité de votre application et son excellente expérience utilisateur.

Les applications Web progressives sont une proposition fantastique qui est plus simple à créer et à déployer que les applications natives, tout en étant capable de fournir une grande partie de l'expérience que les utilisateurs aiment et attendent des applications natives.

Le support que Safari offrira en termes de PWA suscite encore des interrogations, mais ils travaillent sur une gamme d'éléments et les techniciens de maintenance seront disponibles dans iOS 11.3, ce qui semble prometteur.

Si vous voulez faire un effort supplémentaire, un certain nombre d'API supplémentaires sont en cours d'implémentation (nous devons à nouveau voir ce que Safari implémentera) qui peuvent offrir des expériences encore meilleures à vos utilisateurs, notamment:

  • API de notifications push
  • API Paiements Web
  • API des informations d'identification

Même si j'adore React Native et que ce sera toujours la meilleure option pour l'expérience utilisateur, j'investis personnellement beaucoup de temps et d'énergie dans PWA, car je pense qu'ils ont un avenir très prometteur!

Je m'appelle Dave Hudson, je suis un pédant UX pour le développement de produits qui dirige des équipes de développement et écrit du code.
Je consulte sous Applification Ltd et je suis disponible pour tout ce qui concerne Réactif, agile et développement de produits!