Firefox 155 est sorti le 1er septembre 2026, et le changement principal ne se voit pas dans l'interface. Il se voit dans une capture réseau. Happy Eyeballs v3 est activé par défaut, ce qui signifie que Firefox ne met plus seulement IPv6 en course contre IPv4. Il interroge l'enregistrement DNS HTTPS en même temps que AAAA et A, lit la liste des protocoles que le serveur y annonce, et met HTTP/2 en course contre HTTP/3 au passage. La première tentative qui aboutit gagne. À côté de cela, Firefox négocie maintenant QUIC version 2 quand un serveur le propose. Si vous exploitez des services publics, ces deux points changent ce que votre zone DNS et votre frontal doivent contenir.
The short answer
Firefox 155 active Happy Eyeballs v3, qui étend la mise en course des connexions des familles d'adresses vers les types d'enregistrements DNS et les versions HTTP. Le navigateur interroge l'enregistrement de ressource HTTPS avant ou en même temps que AAAA et A, lit la liste de protocoles et les indications d'adresses qu'il y trouve, et tente plusieurs chemins simultanément au lieu de parcourir une liste triée. La version négocie aussi QUIC version 2 pour HTTP/3 quand un serveur le sélectionne, ce qui compte pour l'ossification du protocole plutôt que pour la vitesse. Pour qui exploite un service public, la partie actionnable consiste à publier un enregistrement HTTPS pour que la première connexion aille directement en QUIC.
La plupart des sorties de navigateur se ressentent dans l'interface. Celle-ci se ressent dans une capture de paquets. Firefox 155, publié le 1er septembre 2026, modifie les premières millisecondes de chaque navigation, et le changement est assez large pour mériter d'être compris côté serveur, même si vous n'ouvrez jamais Firefox.
Happy Eyeballs a cessé de parler d'IPv6
L'algorithme d'origine existait pour une seule raison : un client disposant d'un enregistrement AAAA et d'un chemin IPv6 cassé attendait l'expiration d'un délai TCP pendant que l'utilisateur regardait un onglet blanc. La version 1 mettait les deux familles d'adresses en course. La version 2 affinait l'ordre et les délais entre tentatives. Toutes deux répondaient au fond à une seule question : quelle famille d'adresses utilisons-nous.
La version 3 pose une question plus large. Le document ajoute les types d'enregistrement SVCB et HTTPS à l'algorithme, et cela change la forme de l'ensemble. Le client émet la requête HTTPS juste avant les requêtes AAAA et A, parce que cet enregistrement peut transporter deux choses utiles à la fois : les protocoles applicatifs réellement pris en charge par le serveur, et des indications d'adresses pour l'atteindre. La spécification est explicite, les implémentations ne devraient pas attendre toutes les réponses avant de commencer à se connecter. Ce qui arrive en premier entre en course.
Ainsi, au lieu de résoudre, trier, puis décider séquentiellement s'il faut tenter HTTP/3, Firefox dispose d'un seul processus parallèle qui couvre à la fois la famille d'adresses et la version HTTP. IPv6 et IPv4, HTTP/2 et HTTP/3, tous en vol, et le premier qui s'établit gagne. Les délais qui protégeaient d'un chemin bloqué existent toujours, mais ils s'appliquent désormais à un ensemble de candidats plus large.
L'effet pratique pour un utilisateur, c'est qu'un chemin lent ou mort ne coûte presque rien. L'effet pratique pour un exploitant, c'est que la zone DNS est devenue un élément de la performance de connexion, ce qu'elle n'était pas auparavant.
Publiez un enregistrement HTTPS, ou payez un aller-retour
Voici la partie sur laquelle agir. Si vous servez HTTP/3 aujourd'hui sans enregistrement de ressource HTTPS dans votre zone, un client n'a aucun moyen de le savoir sur une connexion à froid. Il se connecte en TCP puis TLS, lit un en-tête Alt-Svc dans la réponse, le met en cache, et utilise QUIC lors d'une visite ultérieure. La première visite, celle qui décide si quelqu'un reste, paie quand même l'établissement TCP complet.
Avec un enregistrement HTTPS qui annonce h3 dans son paramètre ALPN, un client version 3 peut engager une tentative QUIC dans la course dès le premier paquet, avant qu'aucune poignée de main TCP n'ait abouti. Il peut aussi utiliser les indications d'adresses de l'enregistrement, ipv4hint et ipv6hint, pour commencer à se connecter sans attendre le retour d'une réponse A ou AAAA séparée.
C'est une modification de fichier de zone, pas un chantier d'infrastructure. La plupart des hébergeurs DNS gérés prennent en charge le type HTTPS depuis un moment. Si vous avez déjà fait le travail d'activer HTTP/3 sur le frontal, ne pas publier l'enregistrement rend l'essentiel de ce travail invisible pour les nouveaux visiteurs. Nos notes sur ce qui a changé dans Firefox 154 couvrent le côté plateforme de la version précédente si vous suivez la série.
QUIC version 2 est une mesure anti-ossification, pas un gain de vitesse
Le second changement réseau se lit facilement de travers. Firefox 155 prend en charge QUIC version 2 et l'utilise quand un serveur le sélectionne par négociation de version compatible. Personne n'obtient une page plus rapide grâce à cela.
QUIC version 2, défini dans la RFC 9369, est le même protocole que la version 1 sur le plan du comportement. Ce qui change, c'est un ensemble de constantes sur le fil : le numéro de version lui même, les sels servant à dériver les clés initiales, les valeurs des types de paquets à en-tête long. Le but est de garantir qu'il existe plus d'une version de QUIC dans la nature.
Cela paraît théorique jusqu'à ce qu'on se rappelle ce qui est arrivé à TCP. Des décennies d'équipements intermédiaires ont appris à reconnaître TCP à sa disposition d'octets, puis ont commencé à imposer ce qu'ils croyaient voir, et le résultat est qu'expédier une véritable nouvelle option TCP sur l'internet public est aujourd'hui quasi impossible. QUIC a été conçu pour éviter ce sort, en partie en chiffrant l'essentiel de l'en-tête, en partie en exerçant tôt la négociation de version pour qu'aucun équipement du chemin ne puisse supposer sans risque qu'il n'existe qu'une seule version. La RFC 9368 définit le mécanisme de négociation compatible qui permet à un serveur de faire passer une connexion de la version 1 à la version 2 sans aller-retour supplémentaire.
Firefox qui implémente la version 2, c'est une moitié du chemin. L'autre moitié, ce sont les serveurs qui la proposent. Si vous exploitez un frontal qui termine HTTP/3, vérifier si votre pile sait proposer la version 2 est un point raisonnable pour la prochaine fenêtre de maintenance, non parce que cela aide aujourd'hui, mais parce qu'un protocole à version unique est un protocole qui cesse d'évoluer.
Ce qu'il faut vérifier de votre côté du fil
Trois points, par valeur décroissante.
Publiez-vous un enregistrement de ressource HTTPS ? Si vous servez HTTP/3, c'est le changement au plus fort effet mesurable sur les premières connexions. Annoncez h3 en ALPN, ajoutez les indications d'adresses, gardez un TTL raisonnable.
Y a-t-il quelque chose sur votre chemin de sortie qui traite l'UDP 443 comme suspect ? Le trafic version 2 paraîtra inconnu à tout équipement qui reconnaît la version 1 par motif d'octets. Cet équipement était déjà un handicap pour HTTP/3 en général. C'est une bonne occasion de le trouver.
Mesurez-vous encore le temps de connexion comme un chiffre unique ? Avec une mise en course aussi agressive, une moyenne cache la partie intéressante. Ce qui compte maintenant, c'est la queue de distribution : la part de connexions où la tentative gagnante était la deuxième ou la troisième, qui vous dit quelque chose de réel sur les chemins qu'empruntent vos utilisateurs.
Le reste de la version
Les changements de plateforme sont copieux pour une version mineure. La fonction CSS attr() n'est plus limitée à content et s'utilise dans n'importe quelle propriété, avec typage et valeurs de repli, donc width: attr(data-size px) fonctionne. De nouvelles fonctions progress() et alpha() arrivent, et font-width s'installe comme nom moderne de font-stretch, qui reste un alias hérité.
En JavaScript, Promise.allKeyed() et Promise.allSettledKeyed() acceptent un objet de promesses et renvoient les résultats par clé plutôt que par position dans un tableau, ce qui supprime toute une catégorie de jonglage d'indices. Les chargements de modules en échec ne sont plus mis en cache, donc un module tombé sur une erreur réseau ou un mauvais type MIME est réessayé une fois le serveur rétabli, au lieu de rester cassé pour la durée de vie de la page.
WebTransport gagne les groupes d'envoi pour le partage de bande passante et la priorisation de flux, une méthode exportKeyingMaterial() pour dériver des secrets partagés depuis la session TLS, et une propriété draining pour l'arrêt en douceur. WebAssembly gagne le format de section d'import compact et la proposition d'arithmétique large, dont i64.add128 et i64.mul_wide_u.
Sous Linux, la version corrige un bogue qui empêchait les machines de se mettre en veille après une longue session de navigation, plus des blocages de barre d'outils et de bande d'onglets et des interruptions de flux audio en arrière plan. Dans l'interface, la barre d'adresse peut afficher un compteur de traqueurs bloqués, et les conteneurs peuvent être réordonnés dans les réglages.
Sources et pour aller plus loin
- Firefox 155 pour les développeurs, MDN, 1er septembre 2026
- Firefox 155 Available With Faster Page Loads Via Happy Eyeballs v3, QUIC v2 For HTTP/3, Phoronix, 31 août 2026
- Firefox 155 Brings Faster Page Loading, Tracker Counts, Linuxiac
- Happy Eyeballs Version 3: Better Connectivity Using Concurrency, brouillon IETF
- RFC 9369, QUIC Version 2
- RFC 9368, Compatible Version Negotiation for QUIC
Questions fréquentes
Qu'apporte réellement Happy Eyeballs v3 par rapport à la v2 ?
La version 2 traitait des familles d'adresses. Elle interrogeait AAAA et A, triait les résultats et lançait les tentatives de connexion avec un léger décalage entre elles, pour qu'un chemin IPv6 inaccessible ne bloque pas la page. La version 3 ajoute les types d'enregistrement SVCB et HTTPS à ce tableau. Le navigateur émet la requête HTTPS en premier, parce que cet enregistrement peut transporter à la fois la liste des protocoles applicatifs pris en charge par le serveur et des indications d'adresses, puis met en course l'ensemble obtenu. Concrètement, IPv6 contre IPv4 et HTTP/3 contre HTTP/2 se décident désormais dans la même course parallèle, au lieu de deux décisions séquentielles distinctes.
Faut-il un enregistrement DNS HTTPS pour que mon site en profite ?
Vous y gagnez dans tous les cas, parce que la course supprime les blocages liés à une famille d'adresses cassée. Vous y gagnez davantage avec un enregistrement HTTPS. Sans lui, un navigateur qui veut HTTP/3 doit d'abord se connecter en TCP et découvrir HTTP/3 dans un en-tête de réponse Alt-Svc, ce qui coûte un aller-retour et ne sert que pour la visite suivante. Avec un enregistrement HTTPS qui annonce h3, le client peut tenter QUIC dès la toute première connexion. Si vous servez déjà HTTP/3 sans avoir publié d'enregistrement HTTPS, c'est le changement le plus rentable à faire dans votre zone cette semaine.
Qu'est-ce que QUIC version 2 et pourquoi un serveur le choisirait ?
QUIC version 2, spécifié dans la RFC 9369, est volontairement presque identique à la version 1 en comportement. Ce qui change, c'est l'encodage sur le fil de quelques constantes : numéro de version, sels, valeurs de types de paquets. Son but est de lutter contre l'ossification. Quand une seule version d'un protocole a jamais circulé, les équipements intermédiaires finissent par graver dans le dur des hypothèses sur ses octets, et le protocole devient impossible à faire évoluer. La version 2 donne aux opérateurs une seconde version à exercer, via le mécanisme de négociation compatible de la RFC 9368, pour que le chemin reste souple. Les utilisateurs n'y gagnent pas de vitesse. Le protocole y gagne un avenir.
Est-ce que cela peut casser quelque chose sur mon réseau ?
Le vrai risque n'est pas le navigateur, ce sont les équipements du chemin. Si un boîtier en sortie ne reconnaît QUIC version 1 que par sa signature d'octets, le trafic version 2 peut être traité comme de l'UDP inconnu. C'est la même catégorie d'équipement qui gère mal l'UDP 443 en général. Si vous autorisez déjà HTTP/3 en sortie, rien ne change pour vous. Si vous bloquez ou bridez l'UDP 443, vous forciez déjà les clients à revenir en TCP et c'est toujours le cas, sauf que le repli intervient maintenant après une tentative parallèle et non séquentielle, donc vos utilisateurs le ressentent moins.
Qu'y a-t-il d'autre dans Firefox 155 ?
Côté plateforme, la fonction CSS attr() fonctionne dans n'importe quelle propriété et plus seulement dans content, et de nouvelles fonctions progress() et alpha() arrivent, ainsi que font-width comme nom moderne de font-stretch. JavaScript gagne Promise.allKeyed() et Promise.allSettledKeyed(), qui prennent un objet de promesses et renvoient les résultats par clé plutôt que par position, et les chargements de modules en échec ne sont plus mis en cache. WebTransport gagne les groupes d'envoi, exportKeyingMaterial() et une propriété draining. Sous Linux précisément, la version corrige un bogue qui empêchait la machine de se mettre en veille après une longue session de navigation.