Google organisait cette semaine son Chrome Dev Summit pour réunir les développeurs intéressés par le futur du navigateur et la manière dont la société considère le web. Le cru 2017 consacrait Chrome comme moteur de rendu, Google voulant manifestement en faire un point de chute pour les développeurs d’applications.
Si l’on en croit Google, les raisons de se réjouir sont nombreuses. L’entreprise semble particulièrement satisfaite de la progression du HTTPS sur un an. La firme rappelait en fait ici quelques chiffres donnés en fin de semaine dernière. Par exemple, 64 % du trafic transitant par Chrome sur Android est protégé, contre 42 % il y a un an.
Autre facteur de satisfaction, les Progressive Web Apps (PWA). Ces dernières sont pour rappel toujours des applications web, mais avec des interfaces et fonctionnalités pratiquement égales à celles des applications natives. Les performances doivent donc être alignées sur ces dernières, l’interface doit s’adapter à l’écran, les API Notification et Push doivent être gérées, HTTPS est obligatoire et on peut l’installer sur l’écran d’accueil via son icône.
Le Service Worker en approche chez Apple et Microsoft
Ce qui réjouit tant Google, c’est que le support du Service Worker (SW) progresse chez Apple et Microsoft. Il s'agit d'un script chargé en parallèle de ceux spécifiques à la page web qui devient en quelque sorte un proxy pour l’application web via l’API postMessage. Il gère les requêtes depuis et vers l’application et peut y répondre en puisant dans une base de données locales. Il permet ainsi le mode hors ligne, obligatoire pour une PWA.
Qu’il s’agisse des moteurs Webkit ou EdgeHTML, ce support est « en cours de développement ». Cet élément essentiel sera donc bien présent dans Safari et Edge, mais on ne sait pas quand. Autre élément important pour les PWA, le Web Application Manifest est en considération chez Apple, et en développement chez Microsoft.
Trusted Web Activity, encore un mix de contenus web et locaux
Google tient décidément à ce que les développeurs utilisent autant que possible les technologies du web pour leurs applications, quelles qu’elles soient. Et pour cause : plus ils les utiliseront, plus ils auront des chances de pousser encore Chrome en avant. Un mouvement à l'inverse d'Apple par exemple, qui pousse vers Swift et le développement natif.
Si les développeurs doivent manipuler des ressources web dans leurs applications natives, pourquoi dès lors ne pas leur proposer Chrome comme moteur de rendu ? C’est justement l’objectif de la Trusted Web Activity (TWA).
Le contenu TWA vient donc du web, du même éditeur que l’application native servant de base (d’où le terme « confiance »). Leur rendu est effectué par Chrome pour le compte de l’application, de la même manière que si le navigateur s’en chargeait lui-même. À ceci près que le contenu est affiché en plein écran, donc sans aucun élément de contrôle autres que ceux prévus par les développeurs.
Plusieurs avantages selon Google. D’abord le développeur n’a pas à se soucier d’intégrer quoi que ce soit pour le rendu web. Le moteur étant celui de Chrome, il est déjà présent sur Android, soulageant éventuellement le poids total de l’application. De plus, la TWA limite les risques en coupant tout accès direct aux ressources web depuis l’application native. Une communication peut néanmoins se faire via des paramètres dans des URL. Enfin, que les écrans proposés soit de type web ou natif, tout est question d’activités et les deux peuvent s’enchainer.
Pour l’instant, Chrome n’est pas capable d’effectuer ce rendu. La fonctionnalité vient tout juste d’arriver dans le canal de développement Canary sous forme d’une API. Notez que si pour une raison ou une autre la fonction est inexploitable en cas d’appel, Chrome fournira à la place un Custom Tab.
Cette nouvelle interface pour développeurs risque cependant de renforcer la position de Chrome sur Android. En poussant toujours plus son navigateur comme un élément de rendu pour les applications web et mixtes, Google s’assure une belle place au soleil.
De navigateur, Chrome devient trousse à outils
En tant que navigateur, Chrome est assis sur une immense source de données diverses. Google veut en faire profiter les développeurs en leur fournissant des indications techniques capables d’améliorer l’expérience utilisateur.
Arrive donc le Chrome User Experience Report, un dépôt public d’informations diverses sur la manière dont les sites sont utilisés. Seules les données des utilisateurs ayant activé la synchronisation de l’historique, n’ont pas configuré de phrase de passe et participent volontairement aux données statistiques sont présentes.
Le premier lot de données provient de 10 000 sites et se base sur une petite dizaine de métriques. On retrouve ainsi First Paint (premier élément rendu de la page), DOMContentLoaded (document HTML lu et parsé), Effective Connection Type (nécessite l’API Network Information présente dans Chrome 62), Device Type ou encore onload (temps de chargement pour la page et de ses ressources).
L’idée de Google est d’encourager les développeurs à comparer ces valeurs avec celles constatées pour leurs propres pages. Le fait que les données proviennent « d’utilisateurs réelles » peut ainsi représenter une ressource complémentaire, permettant de sortir des tests locaux et autres simulations.
L’intérêt pour Google est évident : impliquer toujours plus Chrome dans le développement web. Car si les données sont recueillies via des API tout à fait standard, c’est bien le nom de Chrome qui est associé au stock d’informations.
Simplifier la création de compte, toujours en passant par Google
Cette prévalence de Google est également très visible dans deux nouveaux mécanismes présentes aux développeurs : One tap sign-up et Automatic sign-in.
Le concept consiste à simplifier au maximum l’étape de création du compte sur un service, qu’il s’agisse d’une application ou d’une simple page web (ou un mélange des deux évidemment). Partant du principe qu’il y a de fortes chances que l’utilisateur se soit déjà connecté à un compte Google depuis Chrome, pourquoi ne pas réutiliser ces informations ?
One tap sign-up propose donc d’utiliser ce compte pour créer un jeton de sécurité faisant office de lien avec le service tiers. Avantage pour l’utilisateur, le processus est réduit à sa plus simple expression puisqu’il n’y a même pas besoin de mot de passe. Google met en avant une friction minimale, apte à faire progresser les inscriptions, souvent rebutantes pour les internautes.
Automatic sign-in assure pour sa part la reconnexion automatique au service tiers, si le jeton de sécurité a expiré entre temps. Cette reconnexion intervient même si l’utilisateur se connecte depuis un autre appareil. Dans le cas d’un compte avec mot de passe, celui-ci ne sera pas exigé s’il a été auparavant enregistré dans Chrome ou Smart Lock for Passwords.
Et les avantages pour Google ? Évidents : pousser toujours davantage le compte maison, tout autant que Chrome. Les éditeurs tiers peuvent effectivement compter sur une hausse des inscriptions, mais le compte qui en résulte reste basé sur celui de Google. Il s’agit d’une version simplifiée à l’extrême de Google Sign-In, déjà en place depuis quelques années.
Pour utiliser cette fonctionnalité, les développeurs intéressés devront en premier obtenir un Google API client ID, puis ouvrir la page Credentials de la console. Notez que One tap sign-up et Automatic sign-in disposent d’une intégration à l’API Credential Management.
La simplification ou la diversité
L’équation proposée par Google est on ne peut plus simple et rappelle d’autres aspects de la concentration, notamment pour les données personnelles : si les développeurs veulent utiliser ces nouvelles capacités, il faut passer par ses services.
D’un côté, le constat n’est pas étonnant : il s’agit après tout de nouveautés annoncées dans le cadre d’un Chrome Dev Summit. De l’autre, certains développeurs se méfieront sans doute d’un web trop accroché au géant de Mountain View, car la simplification dans ce domaine (comme dans bien d’autres) a un prix. Comme toujours lorsque l'on met tous ses œufs dans le même panier.
Signalons qu’il s’agit des nouveautés les plus visibles annoncées par Google. La firme a effectué de nombreuses présentations, toutes rassemblées sur cette page de YouTube. La plupart sont des cas pratiques de technologies proposées par l’éditeur, ou d’exploitation de standards existants à travers les outils de Chrome.
Commentaires (22)
#1
Quand on pourra faire autant avant un navigateur qu’avec un application mobile, ça sera un très grand pas de fait en avant et on s’affranchira enfin de ces stores à la noix, et ces technos enfermantes.
Qu’on puisse utiliser un simple FF sur son mobile pour TOUT faire, la webapp mieux qu’une appli. C’est mon souhait depuis 20 ans que j’utilise un navigateur.
Pour ceux que ça branche :https://whatwebcando.today/
#2
Safari est maintenant notre nouvel IE6, j’exagère mais c’est drôle de penser que dans le #turfu dans lequel on est, on a toujours un problème avec un navigateur.
#3
C’est quoi le problème avec Safari ?
#4
#5
Sauf que Safari ne domine pas. Il est obligatoirement présent sur iOS mais Chrome domine le web en étant présent partout.
#6
#7
#8
#9
Certaines API ne verront probablement jamais le jour pour des raisons de sécurité (je pense notamment à l’API Battery Status ou l’API Contacts).
Mais en terme de performance, l’horizon d’un web aussi performant que du natif commence à se rapprocher sérieusement, notamment grâce à des outils offerts aux développeurs (j’ai découvert récemment la propriété CSS will-change, c’est juste magique).
#10
Pour le JS, si tu en reste au JS d’il y a 5 ans, effectivement, c’est une plaie.
En revanche, comme le souligne l’article à juste titre, je ne pense pas que ça soit la voie souhaitée par Apple qui a d’avantage intérêt à garder captifs ses utilisateurs dans on écosystème fermé.
#11
Battery Status est déjà gérée par qq browsers je crois
Celle des contacts pose pas plus de soucis que pour des apps au final, dans tous les cas faut que l’autorisation soit demandée à l’utilisateur, sinon y’a un souci.
#12
https://html5test.com/results/desktop.html
C’est plus pratique que caniuse pour comparer rapidement
#13
Seul Chrome la supporte, elle a été retirée de Firefox et de Safari.
Le problème des contacts est le même que celui de la Battery API : elle donne accès à un niveau de données tellement précises au niveau du système que les webapp peuvent faire du fingerprinting ultra fiable. En gros, n’importe quel éditeur pourra te tracker via ses app natives et ses sites web - quel que soit le navigateur - de manière 100% fiable sur un même device. Même plus besoin des cookies, il n’y a plus aucune barrière entre domaines, navigateur et apps et au final, l’utilisateur n’a plus aucun contrôle.
#14
#15
#16
#17
#18
Tu t’attends pas à ne pas être identifiable lorsque tu donnes l’accès à tes contacts.
C’est tout aussi vrai pour les apps que certains installent comme ils visitent des sites.
Faut simplement que lorsqu’un “site” (comme une app) tente d’y accéder la demande soit claire.
#19
#20
Y a pas vraiment de status quo là dessus
Plusieurs développeurs de browsers ont plutôt intérêt à ça même (google et ms)
Et c’est pas comme si le même souci n’existait pas déjà avec les apps…
#21
Non, Google n’a pas intérêt à ça. Son business model est basé sur la confiance qu’ont les utilisateurs en ses produits (“je sais que je communique des données personnelles, mais ça en vaut la peine, je ne pourrais pas m’en passer”).
Si cette confiance s’effrite ne serait-ce qu’un peu, c’est problématique pour eux. Le problème des demandes de droits majoritairement ignorées a été souligné (et admis) par Google himself lors de sa dernière Google I/O, notamment suite à quelques cas récents d’appli ultra-connues qui ont abusé de droits abusifs.
#22
Y’a la com’ et la réalité hein