Tout ce que vous devez savoir sur Declarative Web Push

Je m’appelle Brady Eidson, je suis ingénieur dans l’équipe d’architecture WebKit. Je suis très heureux de vous parler des récentes avancées en matière de notifications Web Push.

Les notifications push sont un élément crucial du Web moderne et de toute plate-forme actuelle.

Nous avons commencé à intégrer les notifications push aux plates-formes d’Apple en 2009 avec l’iPhoneOS 3. Nous étions les pionniers, mais les notifications push ont clairement pris leur place dans toutes les plates-formes modernes. Elles ont intégré macOS, puis d’autres plates-formes de bureau et plates-formes mobiles en peu de temps. Presque du jour au lendemain, les apps partaient du principe que les notifications push étaient intégrées à la plate-forme.

Au début, nous ajustions le fonctionnement du push pour les apps natives afin de trouver le compromis idéal pour les développeurs et les utilisateurs. Nous savions dès le départ que les notifications push avaient leur place sur le Web, et nous voulions être attentifs aux détails. Nous avons ajouté les notifications push Safari à Safari 7. Les développeurs ont adopté Safari Push avec enthousiasme, les utilisateurs ont suivi et nous savions que nous tenions quelque chose. Safari Push nécessitait une intégration étroite avec les systèmes Apple, nous ne pouvions pas l’implémenter sur d’autres navigateurs. Bien sûr, tous les navigateurs avaient besoin des notifications push. La communauté des normes web s’est sérieusement penchée sur Web Push, et le premier navigateur l’a intégré un ou deux ans plus tard.

À l’époque, on se concentrait sur les fonctionnalités JavaScript. À l’origine, Web Push a été conçu pour être un système extrêmement flexible, entièrement piloté par le code JavaScript que vous écrivez. Nous sommes fiers de tirer le maximum de performances de chaque exécution de JavaScript, mais comme tous les ingénieurs logiciels le savent : écrire et maintenir du code est plus susceptible de contenir des bogues que l’absence de code.

Et même dans un moteur JavaScript à la pointe de l’efficacité, exécuter du code est moins efficace que de ne rien faire.

Autre inconvénient de cette approche : la confidentialité. Les données du site web sont un vecteur permettant de suivre la navigation des utilisateurs, c’est pourquoi la prévention intelligente du suivi limite la durée de vie du JavaScript requis à l’origine pour le Web Push.

Avec les notifications push iOS, macOS et Safari, le message push lui-même contient une description normalisée de la notification visible par l’utilisateur. Aucun code propre à l’application n’est requis pour l’afficher.

Les apps natives n’ont même pas besoin de leur code sur l’appareil pour afficher une notification push. Les apps supprimées d’iOS affichent leurs notifications sans problème.

En ajoutant le Web Push original à nos navigateurs, nous avons observé quelque chose d’intéressant. Malgré la flexibilité offerte par les standards, de nombreux sites web envoient des messages push dans un format JSON simple à analyser, et leur code JavaScript Service Worker se contente de les traduire en appel API pour afficher la notification. Compte tenu de notre longue histoire avec les notifications push iOS, macOS et Safari, cela nous semblait logique. Et cela nous a donné une idée assez simple. Si déclarer en amont la notification en JSON est courant, nous pouvions faire évoluer Web Push pour qu’il vous trouve là où vous êtes.

En supprimant l’étape qui vous impose d’écrire du code, vous obtenez les mêmes avantages que ceux des apps natives ont dès le départ.

Le Web Push déclaratif offre la facilité d’utilisation, l’efficacité et la transparence. L’utiliser est aussi simple que d’envoyer vos messages push dans un format standardisé et sa configuration ne nécessite presque pas de code.

Nous l’avons conçu dans l’esprit de l’Open Web, en collaborant avec la communauté des normes web tout au long du processus. Il est également conçu pour être rétrocompatible avec les navigateurs qui ne le prennent pas encore en charge. Le Web Push déclaratif est un véritable progrès pour le Web. Si vous connaissez déjà le Web Push original, les concepts de base restent les mêmes.

Comme il s’appuie sur des normes établies, nous aborderons les nouveautés du Web Push déclaratif en revoyant certains éléments du Web Push original. Commençons par une vue d’ensemble du Web Push original.

Il repose presque entièrement sur JavaScript sous la forme d’un Service Worker installé. Un Service Worker contient le code qui gère les événements « push » pour afficher les notifications.

