# Making Chrome QUICer

DevFeed: [Making Chrome QUICer](<https://devfeed.tech/articles/making-chrome-quicer-4191.md>)

Original publisher: [Read original article](<https://blog.chromium.org/2024/12/making-chrome-quicer.html>)

Author: Chromium Blog (noreply@blogger.com)

Published: 2024-12-17T18:09:00Z

Content type: article

Language: en

Sources: [Chromium Blog](<https://devfeed.tech/sources/chromium-blog.md>)

Topics: [web applications](<https://devfeed.tech/topics/web-applications.md>)

Tags: [cache](<https://devfeed.tech/tags/cache.md>), [chrome](<https://devfeed.tech/tags/chrome.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [dns](<https://devfeed.tech/tags/dns.md>), [features](<https://devfeed.tech/tags/features.md>), [google](<https://devfeed.tech/tags/google.md>), [http](<https://devfeed.tech/tags/http.md>), [latency](<https://devfeed.tech/tags/latency.md>), [memory](<https://devfeed.tech/tags/memory.md>), [metrics](<https://devfeed.tech/tags/metrics.md>), [none](<https://devfeed.tech/tags/none.md>), [performance](<https://devfeed.tech/tags/performance.md>), [server](<https://devfeed.tech/tags/server.md>), [tls](<https://devfeed.tech/tags/tls.md>), [youtube](<https://devfeed.tech/tags/youtube.md>)

## AI overview

Chrome's HTTP/3 performance work adds ORIGIN frame support for connection coalescing and Preferred Address support to reduce round-trip time. The article explains how avoiding unnecessary connections can reduce DNS, handshake, TLS, CPU, memory, and latency costs.

## Source excerpt

In October 2020, Chrome enabled HTTP/3 by default. HTTP/3 (RFC 9114) runs over IETF QUIC (RFC9000). Default-enabling HTTP/3 in Chrome resulted in improved performance compared not only HTTP/1 and HTTP/2, but also Google QUIC. Benefits included reduced Google search latency and fewer rebuffers for YouTube. The journey to optimizing performance did not end when HTTP/3 was default enabled. Recent advancements include the implementation of the HTTP/3 ORIGIN frame (RFC 9412) and Server's Preferred Address (RFC 9000 Section 9.6). The former enhances connection coalescing, while the latter reduces a connection's round trip time (RTT). Both features have been enabled by default in M131, which was released to Stable on 11/19. ORIGIN Frame When a connection is established for a specific hostname, the server's certificate typically contains numerous other hostnames for which the server is authoritative. However, a client cannot immediately send requests for those other hostnames on that connection without first performing a DNS lookup for the other hostname and verifying that the IP address of the connection matches the resolved address. This additional DNS resolution introduces latency and significantly reduces the likelihood of connection pooling due to potential IP mismatches. The metrics from Chrome indicate that nearly 20% of HTTP/3 connections would be unnecessary if not for this IP mismatch. Creating a new connection, even with QUIC 0-RTT, is expensive in terms of latency, memory, and CPU usage. This is because: DNS resolution adds latency unless cached locally in Chrome's DNS cache. Both client and server must send multiple packets to complete a QUIC handshake. TLS necessitates CPU-intensive asymmetric cryptography on both ends. The congestion controller begins in its default state, potentially leading to under or over-sending. 0-RTT might fail. Non-safe requests aren't sent via 0-RTT. More connections consume more memory. Additionally, features like HTTP priorities (R