Why Templ.io Supports QUIC & Why Your Web Host Should Too

First we had HTTP.

Then HTTP/2 came along and brought new features and speed improvements to the world wide web.

Now, there’s QUIC which is yet another major leap in performance as well as security, and it’s a candidate to replace HTTP/2 and become HTTP/3.

QUIC is a next generation internet protocol that is encrypted-by-default and can decrease website load times considerably, especially for mobile devices and for low bandwidth connections.

Templ.io has enabled QUIC for all our customers

At Templ.io we have already enabled QUIC for all our customer using our free of charge Google Cloud based CDN and we’re already seeing improvements on our customers’ website load times.

QUIC is an initiative by Google (as HTTP/2 was as well) and brings several major improvements:

  • Dramatically reduced connection-establishment time
  • Multiplexing without head-of-line blocking
  • Improved congestion control
  • Connection migration

Dramatically reduced connection-establishment time

HTTP/2 typically requires 2-3 roundtrip of handshakes between web browser and server for every visit before a secure connection has been established.

With QUIC on the other hand, a server can send data to a web browser without the need of a single roundtrip if they have communicated before, which can dramatically reduce the “time to first byte” or TTFB which is often measured by tools like Pingdom or Webpagetest.org.

HTTP/2 vs QUIC. Source: Google

Non-blocking loss of single packets (a.k.a “Multiplexing without head-of-line blocking”)

HTTP/2 enabled multiple streams of data in one connection, but all of its streams of data can be blocked when a single TCP packet is lost—a problem called head-of-line blocking.

QUIC, just like HTTP/2, allows for multiple streams of data in one connection but uses a more redundant way to transfer data using UDP instead of TCP. With QUIC, a loss of a single data packet won’t slow down other requests than those contained within that packet.

Improved congestion control

Congestion control is a very complex subject and I won’t dig deeper into that in this blog post. Here is a very brief summary of QUIC’s congestion control ambition from Wikipedia:

QUIC’s secondary goals include reduced connection and transport latency, and bandwidth estimation in each direction to avoid congestion.

Connection migration, from WiFi to cellular and back

QUIC was very much created with a mobile-first way of thinking and supports migration of connections from WiFi to Cellular and back.

Never again will your website stop loading completely just because your phone lost its WiFi connection for a moment.

How Much Faster?

On a well-optimized site like Google Search, connections are often pre-established, so QUIC’s faster connections can only speed up some requests—but QUIC still improves mean page load time by 8% globally, and up to 13% in regions where latency is higher.

Source: Google
Google Cloud CDN throughput after enabling QUIC. Source: Google

How To Check If Your Website Is Currently Using QUIC?

To check if your current website is being served using QUIC or not you can open up the Developer Tools panel in your web browser and go to the Network tab and look for QUIC in the Protocol column.

Check if your site is utilizing QUIC or not

If you see several rows mentioning QUIC then voilà, you’re already using QUIC and are ready to blaze pass your competition! 😉

Are you already using QUIC today or are you looking to start using it?

Let us know in the comments below!

Sources:
https://cloud.google.com/blog/products/gcp/introducing-quic-support-https-load-balancing
https://www.litespeedtech.com/products/litespeed-web-server/features/quic-support/why-use-quic
https://blog.cloudflare.com/the-road-to-quic/