Ensuite, il vous faut un abonnement push. Il contient les informations dont votre serveur a besoin pour accéder au navigateur de l’utilisateur, telles que l’URL à utiliser pour envoyer un message push. En réponse à une action de l’utilisateur, votre JavaScript demande un abonnement push, puis l’envoie à votre serveur pour l’utiliser ultérieurement.

Lorsqu’il est temps d’envoyer une notification, vous utilisez l’URL de l’abonnement pour envoyer un message push. Dans les navigateurs WebKit, vous l’enverrez à l’Apple Push Notification Service utilisé pour nos apps natives, mais vous n’avez pas besoin de compte Apple Developer pour utiliser ces abonnements.

Le message chemine jusqu’au navigateur, qui recherche le Service Worker responsable avant de le lancer. Le navigateur envoie un événement push à ce Service Worker, contenant toutes les données envoyées dans votre message push.

Le Service Worker analyse le message et construit un appel JavaScript à l’API showNotification, qui affiche la notification.

Plus tard, lorsque l’utilisateur touche cette notification ou clique dessus, le navigateur relance le Service Worker approprié s’il n’est plus en cours d’exécution et lui envoie un événement notificationclick. Votre gestionnaire a alors pour tâche de faire quelque chose d’utile, généralement d’ouvrir une fenêtre sur une URL.

C’est ainsi que fonctionne le Web Push original aujourd’hui. La majorité des étapes décrites sont gérées par du JavaScript que vous devez écrire et que le navigateur doit exécuter.

Le Web Push déclaratif n’élimine pas complètement JavaScript, mais il s’en rapproche. Le seul JavaScript indispensable avec le Web Push déclaratif sert à obtenir cet abonnement Push, mais sans passer par un Service Worker.

Une fois que vous envoyez un message push déclaratif, le navigateur le reçoit comme avant et l’analyse, à la recherche d’un JSON valide.

Il s’assure que le fichier JSON décrit une notification valide visible par l’utilisateur, puis l’affiche automatiquement.

Le navigateur gère également automatiquement les touchers ou les clics sur la notification. Nous verrons comment le navigateur sait ce qu’il doit faire, mais revenons d’abord au JavaScript requis pour obtenir cet abonnement push. Voyons à quoi ressemblait ce code avec le Web Push original et à quoi il ressemble maintenant avec le Web Push déclaratif.

Cela semblera familier à ceux d’entre vous qui ont déjà utilisé le Web Push original.

Comme je l’ai mentionné, le Web Push original nécessite avant tout qu’un Service Worker soit installé. Une fois votre Service Worker enregistré, vous pouvez accéder à son objet PushManager en réponse à une action de l’utilisateur pour demander un abonnement push.

Le code permettant d’obtenir un abonnement push avec le Web Push déclaratif est presque le même qu’avant, mais comme aucun Service Worker n’est requis, PushManager est désormais également disponible sur l’objet window.

Et voici la magie. Si vous utilisez le Web Push déclaratif pur, vous n’avez pas d’autre code à écrire. Le Web Push déclaratif définit un format JSON standard pour les messages push. Voici un exemple de message minimal valide de l’outil d’infrastructure critique de notre équipe, l’app web Browser Pets.

Il comprend une entrée obligatoire décrivant une notification visible par l’utilisateur.

Cette notification doit contenir à la fois le texte du titre et une URL accessible si l’utilisateur touche la notification ou clique dessus.

Mais cette entrée principale est cette valeur magique pour un message push déclaratif. Vous devez toujours avoir une clé web_push avec la valeur 8-0-3-0.

8030 est la norme RFC originale de l’IETF pour les messages push web, et nous avons pensé qu’il était très improbable que quelqu’un l’inclue.

Rappelez-vous, nous avons retracé le parcours d’un message push déclaratif via le navigateur.

La recherche de la clé magique fait partie de ce parcours.

Que se passe-t-il si le navigateur tente d’analyser le JSON du message push et échoue ? Dans ce cas, il revient au Web Push original, en utilisant un Service Worker pour gérer le message.

Il revient également au Web Push original si le JSON n’a pas la clé magique.

Que se passe-t-il si le message push contient un JSON et la clé magique, mais ne décrit pas une notification valide ?

Dans ce cas, le navigateur ne fait tout simplement rien et laisse tomber le message. Mais si un message push passe toutes ces vérifications, le navigateur affiche automatiquement la notification.

