Responsive Web Design et Progressive Web App (PWA) : les différences

Publié: 2020-08-03

Table des matières

Ces deux approches étant si similaires dans leur apparence et leurs performances, vous devez vous demander pourquoi il n'y a pas de comparaison plus détaillée entre les deux approches populaires du développement Web : la conception Web réactive et l'application Web progressive. Eh bien, c'est ça . Dans cet article, nous comparerons la conception Web réactive avec les applications Web progressives et découvrirons en quoi elles diffèrent vraiment les unes des autres.

Site Web adaptatif

Ce que c'est

La conception Web réactive (RWD) est une approche du développement Web décrite pour la première fois par Ethan Marcotte en 2010, cinq ans avant la conception de Progressive Web App.

Comment ça fonctionne

Fondamentalement, la philosophie de la conception Web réactive est que la conception et le développement doivent être réalisés dans le but de répondre à l'appareil de l'utilisateur, ce qui signifie répondre au comportement, à la taille, à la plate-forme et à l'orientation de l'appareil utilisé. Ceci est réalisé grâce à l'utilisation de grilles fluides, d'images flexibles et de requêtes média CSS :

Grilles fluides, images flexibles et media queries sont les trois ingrédients techniques du responsive web design…

Ethan Marcotte, conception de sites Web réactifs

Grilles fluides

Les sites Web réactifs conçus avec des grilles fluides peuvent mieux gérer les différentes tailles d'écran sur le marché car, au lieu de définir des dimensions basées sur les pixels, la grille fluide adopte un nouveau calcul basé sur un pourcentage.

Images flexibles

Les images sur le Web ne sont pas naturellement fluides, mais avec certaines configurations (propriété width définie sur 100% et propriété height définie sur auto ), n'importe quelle image peut être rendue réactive sur tous les appareils.

Requêtes média CSS

Bien qu'une page Web réactive avec des images flexibles et des grilles fluides soit techniquement réactive, elle n'est pas aussi belle qu'elle peut l'être. C'est là que les requêtes média CSS entrent en jeu car elles sont utilisées pour créer une expérience encore meilleure, adaptée à différents appareils. Ces expériences personnalisées sont souvent introduites par l'ajout de points d'arrêt qui prennent effet à des tailles d'écran spécifiques.

Page Web avec et sans balise meta viewport
Comment une simple balise meta viewport rend la page réactive
Source : w3schools.com

Dans l'ensemble, la conception Web réactive a rendu le Web d'aujourd'hui beaucoup plus accessible, car l'approche élimine les besoins en phases de développement supplémentaires qui étaient auparavant nécessaires pour s'adapter aux différentes tailles d'écran du marché. Ou, selon les mots de son créateur, cette approche du développement web permet enfin de « concevoir pour le flux et le reflux des choses ».

Exemples

Les sites Web réactifs sont monnaie courante de nos jours, et presque tous les sites Web que vous rencontrez sont quelque peu réactifs dans leur nature.

Exemple réactif GitHub
GitHub est un site Web réactif
[Source : Exemples puissants de conception Web réactive]

Applications Web progressives

Ce que c'est

Inventée pour la première fois par Alex Russel en 2015, P rogressive W eb App est la prochaine évolution naturelle du Web en raison de ses nombreux avantages par rapport au site Web réactif typique. La partie « progressive », selon Pete LePage – Google Developer Advocate, peut s'expliquer comme « au fur et à mesure que l'utilisateur construit une relation avec l'application au fil du temps, celle-ci devient de plus en plus puissante ».

Pour le dire en termes simples, un PWA est votre site Web de type application avec (presque) toutes les fonctionnalités que vous pouvez attendre d'une application mobile native , y compris les notifications push, les capacités hors ligne, etc. Et pour cette raison, toute l'expérience est un pas en avant par rapport à son homologue de site Web réactif, car PWA peut conserver tous les avantages supposés d'une plate-forme Web.

 Article connexe : Qu'est-ce qu'une application Web progressive ?

Comment ça fonctionne

Il est en fait assez facile de résumer les composants de base d'une PWA. Fondamentalement, afin de rendre possibles toutes les fonctionnalités progressives susmentionnées, voici les exigences :

