Vous êtes ici : WEBDESIGNMOTEUR » Road-blog » Progressive Web Apps : quand les Apps natives orienté mobile s’affranchissent grâce au Web

Progressive Web Apps : quand les Apps natives orienté mobile s’affranchissent grâce au Web


Les acteurs des navigateurs, Apple (iOS / Safari), Google (Android / Chrome), Microsoft (Windows / Edge), Mozilla (Firefox), sont tous en position sur la grille de départ des Progressive Web Apps. A nous de participer à cette nouvelle course qui va permettre de réunir les Utilisateurs des Apps et du Web. Regardons ensemble maintenant sous le capot les moteurs des PWA pour se préparer ou découvrir ce qui se prépare.



Web vs App ?

Commençons par présenter l’application native. Une application native est développée spécifiquement pour une plateforme (Android, iOS, Linux, Windows), avec un langage spécifique (Java ou Kotlin, Objective-C ou Swift, PHP, C# & XAML) est installable et distribuée à partir d’un magasin d’applications.

A ce qu’il parait, les mobinautes passent 92% de leur temps sur les Apps et seulement 8% sur les navigateurs… Grâce à l’installation en local, le fonctionnement déconnecté (offline), le plein écran ou encore la visibilité dans les stores, les Apps sont très utilisées.

À l’origine, le Web est organisé en pages de documentation. Un très grand nombre de sites obéissent encore à ce paradigme même les sites d’informations. On a un lien, une page web composé de balises HTML, du texte de contenu éditorial et des images pour illustrer.

Depuis le début des années 2000, de nombreux sites se sont enrichis d’interactions via JavaScript pour offrir à leurs visiteurs des usages d’interaction entre utilisateur interprété via le navigateur.

En 2017, en France, près de 80% des détenteurs de smartphones avouent télécharger moins d’une application par mois. L’utilisateur passe la plus grande partie de son temps sur les applications tels que Facebook, Messenger ou Snapchat. En clair, les gens utilise des Apps native orienté mobile pour échanger entre eux, discuter et partager des contenus.

Pour le créateur d’App, le challenge de se démarquer des plus de deux millions d’applications présentes sur l’App Store iOS ou le Google Play Store, sans oublier être présent sur le Windows Store, est ardu.

Les applications natives ne peuvent être utilisées que sur la plateforme pour laquelle elles ont été créées. On ne peut pas faire tourner une application iOS sur un Mac que sur une appareil Android. De plus les applications natives n’avantagent que ceux qui les installent.

Le système des App Store, aussi satisfaisant qu’il soit, atteint ses limites. L’utilisateur fait face à une offre pléthorique d’Apps.

Comscore a publié il y a quelques temps un rapport qui indique que la plupart des utilisateurs de smartphones téléchargent zéro application par mois…

Selon Recode, l’abandon des applications est un problème depuis les premiers jours de l’App Store et le pourcentage de personnes qui arrêtent d’utiliser des applications continue de croître.

Depuis novembre 2016 les sites Web sont d’avantage consultés en situation de mobilité depuis un Smartphone ou une tablette que depuis un PC au bureau.

Web Design, User Interface (UI), expérience utilisateur (UX), Web Performance, accessibilité, autant d’éléments à prendre en compte afin de rendre l’expérience mobile convaincante. C’est au site web de s’adapter à la multitude d’appareil. Et c’est au Web designer de proposer un solution Responsive.

Web vs App - 2017 - by WEBDESIGNMOTEUR

Web vs App – 2017 – by WEBDESIGNMOTEUR

solution actuelle ?

Actuellement on a donc plusieurs solutions à disposition pour servir un message et du contenu :

  • Application native orienté mobile (iOS, Android, Windows) à installer à partir du ‘App store’
    proposé par Google, Apple ou Microsoft. (Développement logiciel)
  • Site Web prévu pour Desktop et adapté Mobile (Web design) à déployer sur serveur Web (Apache via distribution Linux) et avec alternative AMP (Accelerated Mobile Pages)
  • Site Web conçu pour Mobile et prévu pour Desktop (Mobile First) à déployer sur serveur Web (Apache via distribution Linux)
  • Site Web conçu pour Mobile et conçu pour Desktop (Responsive Web design) à déployer sur serveur Web (Apache via distribution Linux)

Là on se rend bien compte des différences entre App native et site Web.

Entre les langages de développement très différent et les matériels requis pour faire fonctionner la solution, c’est deux produits différent et complémentaire. Le truc en commun pourtant est le mobile.

Développer une Progressive Web App s’inscrit dans une démarche de Mobile First.

Les PWA et l’approche Mobile First ont un socle commun : l’amélioration progressive.

L’idée est de proposer aux utilisateurs une expérience mobile complète quels que soient le navigateur utilisé et l’état de la connexion. Pour cela, il faut séparer le fond (le contenu) de la forme (la présentation et les fonctionnalités) afin de se concentrer sur l’essentiel. Ensuite, on ajoute progressivement des nouvelles fonctionnalités.

Web & App ?

Site vitrine, site d’actualités, blog, site e-commerce… Tous les éditeurs de sites Web cherchent la même chose : davantage de pages vues et davantage d’engagement (interactions/conversion) des utilisateurs et donc au final retour sur investissement et revenu gagné.

Site Web - 2017 - by WEBDESIGNMOTEUR

Site Web – 2017 – by WEBDESIGNMOTEUR

Apps mobile quelles que soit leur proposition sont basé sur un modèle économique soit paiement à l’achat de l’App ou in App pour accéder à d’autre contenu.

Mais l’avantage des Apps native sur les site web est leur accès au composants matériels du téléphone et à son système d’exploitation pour échanger. Le code de l’App peut utiliser les fonctions « localisation », envoyer des notifications, ou avoir accès l’Appareil photo ou bien profite de l’accélération matérielle pour l’affichage et permettre son fonctionnement. Ou mieux encore, l’App est disponible hors ligne (sans Internet), hors réseau (3G/4G) et quand on veut.

Sauf que, ces Apps doivent être installées depuis un App store. Cela consomme de la place sur l’espace de stockage du Smartphone.

Coté Dev (back-end), il faut développer et maintenir plusieurs versions pour supporter les différents systèmes d’exploitation (en particulier iOS et Android ou Windows).

App Mobile - 2017 - by WEBDESIGNMOTEUR

App Mobile – 2017 – by WEBDESIGNMOTEUR

Le contenu des Apps n’est ni public ni référencé sur les moteurs de recherche. Il faut donc un budget martketing/communication/publicité à prévoir pour faire connaitre l’App.

Rappelons qu’un serveur web ne prend pas l’initiative d’un échange avec le navigateur de l’internaute. Quand bien même il aurait un contenu frais ou le résultat d’une opération à lui transmettre, il doit attendre d’être sollicité par le biais d’une requête (asynchrone ou non), et c’est en y répondant qu’il transmet ses informations.

Pour simuler un échange en temps réel les codes embarqués dans le navigateur client sont alors obligés d’interroger périodiquement le serveur. Ces demandes fréquentes impliquent toutes la mise en place d’une nouvelle connexion, l’échange, l’interprétation des données s’il y en a, puis la fermeture de la connexion.

Web + App ?

En 2014, certains développeurs, dont Jack Archibald, réfléchissent à une nouvelle API qui s’ajouterait aux autres composants déjà présents dans les navigateurs : les Service Workers.

Pour rappel, le terme API (Application Programming Interface) est un ensemble normalisé de classes, de méthodes ou de fonctions, afin qu’un logiciel offre des services à d’autres logiciels.

Les PWA exploitent plusieurs technologies clés et reposent essentiellement sur une combinaison de l’architecture « application shell » et des service workers.

Service Workers ?

Les Service Workers jouent essentiellement le rôle de serveurs proxy placés entre une application web, et le navigateur ou le réseau lorsque disponible.

Un proxy est un composant logiciel informatique qui joue le rôle d’intermédiaire en se plaçant entre deux hôtes pour faciliter ou surveiller leurs échanges.

Les Service Workers sont destinés (entre autres choses) à permettre la création d’expériences de navigation déconnectée efficaces, en interceptant les requêtes réseau et en effectuant des actions appropriées selon que le réseau est disponible et que des ressources mises à jour sont à disposition sur le serveur. Ils permettront aussi d’accéder aux APIs de notifications du serveur (push) et de synchronisation en arrière-plan.

Un Service Workers est un worker événementiel enregistré auprès d’une origine et d’un chemin. Il prend la forme d’un fichier JavaScript qui peut contrôler la page ou le site web auquel il est associé, en interceptant et en modifiant la navigation et les requêtes de ressources, et en mettant en cache les ressources selon une granularité très fine pour vous donner une maîtrise complète de la manière dont doit se comporter votre application dans certaines situations.

Un Service Workers fonctionne dans le contexte d’un worker : il n’a donc pas d’accès au DOM (Document Object Model de la page web), et s’exécute dans une tâche différente de celle du script principal de votre application, ainsi il est non-bloquant. Il est conçu pour être totalement asynchrone.

Les Service Workers fonctionnent uniquement sur HTTPS, pour des raisons évidentes de sécurité.

Une raison de plus de passer au tout HTTPS !


HTTPS : Découverte du moteur HyperText Transfer Protocol Secure (TCP/IP & #SSL/#TLS)


A quoi sert les Service Workers ?

Selon developer.mozilla.org/

Les service workers sont aussi destinés à être utilisés pour des choses telles que :

  • Synchronisation de données en arrière-plan
  • Répondre à des requêtes de ressource provenant d’autres origines
  • Recevoir des mises à jour centralisées de données coûteuses à calculer telles que la géolocalisation ou le gyroscope, afin que de nombreuses pages puissent bénéficier du même ensemble de données
  • Compilation côté client et gestion des dépendances de CoffeeScript, less, modules CJS/AMD, etc. pour des besoins de développement
  • Branchements pour des services en arrière-plan
  • Personnalisation de gabarit en fonction de certains schémas d’URL
  • Amélioration des performances, par exemple en pré-chargeant des ressources dont l’utilisateur aura probablement besoin par la suite, comme de nouvelles images lors de la consultation d’un album photo.

À l’avenir, les service workers seront capables de réaliser nombre d’autres tâches utiles au sein d’une plate-forme web, ce qui les rapprochera de la viabilité des applications natives. Il est intéressant de noter que d’autres spécifications peuvent ou commencent à faire usage du contexte des service workers, par exemple :

  • Synchronisation en arrière-plan : démarrer un service worker même lorsqu’aucun utilisateur est sur le site, afin de mettre à jour les caches, etc.
  • Réagir à des messages de push : démarrer un service worker pour envoyer aux utilisateurs un message leur signalant qu’un nouveau contenu est disponible.
  • Réagir à une date particulière
  • Enregistrer une géo-localisation

Un Service Worker est concrètement un script chargé parallèlement aux scripts de votre page et qui va s’exécuter en dehors du contexte de votre page web. Bien que le Service Worker n’ait pas accès au DOM ou aux interactions avec l’utilisateur, il va pouvoir communiquer avec vos scripts via l’API postMessage. Il se place en proxy de votre Web App, interceptant toutes les requêtes serveur et propose par exemple d’y répondre avec un cache ou en récupérant des données du LocalStorage ou d’IndexedDB. Il rend donc votre application disponible offline.

En résumé : seules les nouvelles données sont chargées depuis le serveur Web. Les requêtes sont gérées par le Service Worker, l’interface du site web est réutilisée depuis le cache du navigateur web. Cette avancée permet éventuellement le fonctionnement de la Web App en offline, donc sans Internet.

Lorsque l’on perd la connexion Internet, il n’est plus possible de naviguer sur le site web, même les pages que l’on avait visitées précédemment ne sont plus accessibles. De plus, même avec des optimisations en appliquant les principes de la Web Performance, souvent le chargement de certaines pages Web reste longuet, particulièrement lorsque la quantité de données à afficher est importante.

On a donc un site Web disponible sans avoir accès Internet après avoir « installé » notre Web App via le navigateur en l’épinglant sur l’écran d’accueil de notre mobile (iOS, Android, Windows) ou notre interface du navigateur sur Desktop (Windows).

Jusqu’à maintenant, des solutions partielles existaient déjà, mais elles étaient spécifiques à chaque OS tels que iOS, Android, Windows.

La création de ces applications native ont un coût généralement considérable et ne sont pas aussi facilement accessible qu’un site Web puisqu’il faut d’abord que l’utilisateur installe l’application pour pouvoir profiter de toutes les fonctionnalités telles qu’un accès à certaines informations hors connexion, des notifications push, des temps de chargement instantané.

Web architecture application shell

En ce qui concerne l’architecture application shell, il s’agit d’une architecture d’application web moderne qui tire parti d’un service worker pour mettre en cache la « coque » de votre application hors ligne et remplir son contenu en utilisant JS, quand la coque est chargée. La coque (shell en anglais) d’une application fait allusion au code HTML, CSS et JavaScript minimal qui alimente l’interface utilisateur.

Web App Manifest

Aujourd’hui il existe une solution standard, simple, qui permet d’uniformiser les installations depuis n’importe quel OS via le Web App Manifest.

Cette synthèse de fichiers de description des Web Apps permet de décrire l’application (incluant toutes ses caractéristiques) dans un fichier JSON (JavaScript Object Notation). Ce manifeste est un simple fichier complet regroupant les informations essentielles proposées à l’utilisateur tel que orientation d’affichage (portrait ou paysage), thème, couleur, icônes, adresse (URL), …

The web app manifest is a W3C specification defining a JSON-based manifest to provide developers a centralized place to put metadata associated with a web application including:

– The name of the web application
– Links to the web app icons or image objects
– The preferred URL to launch or open the web app
– The web app configuration data for a number of characteristics
– Declaration for default orientation of the web app
– Enables to set the display mode e.g. full screen

Les Web Apps profitent d’avoir des adresses (URL pour Uniform Resource Locator) pour exister sur un serveur Web ! Pratique pour partager le lien de la Web App directement.

Revenons aux PWA pour l’utilisateur & l’éditeur maintenant que l’on compris ces éléments moteurs.

Progressive Web App

Progressive Web Apps - 2017 - by WEBDESIGNMOTEUR

Progressive Web Apps – 2017 – by WEBDESIGNMOTEUR

In 2015, designer Frances Berriman and engineer Alex Russell coined the term ‘Progressive Web Apps’ to describe apps taking advantage of new features supported by modern browsers, including service workers and web app manifests, that let users upgrade web apps to progressive web applications in their native operating system (OS).

– Progressive – Work for every user, regardless of browser choice because they’re built with progressive enhancement as a core tenet.
– Responsive – Fit any form factor: desktop, mobile, tablet, or forms yet to emerge.
– Connectivity independent – Service workers allow work offline, or on low quality networks.
– App-like – Feel like an app to the user with app-style interactions and navigation.
– Fresh – Always up-to-date thanks to the service worker update process.
– Safe – Served via HTTPS to prevent snooping and ensure content hasn’t been tampered with.
– Discoverable – Are identifiable as “applications” thanks to W3C manifests[6] and service worker registration scope allowing search engines to find them.
– Re-engageable – Make re-engagement easy through features like push notifications.
– Installable – Allow users to “keep” apps they find most useful on their home screen without the hassle of an app store.
Linkable – Easily shared via a URL and do not require complex installation.

Une Progressive Web App est une application hybride basée sur des API web ayant la même apparence qu’une application native.

Les Progressive Web App peuvent être téléchargées à partir d’une adresse web et s’ajoutera à votre mobile comme une nouvelle application.

Il est donc possible de donner aux sites web des fonctionnalités proches de celles auxquelles les utilisateurs d’applications sont habitués.

Pour prétendre être une Progressive Web App, les sites doivent remplir un certain nombre de conditions :

  • Progressif : Fonctionnent pour tous les utilisateurs, quel que soit leur navigateur, parce qu’ils sont construits avec l’amélioration progressive comme principe de base.
  • Responsifs : Fonctionnent sur tous les supports : ordinateur, mobile, tablette, ou d’autres supports à venir.
  • Indépendants de la connexion : Les service workers permettent de travailler sans connexion ou sur des réseaux de mauvaise qualité.
  • Ressemblent à une application : Se comportent comme une application pour l’utilisateur, avec des interactions et une navigation similaires à celles des applications.
  • À jour : Toujours à jour grâce au processus du service worker de mise à jour.
  • Sûres : Utilisent HTTPS pour assurer que les données ne sont ni interceptées ni modifiées.
  • Découvrables : Identifiables comme une « application » grâce aux manifestes W3C et au service worker d’enregistrement qui permet aux moteurs de recherche de les trouver.
  • Ré-engageants : Facilitent le ré-engagement avec des fonctionnalités comme les notifications push.
  • Installables : Permettent aux utilisateurs de « garder » sur leur écran d’accueil les applications qu’ils trouvent les plus utiles, sans passer par un store d’application.
  • Partageables : Faciles à partager par une URL et sans installation complexe.

Si le site remplit tous ces critères, alors le navigateur web, proposera aux utilisateurs d’installer l’application. Elle sera alors présente sur l’écran d’accueil de l’appareil de l’utilisateur.

C’est donc une solution intermédiaire qui utilise les techniques du Web pour afficher les informations (HTML, CSS, JavaScript) mais qui utilise les techniques des applications natives pour charger rapidement les données et les rendre disponibles hors connexion.

Les PWA se consultent comme des sites web, depuis une URL sécurisée donc elles ne prennent pas de place dans le téléphone.

les Progressive Web Apps sont conçues pour contourner cet épuisement du téléchargement d’applications. Les gens découvrent les applications naturellement via des liens sur les réseaux sociaux ou en surfant sur le web.

Au premier abord il est aussi difficile de distinguer l’interface d’un site web ou d’un App d’une PWA pourtant son expérience en est grandement améliorée.

Leur architecture donne un premier avantage aux Progressive Web Apps par rapport à un site web « standard ». la Web App charge beaucoup plus vite. Puisque après le premier affichage d’une page, ces éléments essentiel sont enregistré. Seul le contenu est obtenu et envoyé pour une remplir une nouvelle page. Le navigateur conserve la structure et refresh le contenu.

Attention, la PWA n’est pas adapté à tout projet.

Divers facteurs sont à prendre en compte : le secteur d’activité, le type d’utilisation, les besoins en développement et en ressources…

Pour prendre de bonnes décisions, il faut aborder l’ensemble de chaque projet :

Spécifications fonctionnelles et technique, analyse de la cible (en âge, Catégories Socio-Professionnelles ou Professions et Catégories Socioprofessionnelles, emplacement géographique, culture…), niveau d’information et de compétence des équipes, plate-forme de développement existante ou acquise, architecture serveur, pérennité du développement, chiffre d’affaire espéré, stratégie de déploiement et de maintenance…

Mais dès maintenant on a un nouveau support qui permet de réunir les Utilisateur et leurs appareils (Apple, Google, Microsoft, Web) en situation de mobilité ou au bureau.

En juillet 2017, avec 2,6 millions de visiteurs par jour dont 1,6 millions uniquement sur mobile, le célèbre média L’Équipe a bien compris l’enjeu des Progressive Web Apps et à l’image des derniers sites mobiles du Financial Times et du Washington post, L’Équipe est le premier média français à avoir déployé une Progressive Web App.

Lancôme a redonné un coup de boost à son m-commerce et a fait le choix d’une PWA pour son site marchand.

Les clients de Lancôme rencontraient des obstacles pendant leur navigation sur mobile, pourtant devenus majoritaires, donc les taux de transformation étaient décevants. De plus, le client ponctuel était réticent vis-à-vis du téléchargement d’application native (obligation de quitter la navigation web pour passer par les App stores).

Les équipes de la marque Lancôme ont fait le choix d’une Progressive Web App afin d’améliorer l’expérience d’achat et ainsi redynamiser les ventes sur mobile.

Aux USA, le Washington Post a développé une Progressive Web App qui s’installe en arrière-plan pendant que les personnes regardent ses pages AMP5 dans les résultats de recherche de Google. Le Washington Post a vu une augmentation de 12% de visites en provenance des résultats de recherche de Google grâce à AMP.

Il reste encore à voir comment la Progressive Web App du Washington Post se comportera – ils n’ont lancé la version beta qu’en Mai – mais les gains en performance sont impressionnants. Ils sont passés d’articles qui mettaient 8 secondes à se charger en 2013 à 80 millisecondes dans la Progressive Web App.

So PWA now!

Les PWA reposent sur un ensemble de choses sur lesquelles reposent déjà les Web Apps :

Responsive Web Design, Web Services & Web Sockets, API fournies par les navigateurs.

…le Responsive Web Design (RWD) pour adapter les interfaces à tous les écrans

Le Responsive Web design est une approche de conception Web qui vise à l’élaboration de sites offrant une expérience de lecture et de navigation optimales pour l’utilisateur quelle que soit sa gamme d’appareil (téléphones mobiles, tablettes, liseuses, moniteurs d’ordinateur de bureau).

Une expérience utilisateur ‘Responsive’ réussie implique un minimum de redimensionnement (zoom), de recadrage, et de défilements multidirectionnels de pages.

Le terme de ‘Responsive Web design’ a été introduit par Ethan Marcotte dans un article de A List Apart publié en mai 2010.

Il décrira par la suite sa théorie et pratique du RWD dans son ouvrage « Responsive Web Design » publié en 2011, au sujet des grilles flexibles en pourcentages, images fluides et CSS3 Media Queries.

…des ‘Web Services’ et ‘Web Sockets’ via serveurs et permettant d’accéder à des informations ou de réaliser des actions par le biais d’actions web

Un ‘Web Services’ est un composant logiciel identifié par une URI (Uniform Resource Identifier), dont les interfaces publiques sont définies et appelées en XML (Extensible Markup Language). Les services Web peuvent interagir entre eux d’une manière prescrite par leurs définitions, en utilisant des messages XML portés par les protocoles Internet.

Un service Web est tout simplement un programme accessible au moyen d’Internet, qui utilise un système de messagerie standard XML, et n’est lié à aucun système d’exploitation ou langage de programmation !

Par exemple, WordPress utilise XML-RPC depuis longtemps et REST API depuis 2016.

XML-RPC est un protocole simple utilisant XML pour effectuer des messages RPC. Les requêtes sont écrites en XML et envoyées via HTTP POST. Les requêtes sont intégrées dans le corps de la réponse HTTP. XML-RPC est indépendant de la plate-forme, ce qui lui permet de communiquer avec diverses applications.

REST (Representational State Transfer) est une architecture de services Web. Élaborée en l’an 2000 par Roy Fiedling, l’un des créateurs du protocole HTTP, du serveur Apache HTTPd et d’autres travaux fondamentaux, REST est une manière de construire une application pour les systèmes distribués comme le World Wide Web.

Le serveur web ne peut pas envoyer de données au client (ici le navigateur) si le client ne fait pas une requête au préalable. Du coup, pour savoir si il y a quelque chose de nouveau, le navigateur doit régulièrement faire des requêtes au serveur.

Les Web Sockets ont été créés pour répondre à ces besoins : elles permettent d’ouvrir une connexion permanente entre le navigateur et le serveur. Ainsi, chaque requête est plus rapide, et plus légère. En prime, le serveur peut envoyer des requêtes au navigateur pour le prévenir qu’il y a du nouveau.

Dans tous les cas, il vous faudra un serveur qui supporte les Web Sockets pour l’utiliser. En Javascript, c’est NodeJS. Quoi qu’il en soit, il faut un logiciel sur serveur qui gère les entrées sortie (In/Out) de manière non bloquante, car il y a de nombreuses connexions ouvertes en simultanées, si on veut que ça soit performant.

La spécification permettant d’utiliser les WebSockets est développée par le W3C, tandis que le protocole de communication est standardisé par l’IETF.

Pour établir une connexion WebSocket, une requête de type « upgrade » doit être envoyée par le client, afin de demander la mise à jour de la connexion TCP/HTTP actuelle vers le mode WebSocket.

Puis le serveur renvoie une réponse. Cet échange initial est nommé « handshake ». A partir de là, la communication entre serveur et client se fait par le protocole WebSocket.

Les développeurs n’ont pas attendu les WebSockets pour concevoir des pages dynamiques. Les solutions actuelles se basent sur des iframes, qui permettent de créer des « pages dans la page », ou sur AJAX et l’objet Javascript XMLHttpRequest.

AJAX est un acronyme qui signifie Asynchronous Javascript and XML. C’est une architecture informatique qui permet la conception d’applications Internet dynamiques. Une application dynamique est capable de travailler « derrière » la fenêtre du navigateur. Elle est capable de mettre à jour du contenu, déclencher des sauvegardes, etc., sans perturber la navigation de l’internaute.

L’objet XMLHttpRequest est l’élément Javascript en charge de ces échanges asynchrones.

Les WebSockets ne sont pas là pour supplanter Ajax. Cette nouvelle API répond simplement à un besoin qui n’était jusqu’à présent pas adressé.

Le WebSocket permet donc d’ouvrir un canal de communication entre le navigateur de l’internaute et le serveur web. Le protocole utilisé est TCP (pour Transmission Control Protocol). On parle donc de mode connecté, puisque le protocole TCP impose aux deux parties de se présenter l’une à l’autre avant d’échanger les premières informations (c’est ce qu’on appelle la « poignée de main »). Une fois la connexion établie le navigateur comme le serveur peuvent envoyer des informations. De la même manière la fin de la connexion est initiée par l’une ou l’autre des parties.

schema TCP/IP - HTTP - by DESIGNMOTEUR START-UP -

schema TCP/IP – HTTP – by DESIGNMOTEUR START-UP –

…certaines API fournies par les navigateurs, qui permettent de tirer pleinement partie du contexte tel que selon l’appareil : audio, vidéo, accélération, géolocalisation, transcription, vibreur, appareil photo, etc.

On ajoute deux composants techniques récents : Service Workers & Web Workers.

Aussi et surtout, on a maintenant les nouvelles routes ouvertes via le protocole HTTP/2 avec HTTPS natif disponible !


A la découverte du moteur du serveur web HTTP/2 (#SPDY #SSL #TLS #SEO) & Debrief Web Perf


amélioration progressive

L’application doit pouvoir se charger de manière rapide, quel que soit l’état du réseau. La disponibilité du réseau devient alors une amélioration progressive :

  • en très haut débit : l’application web affiche une synchronisation totale et instantanée avec le serveur
  • en navigation bas débit : la mise-à-jour des ressources externes ne doit pas gêner la navigation
  • en mode hors-ligne : l’application doit être accessible au moins sur la page d’accueil

L’application doit se comporter de manière extrêmement fluide, dans l’idéal autant qu’une interface d’application de bureau. Pour cela, les développeurs peuvent miser sur l’accélération matérielle en CSS, les requestAnimationFrame en JavaScript, l’optimisation des ressources.

HTTPS est obligatoire dans les PWA pour sécuriser l’intégralité des échanges entre le navigateur et le serveur, et permettre l’utilisation des Service Workers. Contrairement à une application native dont l’utilisateur n’a aucune idée de la sécurisation, c’est ici le navigateur, composant de confiance, qui affiche un cadenas vert, rassurant pour l’utilisateur.

schema TCP/IP - HTTPS - by DESIGNMOTEUR START-UP -

schema TCP/IP – HTTPS – by DESIGNMOTEUR START-UP –

Faire savoir à l’utilisateur que le site est disponible sous la forme d’une PWA n’est pas chose aisée. Des mécanismes natifs existent comme sur Chrome pour Android, par exemple. Cependant, le navigateur ne va proposer de rajouter la PWA sur la page d’accueil qu’à la seconde visite de l’utilisateur (il faut que cinq minutes se soient écoulés entre les deux sessions). Il faudra donc trouver d’autres méthodes pour prévenir l’utilisateur de cette possibilité et lui donner envie d’y recourir.

Techniquement, une PWA sauvegardera la page Web entière en local chez le visiteur, et mettra à jour seulement le contenu quand nécessaire. Ceci peut se faire en utilisant le Service Worker pour servir toutes les pages, les feuilles de style CSS, images et JavaScript, etc.. Tout cela sera stocké dans ce qui est généralement appelé un shell d’application. Ceci signifie que tout ce qui est nécessaire pour afficher la page sera stocké localement pour une performance optimale.

Ensuite, une fois qu’un utilisateur accède à une nouvelle page ou à une page avec du contenu mis à jour par rapport à la dernière visite de cet utilisateur, le Service Worker affiche le nouveau contenu en conséquence et le stocke également dans l’application.

Les PWA induisent que tous les utilisateurs doivent accéder aux mêmes contenus et interfaces visuelles.

Les utilisateurs disposant de navigateurs supportés par les Services Workers verront tous les aspects positifs des PWA.
Les utilisateurs qui utilisent des navigateurs sans prise en charge des PWA verront toujours la même mise en page, quels que soient leurs périphériques, mais ne pourront pas profiter des divers avantages, comme le mode hors ligne ou les notifications push.

PWA met en cache tout ce que l’on retrouve dans le « shell d’applications », donc nous avons la possibilité d’imiter l’apparence d’une application mobile existante, avec des éléments d’interface utilisateur, des animations, etc.

La toute première fois qu’un utilisateur visite un site Web avec une PWA installée, un ensemble complet ou partiel de contenu mis en cache sera stocké localement sur le périphérique de cet utilisateur. Cela garantit que toutes les visites ultérieures serviront les pages presque instantanément, et ajoute la possibilité pour les utilisateurs de visiter les pages en mode hors ligne.

Selon la façon dont les PWA individuelles sont développées, il est possible de mettre en cache tout le contenu, ou une partie de celle-ci, et il est également possible de montrer une simple page personnalisée hors connexion, ou de montrer la version ‘live’ avec du contenu mis en cache hors connexion.

Une fois qu’un site Web répond à quelques exigences pour être labellisé PWA, plusieurs navigateurs invitent maintenant les visiteurs à installer le PWA sur leur écran d’accueil, similaire à l’installation d’une icône pour un accès facile.

Chaque fois qu’un visiteur ajoute la PWA à son écran d’accueil, il peut être invité à accepter également les notifications push et ainsi recevoir des messages sur son périphérique automatiquement. Cela ouvre la possibilité à des sites Web d’exploiter un potentiel marketing jusque là monopolisé par les applications mobiles.

Les Progressive Web Apps fonctionneront partout sur le web, qu’elles soient installées ou pas. Elles fonctionneront même sur des plateformes qui ne supportent pas encore toutes les fonctionnalités des Progressive Web Apps de la même manière que les vieux ordinateurs peuvent accéder aux sites web les plus récents – avec quelques technologies en moins.

L’expression amélioration progressive renvoie à l’idée que vous pouvez concevoir une expérience qui marche partout et ensuite améliorer l’expérience pour les appareils qui supportent davantage de fonctionnalités plus avancées.

Les Progressive Web Apps partagent cette même philosophie. Les appareils qui ne supportent pas toutes les fonctionnalités des Progressive Web Apps bénéficieront toujours des améliorations faites pour les supporter.

Les mesures à prendre pour développer une Progressive Web App bénéficient à toute personne qui visite le site indépendamment de l’appareil qu’elle choisit d’utiliser.

Une Progressive Web App utilise les possibilités du web moderne pour proposer une expérience utilisateur similaire à une application native ajoutant une liberté propre au site web.


Évolution de l’intérêt pour cette recherche des termes Responsive Web Design & Progressive Web Apps de 2009 à 2017 :


Ressources :

RWD
http://alistapart.com/article/responsive-web-design/

Progressive Web Apps
http://adaptivepath.org/ideas/ajax-new-approach-web-applications/
https://jakearchibald.com/2013/progressive-enhancement-still-important/
https://jakearchibald.com/2014/offline-cookbook/
https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/

https://infrequently.org/2015/06/progressive-apps-escaping-tabs-without-losing-our-soul/

Apps mobile
https://www.comscore.com/Insights/Press-Releases/2014/8/comScore-s-US-Mobile-App-Report-Available-for-Download

https://www.recode.net/2015/6/13/11563532/one-in-four-mobile-apps-are-abandoned-after-a-single-use
https://www.recode.net/2016/6/8/11883518/app-boom-over-snapchat-uber

Dev Mozilla
https://developer.mozilla.org/fr/docs/Web/API/Service_Worker_API/
https://developer.mozilla.org/fr/docs/Web/API/Service_Worker_API/Using_Service_Workers
https://developer.mozilla.org/fr/docs/Web/Manifest

Dev Google
https://developers.google.com/web/fundamentals/getting-started/primers/service-workers/
https://developers.google.com/web/progressive-web-apps/
https://developers.google.com/web/showcase/2017/lancome

Dev Microsoft
https://blogs.windows.com/msedgedev/2016/07/08/the-progress-of-web-apps/
https://blogs.windows.com/msedgedev/2017/05/19/microsoft-edge-at-build-2017/

Dev Apple
https://webkit.org/blog/7833/release-notes-for-safari-technology-preview-36/
https://bugs.webkit.org/attachment.cgi?id=317095&action=prettypatch/

Dev
https://14islands.com/blog/2017/01/19/progressive-web-app-from-scratch/

http://blog.soat.fr/2013/11/html5-websockets/

PWA doc
https://makina-corpus.com/blog/metier/2016/decouvrir-le-service-worker/
https://makina-corpus.com/blog/metier/2016/introduction-progressive-web-apps/

https://fr.linkedin.com/pulse/les-avantages-des-progressive-web-app-pwa-d%C3%A9velopp%C3%A9es-c%C3%A9dric-loue

PWA blog
https://frank.taillandier.me/2016/06/28/que-sont-les-progressive-web-apps/

https://blog.clever-age.com/fr/2017/08/01/introduction-aux-progressive-web-apps/
https://blog.clever-age.com/fr/2017/06/27/progressive-web-app-lengouement-se-precise/
https://blog.clever-age.com/fr/2016/12/29/les-progressive-web-apps-pour-booster-ux/

http://blog.concept-image.fr/culture-numerique/progressive-web-apps-sites-applis/

https://www.powertrafic.fr/progressive-web-apps-web-mobile/

https://oncletom.io/node.js/chapter-01/index.html

site PWA
http://devdocs.io/


Vous, quelles idées auriez-vous pour votre PWA ? Discutons-en !



Comments are closed.