Un titre de notification et une URL de navigation sont le minimum requis pour une notification valide. Mais si vous connaissez le Web Push original, vous savez que JavaScript comporte beaucoup plus d’options lors de la création d’une notification. Le Web Push déclaratif les prend toutes en charge.

Ici, nous spécifions un corps pour le message, une balise de notification et nous demandons à la plate-forme de diffuser le son de notification par défaut, si possible. Ce ne sont que des exemples, tout ce qui est pris en charge par le dictionnaire NotificationOptions du W3C est respecté.

Mais ce n’est pas tout ! Les badges d’application, pour le nombre d’éléments non lus par exemple, ont tendance à aller de pair avec les notifications, de sorte que les messages push déclaratifs prennent également en charge la mise à jour intégrée du badge d’app.

Le nombre de notifications que vous pouvez désormais afficher automatiquement dans le navigateur est un soulagement. Mais parfois, vos besoins sont plus spécifiques et vous ne pouvez pas vous fier entièrement au navigateur pour tout.

Nous avons tiré cette leçon du push natif sur iOS et macOS, et les apps qui utilisent le framework UserNotifications ont cette capacité depuis un certain temps. Tandis que ces messages push décrivent toujours une notification visible, l’app peut choisir de l’affiner de manière plus utile.

Le Web Push déclaratif prend également cela en charge, sous la forme d’un traitement facultatif par un Service Worker. Pourquoi est-ce si important ? C’est utile lorsque vous avez des normes extrêmement élevées pour l’exactitude de vos notifications. Par exemple, le serveur Browser Pets peut informer un utilisateur qu’il a 7 messages non lus, sans savoir que l’utilisateur en a déjà lu 3. JavaScript sur l’appareil client peut mettre à jour la notification et aider l’utilisateur.

Parfois, vous ne pouvez mathématiquement pas inclure le texte de notification. Les utilisateurs de Browser Pets s’attendent à un chiffrement de bout en bout de classe mondiale lorsqu’ils s’envoient des messages directs, et une clé sur l’appareil client est le seul moyen de décoder la notification. Voyons à quoi cela ressemble. Voici à quoi ressemble le JSON de notification pour un message direct classique de Browser Pets.

Le JSON contient les données qui ont été chiffrées sur l’appareil de l’expéditeur. L’appareil de notre utilisateur dispose de la clé pour déchiffrer ces données et peut le faire grâce à son Service Worker facultatif.

Le JSON comporte également une entrée spécifiant « mutable » comme Vrai. La plupart des messages push déclaratifs sont traités automatiquement, mais cette entrée indique au navigateur que cette notification doit être traitée par le Service Worker.

Voici le JavaScript utilisé par Browser Pets pour gérer le déchiffrement des messages directs.

Nous avons donné à notre Service Worker un gestionnaire d’événements push, comme vous le feriez avec le Web Push original.

Une nouveauté est que si l’événement distribué provient d’un push spécifié comme « mutable », l’événement dispose désormais d’une copie de la notification proposée par le JSON déclaratif.

L’inspection de cette notification nous permet de savoir qu’il s’agit d’un message direct et d’accéder aux données chiffrées.

Vous vous souvenez de notre organigramme pour le Web Push déclaratif ? Après avoir validé la description de la notification, le navigateur recherche l’entrée « mutable ».

Si elle est absente ou définie sur Faux, le navigateur affiche automatiquement la notification.

Si elle est définie sur Vrai et que le Service Worker affiche une notification de remplacement, le navigateur utilise le remplacement au lieu du texte brut du message push.

Ainsi, si notre Service Worker réussit à déchiffrer le message direct et remplace la notification proposée, le navigateur affichera ce message déchiffré.

Mais s’il ne parvient pas à déchiffrer le message et ne propose donc pas de remplacement, la notification originale en texte brut sera utilisée.

La notification déclarative sera également utilisée dans les cas où le Service Worker ne peut pas être lancé, parce que les fonctionnalités de confidentialité l’ont supprimé ou que l’appareil est soumis à une pression des ressources. Le Web Push déclaratif utilise son JavaScript optionnel pour Service Worker de la même manière que le Web Push original requiert des Service Workers. Et cela nous amène à la partie que je préfère. Passons en revue la rétrocompatibilité.