Manifeste de l'application Web

Le manifeste de l'application Web est un fichier JSON qui fournit les métadonnées nécessaires au processus d'installation de votre PWA et détermine comment votre PWA se présente sur l'écran d'accueil de l'utilisateur.

Travailleurs des services

Universellement considérés comme le composant fondamental qui rend possibles toutes les fonctionnalités progressives de PWA, les service workers s'exécutent indépendamment du navigateur et sur un thread différent du JavaScript principal.

Contextes sécurisés

En tant que nouvelle norme du Web, il est nécessaire qu'une PWA soit coupée sur un protocole sécurisé, HTTPS. Cela garantit une communication sécurisée entre l'utilisateur et le serveur et en retour, garantissant une expérience sans risque.

Exemples

Comme les PWA ne se comportent pas différemment des applications mobiles natives, vous avez peut-être déjà visité un site PWA sans le savoir. Pensez aux grands sites ressemblant à des applications comme Instagram et Pinterest, ils sont tous alimentés par PWA.

PWA Instagram
Le site Instagram est un PWA
 Lecture recommandée : 12 meilleurs exemples d'applications Web progressives en 2020

Où ils se chevauchent

Une expérience similaire avec des fonctionnalités modernes

Si tout a du sens pour vous jusqu'à présent, vous devriez voir que la conception Web réactive (RWD) et la PWA se chevauchent beaucoup en ce qui concerne l'expérience utilisateur. Techniquement, PWA est réactif, car l'approche est conçue pour être adaptée à l'affichage sur tous les appareils, avec une touche moderne pour activer davantage de fonctionnalités de type application.

Et comme ce sont deux approches du développement Web, elles partagent presque tous les mêmes avantages du Web, notamment :

  • Une URL, une base de code pour toutes les plateformes
  • Sécurité renforcée avec HTTPS
  • Meilleure découverte et toujours à jour

Où ils diffèrent

C'est là que les choses deviennent intéressantes, car ces deux approches du développement Web, bien que similaires en apparence, diffèrent beaucoup dans leurs impacts réels.

En termes de fonctionnalités

Un PWA, par définition, contient plus de fonctionnalités que votre site Web réactif typique. En tirant parti des avancées récentes des technologies Web, c'est-à-dire des service workers et du manifeste d'application Web, PWA peut fournir des fonctionnalités qui étaient auparavant exclusives aux applications mobiles natives telles que :

Ajouter à l'écran d'accueil

Avec des techniciens de service enregistrés et un manifeste d'application Web, PWA peut être installé sur chaque appareil doté d'un navigateur compatible.

PWA installable
Installation de PWA sur tous les appareils avec Magento PWA de SimiCart

>> En savoir plus : Créez votre première PWA

Notifications push

Grâce aux service workers, vous pouvez envoyer des notifications et les afficher sur les appareils des utilisateurs, comme le ferait une application native. Il s'agit d'une fonctionnalité relativement récente du Web qui tire parti de l'API Push, de l'API Notifications et du protocole Web Push ; et dans un avenir proche, cette fonctionnalité ne fera que s'améliorer grâce à l'avènement des déclencheurs de notifications et de l'API Badging.

Capacités hors ligne

Grâce à l'aide du proxy réseau programmable intégré au navigateur, à savoir les service workers , PWA peut mettre en cache et servir de manière proactive du contenu hors ligne sans avoir à s'appuyer sur des mécanismes de mise en cache obsolètes tels que le cache HTTP.

Remarques : Les sites Web réactifs peuvent toujours bénéficier de toutes les API existantes du Web pour offrir également une expérience utilisateur optimale. C'est juste que vous n'obtiendrez pas toutes les fonctionnalités qui dépendent des travailleurs de service.

 Lecture recommandée : Progressive Web App (PWA) et accès au matériel

En termes de performances

Étant donné que les sites Web réactifs sont toujours votre site Web typique retenu par tous les inconvénients associés au mécanisme de mise en cache HTTP actuel, il est raisonnable de s'attendre à de meilleures performances de PWA car il utilise un mécanisme de mise en cache plus récent et plus axé sur les performances appelé service workers.

