Firefox 155 shipped on September 1, 2026, and the headline change is not in the interface. It is in how the browser opens a connection. Happy Eyeballs v3 is on by default, which means Firefox no longer just races IPv6 against IPv4. It queries the HTTPS DNS record alongside AAAA and A, reads the protocol list the server advertises there, and races HTTP/2 against HTTP/3 while it is at it. The first attempt that completes wins. Alongside it, Firefox now negotiates QUIC version 2 when a server offers it. If you run public services, both of those change what your DNS zone and your edge need to look like.
The short answer
Firefox 155 turns on Happy Eyeballs v3, which extends connection racing from address families to DNS record types and HTTP versions. The browser queries the HTTPS resource record before or beside AAAA and A, reads the protocol list and address hints it finds there, and attempts several paths concurrently instead of walking a sorted list. The release also negotiates QUIC version 2 for HTTP/3 when a server selects it, which matters for protocol ossification rather than for speed. For anyone running a public endpoint, the actionable part is publishing an HTTPS RR so the first connection can go straight to QUIC instead of learning about it from an Alt-Svc header.
Most browser releases are felt in the interface. This one is felt in a packet capture. Firefox 155, out on September 1, 2026, changes the first few milliseconds of every navigation, and the change is large enough that it is worth understanding from the server side even if you never open Firefox.
Happy Eyeballs stopped being about IPv6
The original algorithm existed for one reason: a client with a AAAA record and a broken IPv6 path used to sit there waiting for a TCP timeout while the user stared at a blank tab. Version 1 raced the two address families. Version 2 refined the ordering and the delays between attempts. Both were, at heart, an answer to a single question, which address family do we use.
Version 3 asks a bigger question. The draft adds the SVCB and HTTPS resource record types to the algorithm, and that changes the shape of the whole thing. The client issues the HTTPS query immediately before the AAAA and A queries, because that record can carry two useful things at once: the application protocols the server actually supports, and address hints for reaching it. The specification is explicit that implementations should not wait for every answer before starting to connect. Whatever arrives first gets raced.
So instead of resolving, sorting, and then deciding sequentially whether to try HTTP/3, Firefox now has a single parallel process that covers address family and HTTP version together. IPv6 and IPv4, HTTP/2 and HTTP/3, all in flight, and the first one to establish wins. The delays that used to protect against a stalled path are still there, but they now apply across a wider set of candidates.
The practical effect for a user is that a slow or dead path costs almost nothing. The practical effect for an operator is that the DNS zone became part of the connection performance story in a way it was not before.
Publish an HTTPS record, or keep paying a round trip
Here is the part worth acting on. If you serve HTTP/3 today and you have no HTTPS resource record in your zone, a client has no way to know that on a cold connection. It connects over TCP and TLS, reads an Alt-Svc header in the response, caches it, and uses QUIC on a later visit. The first visit, which is the one that decides whether someone stays, pays the full TCP setup anyway.
With an HTTPS RR that advertises h3 in its ALPN parameter, a version 3 client can put a QUIC attempt into the race from the very first packet, before any TCP handshake has completed. It can also use the address hints in the record, ipv4hint and ipv6hint, to start connecting without waiting for a separate A or AAAA answer to come back.
That is a zone file change, not an infrastructure project. Most managed DNS providers have supported the HTTPS record type for a while now. If you have already done the work of enabling HTTP/3 at the edge, not publishing the record means most of that work is invisible to first time visitors. Our notes on what changed in Firefox 154 cover the platform side of the previous release if you are tracking the series.
QUIC version 2 is an anti-ossification measure, not a speedup
The second networking change is easy to misread. Firefox 155 supports QUIC version 2 and uses it when a server selects it through compatible version negotiation. Nobody gets a faster page out of this.
QUIC version 2, defined in RFC 9369, is behaviourally the same protocol as version 1. What changes is a set of constants on the wire: the version number itself, the salts used to derive initial keys, the values of long header packet types. The point is to make sure that more than one version of QUIC exists in the wild.
That sounds academic until you remember what happened to TCP. Decades of middleboxes learned to recognise TCP by its byte layout, then started enforcing what they thought they saw, and the result is that shipping any genuinely new TCP option on the public internet is close to impossible. QUIC was designed to avoid that fate, partly by encrypting most of the header, and partly by exercising version negotiation early so that no device on the path can safely assume there is only ever one version. RFC 9368 defines the compatible version negotiation mechanism that lets a server move a connection from version 1 to version 2 without an extra round trip.
Firefox implementing version 2 is one half of that. The other half is servers offering it. If you run an edge that terminates HTTP/3, checking whether your stack can offer version 2 is a reasonable item for the next maintenance window, not because it helps today but because a protocol with one version is a protocol that stops evolving.
What to check on your side of the wire
Three things, in descending order of value.
Do you publish an HTTPS resource record? If you serve HTTP/3, this is the change with the biggest measurable effect on first connections. Advertise h3 in ALPN, add address hints, keep the TTL sane.
Does anything in your egress path treat UDP 443 as suspicious? Version 2 traffic will look unfamiliar to any device that pattern matches on version 1 bytes. That device was already a liability for HTTP/3 in general. This is a good excuse to find it.
Are you still measuring connection time as a single number? With racing this aggressive, an average hides the interesting part. What matters now is the tail: the fraction of connections where the winning attempt was the second or third one, which tells you something real about the paths your users are on.
The rest of the release
The platform changes are substantial for a point release. The attr() CSS function is no longer restricted to content and can be used in any property, with type support and fallbacks, so width: attr(data-size px) works. There are new progress() and alpha() functions, and font-width arrives as the modern name for font-stretch, which continues as a legacy alias.
In JavaScript, Promise.allKeyed() and Promise.allSettledKeyed() accept an object of promises and hand back results by key rather than by array position, which removes a whole category of index juggling. Failed module loads are no longer cached, so a module that failed on a network error or a wrong MIME type is retried once the server recovers instead of staying broken for the life of the page.
WebTransport gained send groups for bandwidth sharing and stream prioritisation, an exportKeyingMaterial() method for deriving shared secrets from the TLS session, and a draining property for graceful shutdown. WebAssembly gained the compact import section format and the wide arithmetic proposal, including i64.add128 and i64.mul_wide_u.
On Linux, the release fixes a bug that prevented systems from sleeping after a long browsing session, plus toolbar and tab strip unresponsiveness and interrupted background audio streams. In the interface, the address bar can now show a count of blocked trackers, and containers can be reordered in Settings.
Sources and further reading
- Firefox 155 for developers, MDN, September 1, 2026
- Firefox 155 Available With Faster Page Loads Via Happy Eyeballs v3, QUIC v2 For HTTP/3, Phoronix, August 31, 2026
- Firefox 155 Brings Faster Page Loading, Tracker Counts, Linuxiac
- Happy Eyeballs Version 3: Better Connectivity Using Concurrency, IETF draft
- RFC 9369, QUIC Version 2
- RFC 9368, Compatible Version Negotiation for QUIC
Frequently asked questions
What is actually new in Happy Eyeballs v3 compared with v2?
Version 2 was about address families. It queried AAAA and A, sorted the results, and started connection attempts with a small delay between them so an unreachable IPv6 path could not stall the page. Version 3 adds the SVCB and HTTPS resource record types to that picture. The browser issues the HTTPS query first, because that record can carry both the list of application protocols the server supports and address hints, then races across the resulting set. In practice that means IPv6 versus IPv4 and HTTP/3 versus HTTP/2 are now decided by the same parallel race rather than by two separate sequential decisions.
Do I need an HTTPS DNS record for this to help my site?
You benefit either way, because the race itself removes stalls on broken address families. You benefit more with an HTTPS record. Without one, a browser that wants HTTP/3 has to connect over TCP first and learn about HTTP/3 from an Alt-Svc response header, which costs a round trip and only helps the next visit. With an HTTPS record advertising h3, the client can attempt QUIC on the very first connection. If you already serve HTTP/3 and have not published an HTTPS RR, that is the single highest value change you can make in your zone this week.
What is QUIC version 2 and why would a server pick it?
QUIC version 2, specified in RFC 9369, is deliberately almost identical to version 1 in behaviour. What differs is the wire encoding of a handful of constants: version number, salts, packet type values. It exists to fight ossification. When only one version of a protocol has ever been seen on the wire, middleboxes start hardcoding assumptions about its bytes, and the protocol becomes impossible to evolve. Version 2 gives operators a second version to exercise, using the compatible version negotiation mechanism in RFC 9368, so the path stays flexible. Users do not get faster pages from it. The protocol gets a future.
Could this break anything on my network?
The realistic failure mode is not the browser, it is equipment in the path. If a device on the way out only recognises QUIC version 1 by its byte pattern, version 2 traffic may be treated as unknown UDP. The same class of device tends to be the one that mishandles UDP 443 in general. If you already permit HTTP/3 out of your network, nothing changes for you. If you block or throttle UDP 443, you were already forcing clients back to TCP and you still are, only now the fallback happens after a parallel attempt rather than a sequential one, so your users feel it less.
What else is in Firefox 155?
On the platform side, the attr() CSS function works in any property rather than only in content, and there are new progress() and alpha() functions plus font-width as the modern name for font-stretch. JavaScript gains Promise.allKeyed() and Promise.allSettledKeyed(), which take an object of promises and return results by key instead of by position, and failed module loads are no longer cached. WebTransport gains send groups, exportKeyingMaterial() and a draining property. On Linux specifically, the release fixes a bug that kept systems awake after a long browsing session.