Firefox 36 prend en charge HTTP/2

Stéphane Moussie |

Seulement quelques jours après la finalisation du protocole HTTP/2, Firefox le prend en charge. C’est la dernière version stable du navigateur venant de sortir, la 36, qui supporte cette évolution du protocole améliorant notamment la rapidité de connexion. Les autres navigateurs devraient également bientôt faire de même.

Crédit Håkan Dahlström CC BY

Par ailleurs, Firefox 36 synchronise les tuiles épinglées de la page de nouvel onglet sur les différents terminaux où l’on est connecté avec son compte Firefox. On peut donc retrouver sur Android (et prochainement iOS) le même Firefox que sur Mac. Les autres changements concernent essentiellement les développeurs.

Tags
avatar nono68200 | 

Et concrètement, il faut simplement que le navigateur supporte ce nouveau protocole, où il y a d'autres choses nécessaires, comme un site forcément en HTML 5 par exemple ?

avatar Bardyl | 

Aucun rapport avec le HTML :).
HTTP ne s'occupe « que » des requêtes envoyées et des réponses reçues. Maintenant il faut attendre que les serveurs soient mis à jour de leur coté. Autant dire que ça peut prendre un certain temps...

avatar nono68200 | 

D'accord, donc il faut des serveurs à jour. Mais du coup, c'est automatique dans la plupart des cas non ? Je veux dire, dès que le serveur est mis à jour, y'a rien de plus à faire... Donc même un site créé en 2010, si le serveur d'hébergement se met sur du HTTP/2, ca passe ? (Histoire d'être sûr d'avoir compris...)

avatar jackhal | 

En théorie oui.
En pratique, le wiki de Mozilla indique toujours un support de HTTP/2 uniquement pour les connexions https avec TLS1.2 minimum : https://wiki.mozilla.org/Networking/http2
Google ayant aussi une forte envie de pousser https, ils pourraient bien décider de suivre la même voie.

avatar oomu | 

il faut que le serveur web visité gère HTTP2 et que son administrateur ait activé son usage.

L'internaute n'a rien à faire.

avatar - B'n - | 

Et concrètement ça accélère tant que ça la connexion ?
Parce qu'actuellement, ce qui est « long » c'est plus le chargement des images/vidéos que les requêtes non ?

avatar nono68200 | 

Bah du coup, si j'ai bien compris, ca permettra justement de charger les images/vidéos en même temps que la page, là où actuellement, la page se charge d'abord, et ensuite le multimédia... Donc après je ne sais pas si le changement sera révolutionnaire, mais ca devrait en théorie être plus rapide...

avatar - B'n - | 

Ok merci pour l'info.
Je me demande comment ça fonctionne car les appels des éléments sont dans le code de la page, donc il faut bien la télécharger, la lire et l'interpréter avant de pouvoir lancer les autres chargements…

avatar oomu | 

cela devrait accélérer le chargement de pages riches en éléments divers (par exemple, une page de MacG.co, qui a plein d'images, etc)

Au lieu d'initier une requête par élément composant la page web (avec éventuellement un traitement différé imprévisible), le protocole permet d'utiliser une seule requête pour plusieurs éléments. Cela optimise le temps du serveur et la bande passante (on ne gaspille pas en ouverture, fermeture, négociation de requête http).

Ca ne peut évidemment rien pour le débit d'un flux (vidéo en stream par exemple ou gros fichiers en cours de transfert) mais le web n'est pas que cela.

ça donnera au final moins de "latence" (le temps avant qu'une page s'affiche complète et lisible par l'utilisateur) au web.

avatar jackhal | 

une page de MacG.co ne sera pas beaucoup accélérée sans toucher au code.

avatar Strix | 

@- B'n - :
C'est ça, les images sont longues à charger parce que certains webdesigners pensent que tout le monde à la fibre et ils ont oublié le mot "optimisation"

avatar mp_ | 

Avoir le navigateur, c'est bien, mais côté serveur, on est pas encore tout à fait prêt semble-t-il ...

http://en.wikipedia.org/wiki/HTTP/2#HTTP.2FHTTPS_servers

avatar Mark Twang | 

Vivement la version iOS !

CONNEXION UTILISATEUR