Les prochaines versions de Firefox et Chromium pourraient apporter des modifications importantes.

Premièrement, dans Firefox 66 pour ordinateurs de bureau, la lecture automatique de la vidéo et du son sur toutes les pages est bloquée par défaut. Le blog Mozilla Hacks avertit les développeurs à l'avance . La lecture de vidéo et de son n'est autorisée que via l'API HTMLMediaElement et uniquement après que l' utilisateur a interagi avec la page (clic de souris, clic de bouton ou toucher sur l'écran tactile).

Dans Chrome, des changements encore plus intéressants peuvent se produire.

Dans le même temps, la lecture automatique de vidéo avec un son étouffé est autorisée. Pour un tel contenu, vous devez définir l'attribut «muet» sur true pour HTMLMediaElement . La capture d'écran montre que les utilisateurs peuvent désactiver manuellement le blocage du son pour des sites individuels.

Dans Firefox pour Android, la nouvelle implémentation remplacera le mécanisme de blocage de lecture automatique existant.

Techniquement, Firefox bloque l'appel play() de HTMLMediaElement.play() , renvoyant une erreur NotAllowedError . Tous les navigateurs dotés de fonctionnalités similaires font de même. Par conséquent, les développeurs Web ne doivent pas supposer que l'appel à play() réussira toujours. Pour éviter le blocage, deux options sont recommandées. Premièrement: commencez à lire du contenu en conjonction avec un gestionnaire d'événements, par exemple, KeyboardEvent sur le bureau ou touchend pour Android. Deuxièmement: lancez la lecture automatique sans son (elle est activée par défaut) et montrez à l'utilisateur un bouton pour activer le son.

La version finale de Firefox 66 devrait sortir le 19 mars 2019 , afin que les développeurs aient le temps de se préparer.

Mozilla travaille actuellement sur le blocage automatique du contenu Web Audio : il est promis jusqu'à la fin de 2019.

Budget de la page Web

Les modifications apportées au chrome sont toujours en discussion. Pas le fait que le commit correspondant sera inclus dans la branche principale. Mais l'idée est très intéressante.

Le 4 février 2019, l'un des développeurs, Alex Russell, a introduit le commit 1265506 («Never-Slow Mode») . Il suggère d'introduire dans le navigateur un mode supplémentaire --enable-features=NeverSlowMode , qui limitera le budget de chaque page web , garantissant ainsi un chargement rapide.

Alex Russell est l'un des principaux développeurs de Chrome, Blink et de la plate-forme Web de Google, l'auteur de l'article «Pouvez-vous vous le permettre? Le budget de la productivité du web dans le monde réel ", dont la traduction a été publiée sur Habré.


Illustration tirée d'un article d' Alex Russell

Budget suggéré:

• Volume d'une image: 1 Mo
  
• Le volume de toutes les photos: 2 Mo
  
• Une feuille de style CSS: 100 Ko
  
• Toutes les feuilles de style CSS: 200 Ko
  
• Taille maximale du script: 50 Ko

Naturellement, l'utilisateur inclura cette fonction à volonté. Par exemple, si vous travaillez via une connexion Internet lente, sur un appareil faible (ordinateur obsolète), etc. La limite de budget garantit un chargement rapide et aucun freinage, mais augmente en même temps la probabilité que la page ne se charge pas à la fin.

De toute évidence, le budget doit être revu périodiquement, en se concentrant sur le temps de chargement des pages.

Sites d'obésité

La budgétisation par page est une bonne idée. De nombreux utilisateurs et spécialistes notent qu'au fil des années, les programmes et les applications Web ne deviennent pas du tout plus rapides, malgré une augmentation significative des performances informatiques.

Pour une raison quelconque, les demandes d'application augmentent plus rapidement que les performances matérielles. En conséquence, les logiciels ralentissent chaque année et les sites Web grossissent .

La tendance est que les logiciels ne deviennent pas du tout plus rapides et plus fonctionnels. Nous obtenons un équipement plus rapide sur lequel un logiciel avec les mêmes fonctions bascule plus lentement qu'auparavant. Tout fonctionne beaucoup plus lentement que la vitesse maximale. Vous êtes-vous déjà demandé pourquoi votre téléphone démarre de 30 à 60 secondes? Pourquoi ne peut-il pas démarrer, disons, en une seconde? Il n'y a aucune limitation physique. Personnellement, j'aimerais ça. Je veux que les développeurs atteignent la limite, en utilisant chaque bit pour les performances. - Extrait de l'article «Ma déception sur les logiciels»

Peut-être qu'un budget de page Web aidera à résoudre le problème si d'autres développeurs de Chromium acceptent l'engagement de Russell.

---