Aujourd’hui, la plupart des principaux moteurs de navigation et de nombreux sites web prennent en charge le Web Push original. Même si l’adoption à grande échelle du Web Push déclaratif serait préférable, nous avons fait en sorte que vous puissiez l’adopter facilement tout en vous assurant que vos notifications fonctionnent dans tous les navigateurs. Pour beaucoup d’entre vous qui utilisent déjà le Web Push original et font une simple analyse JSON pour afficher une notification, je parie que le format de vos messages push a évolué à mesure que vos besoins grandissaient et se complexifiaient. C’est comme cela que Browser Pets s’est développé avec le temps. Une fois que l’équipe WebKit a fait fonctionner le Web Push déclaratif, nous voulions que Browser Pets en profite pour fournir des notifications aussi efficaces et fiables que possible. Mais le push doit évidemment continuer à fonctionner pour tous les navigateurs. Je vais vous expliquer comment nous l’avons mis à jour.

Ce JSON de notification de Browser Pets s’est développé de manière organique au fil du temps.

Au début, il n’incluait que le texte du titre pour la notification.

À l’origine, les clics de notification ouvraient l’app principale Browser Pets. Nous avons ensuite ajouté cette entrée clickURL pour configurer la destination du clic de notification.

Ensuite, certains ingénieurs ont estimé que le texte du corps de la notification était important.

J’assume la responsabilité du changement suivant. L’idée de jouer le son d’alerte système pour les notifications venait de moi.

L’ingénieur suivant a constaté que nous configurions essentiellement nos notifications avec un dictionnaire web NotificationOptions standard, et a décidé de le coder explicitement. Bien sûr, personne n’est revenu en arrière pour mettre à jour les options précédentes.

Ce format JSON ad hoc contient tout ce qui compose un appel d’API à showNotification, mais avec une structure et des noms différents.

Le réorganiser pour qu’il corresponde au format standard déclaratif était un jeu d’enfant.

Tout comme renommer chaque propriété avec le nom standard d’un dictionnaire NotificationOptions.

Une fois la clé magique ajoutée pour indiquer qu’il s’agissait d’un message push déclaratif, nous avons reçu des notifications automatiques dans les navigateurs récents qui les prennent en charge !

Revenons à ce JSON ad hoc. Avec le Web Push original, le message push n’est qu’une pièce du puzzle. Votre Service Worker doit en faire quelque chose. Voici le Service Worker original de Browser Pets. Chaque argument que nous avons introduit dans ce JSON a dû être extrait par son nom et nous avons dû créer un dictionnaire NotificationOptions pour l’appel éventuel à showNotification.

Maintenant, rappelez-vous à quoi ressemble le message push déclaratif.

L’élément critique d’un message déclaratif qui décrit la notification est conçu pour être lui-même un dictionnaire NotificationOptions valide. Ainsi, une fois que nous avons reformaté notre message push pour qu’il soit un JSON déclaratif valide, la réécriture de notre Service Worker pour le gérer est très simple.

Nous extrayons le membre « notification » du JSON, extrayons le titre et le transmettons à showNotification tel quel.

Une fois que vous avez refactorisé le JSON de votre message push et le gestionnaire d’événements push de votre Service Worker, vos messages Web Push tirent parti de tous les navigateurs.

Les navigateurs qui prennent en charge le Web Push déclaratif les gèrent de manière fiable et efficace.

Et ceux qui ne prennent pas encore en charge le Web Push déclaratif les gèrent via votre JavaScript, comme tout message Web Push original. Nous sommes ravis du Web Push déclaratif et espérons qu’il pourra fonctionner pour tout le monde. Essayez-le dans Safari 18.5 et versions ultérieures sous macOS, ou dans des apps web enregistrées sur l’écran d’accueil sous iOS 18.4 ou iPadOS 18.4 et versions ultérieures.

Si vous prenez en charge le Web Push dans votre app pour la première fois, vous pouvez opter pour le format déclaratif dès le départ. Si vous utilisez déjà le Web Push, c’est le moment idéal pour commencer la transition. Et quitter le format de notification Push Safari, lui-même déclaratif, n’a jamais été aussi facile. À mesure que vous l’adoptez, gardez à portée de main les ressources associées à cette séance pour donner votre avis à la communauté des normes web ou au projet WebKit.

Vous pouvez également consulter ces séances pour en savoir plus sur la façon dont nos navigateurs prennent en charge le Web Push en général, et sur les nouveautés de Safari et WebKit cette année.

Merci de votre attention !