Mécanisme de mise en cache plus rapide

Avec les techniciens de service enregistrés, vous pouvez contrôler exactement ce qui est mis en cache et offrir ainsi de meilleures expériences aux visiteurs qui reviennent.

L'impact sur les performances réelles des travailleurs des services n'est pas quelque chose qui n'a pas été soigneusement observé non plus. En utilisant le temps de la première peinture comme métrique pour mesurer la première expérience de l'utilisateur avec un site Web, Google lui-même a mené une étude observant les performances de l'application Web Google I/O avec un groupe contrôlé (où un technicien de service contrôle l'application Web) et un groupe pris en charge (où le service fonctionne est pris en charge par le navigateur utilisé mais il ne contrôle pas encore l'application Web).

Histogramme - Distribution du premier temps de peinture (Desktop)
Les techniciens de service ont fait leur part pour réduire le temps de firstpaint . [Source : Philippe Walton]

Les résultats ont été particulièrement impressionnants sur les ordinateurs de bureau, car nous pouvons voir ici que les techniciens de maintenance ont fait leur part pour réduire le temps de première firstpaint d'origine (912 ms) à seulement 583 ms . C'est aussi proche d'une expérience instantanée que possible.

Les choses sont cependant un peu moins impressionnantes sur les appareils mobiles :

Histogramme - Distribution du premier temps de peinture (Mobile)
Augmentation significative du temps de firstpaint sur mobile [Source : Philip Walton]

Ici, nous pouvons voir que la fin du groupe contrôlé ressemble toujours un peu au groupe pris en charge. Cela est dû en grande partie au fait que sur mobile, les threads de travail de service ne sont pas aussi optimisés et ont besoin de plus de temps pour démarrer par rapport au bureau.

Dans l'ensemble, l'augmentation des performances obtenue avec les services workers, ou en d'autres termes, avec les PWA, est tout simplement phénoménale. Il reste, bien sûr, encore du travail à faire du côté des travailleurs des services mobiles ; mais nous estimons que dans l'ensemble, c'est encore une étape marginale vers ce qu'était autrefois le Web, et un pas dans la bonne direction.

En termes de sécurité

HTTPS—La ligne séparant

Bien qu'un site Web réactif typique puisse être tout aussi sécurisé qu'un PWA, il n'est pas nécessaire que les sites Web réactifs utilisent des protocoles de communication sécurisés. C'est le cas contraire avec les sites Web alimentés par PWA, car Google, fondateur de PWA, exige que toutes les communications entre le serveur et le client dans une PWA soient cryptées via l'utilisation de HTTPS.

La plupart des fonctionnalités liées à une PWA telles que la géolocalisation et même les service workers ne sont disponibles qu'une fois l'application chargée en HTTPS.

Documents Web MDN, applications Web progressives (PWA)
 Article connexe : Avez-vous besoin de HTTPS ?

Conclusion

L'amélioration des performances susmentionnée obtenue avec les travailleurs de service, combinée à des fonctionnalités supplémentaires de type application telles que les notifications push, l'ajout à l'écran d'accueil (et dans un avenir proche, le géorepérage et la synchronisation périodique), s'avèrent tous faire de PWA le candidat idéal pour être le prochain évolution du Web. À l'heure actuelle, le mouvement PWA est déjà largement encouragé par presque tous les grands noms, y compris Microsoft avec leur poussée d'adoption de PWA dans Windows 10. Il ne faudra pas longtemps avant que nous voyions un avenir plein d'applications Web progressives, comme celui que Steve Jobs envisageait :

Le moteur Safari complet se trouve à l'intérieur de l'iPhone. Et ainsi, vous pouvez écrire des applications Web 2.0 et Ajax étonnantes qui ressemblent exactement et se comportent exactement comme des applications sur l'iPhone. Et ces applications peuvent parfaitement s'intégrer aux services iPhone. Ils peuvent passer un appel, ils peuvent envoyer un e-mail, ils peuvent rechercher un emplacement sur Google Maps.

Steve Jobs, 2007