Google发现互联网传输协议IETF QUIC（Quick UDP Internet Connections）能够降低Google搜索和YouTube等服务的延迟，还能提升客户端设备的吞吐量，因此Google决定在Chrome中，开始积极支持IETF QUIC。Chrome会同时支持IETF QUIC和Google QUIC协议，让原本支持Google QUIC的服务器，有时间转换到IETF QUIC。
QUIC是一种新的网络传输协议，为下一代HTTP协议HTTP/3的基础，有别于HTTP/2使用TCP协议作为对话（Session）传输层，HTTP/3在QUIC上运行，而QUIC则是基于UDP协议的实例。HTTP/3并非HTTP/1.1或HTTP/2的衍伸后继者，也不是在QUIC上的HTTP/2协议，而是以QUIC重新开发的HTTP协议。
最一开始的QUIC协议是由Google开发，并在2013年对外发布，Google也将自家的QUIC项目提交给标准组织互联网工程任务组（Internet Engineering Task Force, IETF），计划使其成为公用标准，但是之后IETF却发展出了另一个QUIC协议，虽然名称相同，但是内容却不一样，社群以gQUIC以及iQUIC区分。
gQUIC被设计用来支持Chromium的HTTPS协议，以加密的UDP发送HTTP/2影格，而IETF则是发展成为通用传输协议，也就是让HTTP以外的其他协议，包括SMTP、DNS、SSH、Telnet和NTP都能够使用。在2012到2019年初，Google在其服务和Chrome皆使用gQUIC，不过，Google也持续关注iQUIC的进展，Chromium开发人员在后期开发上，也都遵照iQUIC的标准。
Google提到，当前最新的Google QUIC版本Q050，已经和IETF QUIC有许多相似之处，但是大部分的Chrome用户，由于都还未激活特定的命令行选项，因此无法与IETF QUIC服务器通信。而现在Google决定更积极地支持IETF QUIC，将会在Chrome上激活对IETF QUIC草稿版本H3-29的完整支持。
目前有25%的Chrome稳定版用户正在使用H3-29，Google计划会在接下来数周内，增加这个数字，Chrome会同时积极支持IETF QUIC H3-29和Google QUIC Q050，让支持Q050的服务器，有足够的时间更新到IETF QUIC。
IETF QUIC的性能表现，明显优于以TCP为基础的HTTP over TLS 1.3，在Google搜索延迟少了2%，YouTube重新缓冲时间减少9%以上，桌面客户端吞吐量增加3%，而移动设备客户端吞吐量增加7%。不过，由于Chrome m85还没有支持IETF QUIC 0-RTT，Google预计当他们开始支持该功能，性能指标表现将会更好。
Google提到，后续IETF草案QUIC版本30与31，都没有破坏兼容性，因此Chrome会以H3-29会支持基础，他们也建议服务器开发者，如果要与Chrome维持互通性，在RFC完成之前，应继续维持支持H3-29，不过，如果未来IETF的草案有破坏性变更，他们将重新考量决策。