Network Protocols Revisited: Make Fewer, Smarter Requests

Networking remains the foundation of front-end performance. A request begins with a DNS lookup, then a TCP and TLS handshake, each adding latency before a single byte arrives. In 2021, the practical levers are reducing those round trips and choosing the right protocol for the job.

HTTP/2 is now ubiquitous. The protocol allows multiplexing — many requests sharing a single connection — which is a major shift from HTTP/1.1's single request per connection. This makes the practice of domain sharding largely irrelevant; in fact, splitting resources across domains can hinder HTTP/2 performance by breaking the shared connection.

Despite HTTP/2's multiplexing, a server can still prioritize or delay certain resource types, which can hurt the delivery of critical assets. A best practice is to avoid relying solely on server-side prioritization. Instead, aim for fewer, more direct requests. Since HTTP/2 removes much of the overhead of connection setup, the old "concat all files" approach is also less attractive, but aggressive file splitting into hundreds of small files is poor practice too. A balance is needed.

When one connection can carry many streams, the network layer pushes the bottleneck upward: to the number of unique hosts you connect to, to the latency of DNS and TLS, and to the efficiency of your preload hints.

The Case for HTTP/3 and QUIC

HTTP/3, built on QUIC, is the next step. It runs over UDP, which solves the problem of head-of-line blocking at the transport layer. In TCP, a lost packet stalls the entire connection even if unrelated data was already received. QUIC isolates this, so a single lost packet only delays its own stream. This is most noticeable on high packet-loss networks, like mobile connections.

Another core benefit is the 0-RTT connection setup. While TCP + TLS typically require one or more round trips to establish a connection, a returning QUIC client can send data immediately with its first packet. This yields large gains for repeat visits.

At the time of writing, HTTP/3 is not mainstream but is maturing. Browser support is present in most evergreen browsers (Chrome, Edge, Firefox, Safari as of 2021) often behind flags, and services like Cloudflare and Fastly serve it. If you can, testing on a staging environment through a CDN that supports HTTP/3 is worthwhile.

Even with HTTP/3, the fundamentals don't change: eliminate render-blocking resources, defer non-critical scripts, and compress text. A modern front-end stack relies on less — and more focused — network activity.

The Hidden Costs of Third Parties

One of the biggest contributors to page bloat is third-party scripts. Think of all the trackers, ad widgets, and social buttons on a page. Each one represents an additional DNS lookup, connection, and potential JavaScript execution that you don't control.

The performance model here is stark. A modern page can have hundreds of third-party HTTP requests. Research in 2020 suggested that requests to third parties often needed to wait two round trips: one for DNS+TCP+TLS for the third-party origin, and another one to resolve client-side redirects (e.g., URL shorteners or consent wrappers). This latency is often hidden from web performance monitoring.

To keep this under control, establish a budget for third-party requests. Monitor the actual origins your page connects to in your production environment, not just the dev tools view. Check whether each script is needed, whether its async/defer flags are set, and whether it could be loaded via a single bundled wrapper instead of many discrete tags.

Content delivery networks provide a tangible trick here: many CDNs can bundle or proxy third-party requests, routing them through an origin closer to the user. This can reduce DNS/connection overhead and make use of keep-alive connections, simplifying the connection count that a browser has to handle. When selecting a CDN or cloud provider, pay attention to whether such “third-party acceleration” is available.

Core Web Vitals

The performance dial in 2021 is tuned to Google’s Core Web Vitals, a set of user-focused metrics that search engine rankings partially depend on. These three metrics are:

  • LCP (Largest Contentful Paint): The loading performance marker. A good LCP is under 2.5 seconds.
  • CLS (Cumulative Layout Shift): Visual stability. Layout shifts happen when a button loads late and pushes content down. The good threshold is CLS below 0.1.
  • FID (First Input Delay): Responsiveness. A page may render quickly but if the main thread is busy, a click can have a perceivable delay. FID should be under 100ms.

These are best thought of as proxy metrics for computing, latency, and rendering. CTAs that load late and move the purchase button after we already hovered are a real-world CLS effect. Keeping CLS low requires explicit width/height attributes on images and videos, reserving space for ad slots, and avoiding inserting content above already displayed content.

Metrics and Tooling Are Aligned

The three core metrics are not just arbitrary numbers. All three are measured by major field tools like PageSpeed Insights, Lighthouse, CrUX (Chrome User Experience Report) and real user monitoring (RUM). To see the full picture, combine lab tests (Lighthouse) with field data (CrUX). A lab test sees the page from one vantage; field data reflects distribution: for high-traffic sites, aim for the 75th percentile of your users, not the median.

Note: LCP started out as “largest image or text block” and technology keeps shifting: in early 2021, Google quietly updated how videos are counted and how small text is treated. It pays to read the spec checks occasionally.

JavaScript: Time to Trim the Payload

JavaScript delays interactivity and often pushes other assets down. The problem: the processing cost of JS on a device is high. Executing a 200-KB (uncompressed) script can consume many times more CPU than parsing or downloading it. On mid-tier Android phones this is visible as jank and delays in First Input Delay.

Full hydration frameworks (React with SSR, Angular Universal) currently introduce a classic tension: you get server-rendered HTML fast, but then a large JS bundle downloads and executes just to repaint what the server already sent (and wire up event handlers). The emerging pattern of islands architecture is to ship only the smallest amount of JS to make each interactive component work — nothing more. Vendors and frameworks, such as Vite and Astro, push boundaries here. You don't have to rebuild on these; simply auditing where your JS bundle provides value and cutting unused libraries (e.g., dropping large date formatting utilities, charting libraries, and non-critical polyfills) can often cut bundle sizes by 30–50%.

A realistic route is making sure that:

  • You parse only what’s needed for the route. (Webpack code split points.)
  • You defer polyfills that are rarely used, e.g., those catering to very old browsers.
  • You read your bundle graph in webpack-bundle-analyzer or source-map-explorer.

Certificates, TLS, and Handshake Speed

One of the earliest opportunities to trim latency happens before a single byte of your page is even requested: the TLS handshake. A common oversight is failing to enable OCSP stapling. Online Certificate Status Protocol (OCSP) checks whether an SSL certificate has been revoked, and it was designed as a faster alternative to the older Certificate Revocation List (CRL) approach. With OCSP stapling enabled on your server, the browser avoids spending time downloading and parsing a revocation list during the handshake.

The type of certificate you choose also has measurable performance implications. There are three main validation levels:

  • Domain Validation (DV) confirms the requestor owns the domain.
  • Organisation Validation (OV) additionally validates that an organisation owns the domain.
  • Extended Validation (EV) applies the same technical checks as OV but with more rigorous, human-reviewed validation.

Technically, all of these certificate types are identical; they differ only in the information and properties they include. However, EV certificates are more expensive and slower to obtain. More critically, EV certificates have historically not supported OCSP stapling fully. Without stapling, the client must perform extra revocation checks during the TLS negotiation, which can add over 1000ms on poor connections. For optimal performance, a DV certificate with OCSP stapling enabled is the better choice—they are cheaper, easier to acquire, and avoid this latency penalty.

This concern becomes more acute with QUIC and HTTP/3, where the TLS certificate chain is the dominant variable-sized element in the handshake. Chain sizes can range from a few hundred bytes to over 10 KB. Large certificates force multiple handshake round trips, so keeping the chain small and ensuring certificates are compressed is critical for fast QUIC connections.

## IPv6 and HTTP/2 Deployment

With IPv4 address space exhausted and major mobile networks rapidly adopting IPv6, updating your DNS records to support IPv6 is a forward-looking move. Studies indicate that sites with IPv6 support can be 10–15% faster due to improvements in neighbor discovery and route optimization. Ensure your network provides proper dual-stack support, since IPv6 does not offer backwards compatibility.

Migrating to HTTP/2 remains a solid investment, and most of the web has already moved—64% of requests now run over HTTP/2. The protocol has known prioritization flaws, but it's broadly supported and generally an improvement over HTTP/1.1. One notable caveat: Chrome has removed HTTP/2 Server Push, so implementations relying on it should be revisited. Early Hints (the 103 status code) is emerging as the experimental alternative.

Deploying HTTP/2 correctly requires finding a balance between packaging assets and serving many small modules in parallel. On one side, avoiding concatenation means a single file change doesn't force a full re-download of a large bundle, reduces parsing time, and keeps individual page payloads lower. On the other side, many small files reduce the effectiveness of compression due to a lack of dictionary reuse, and browsers haven't been optimized for hundreds of resources—Chrome, for instance, triggers inter-process communication linearly with the number of resources, creating runtime overhead.

Though in-body CSS no longer blocks rendering in Chrome, it still has some prioritisation issues worth experimenting with. HTTP/2 connection coalescing can theoretically allow domain sharding over a single connection, but it's difficult to get right in practice. A decent compromise for most sites running HTTP/2 is serving around 6–10 packages, a range that also avoids major issues on legacy browsers.

Verifying Server and CDN Capabilities

It's worth checking that all your assets truly share a single HTTP/2 connection. CORS issues or a misconfigured crossorigin attribute can force browsers to open additional connections. You can verify this in DevTools by enabling the "Connection ID" column in the Network panel—all requests should share one ID unless something is misconfigured.

Server and CDN support for HTTP/2 features varies significantly. Tools like CDN Comparison can help you evaluate your options. For more advanced tuning, you can test your server's HTTP/2 prioritisation support against research from Pat Meenan, who recommends enabling BBR congestion control and setting tcp_notsent_lowat to 16KB on Linux 4.9 and later for reliable prioritisation.

While on the topic of server tuning, double-check that your HTTP/2 servers fully implement HPACK compression for response headers. Some implementations miss this feature. H2spec is a thorough—if technically dense—tool for checking protocol conformance. The HPACK compression algorithm is surprisingly effective and well worth having enabled.

Security misconfigurations also create performance and reliability problems. All browser HTTP/2 implementations run over TLS, so ensure your security headers are properly set, external plugins and trackers load via HTTPS, and both HTTP Strict Transport Security and Content Security Policy headers are present. Online scanners can check your HTTPS setup and header configuration.

Preparing for HTTP/3

HTTP/2's main remaining bottleneck is head-of-line blocking at the TCP layer, noticeable on slow or lossy networks. HTTP/3, standardised by the IETF, addresses this by replacing TCP with QUIC, which runs over UDP. In terms of features, HTTP/3 resembles HTTP/2, but under the hood it’s quite different: it integrates TLS 1.3 directly into the transport, combining what used to be two separate handshakes into a single round trip. Connection migration is supported via connection IDs in each QUIC packet, and most implementations live in user space rather than the kernel, allowing for faster protocol evolution.

Practically, requests over a QUIC connection stream independently, so a dropped packet impacts only one stream instead of blocking all requests. This means the way you package assets still matters, but you may be able to serve more, smaller files without suffering the same worst-case stalls.

HTTP/3 support is still rolling out. Chrome, Firefox, and Safari already have implementations, and several CDNs plus Google's own services (Google Analytics, YouTube) already run on it. LiteSpeed Web Server supports HTTP/3, though Apache, nginx, and IIS do not yet. If your server or CDN offers HTTP/3, early results suggest enabling it is a good idea, particularly for fetching multiple objects on high-latency connections.

For those researching the protocol further, HTTP/3 Explained and videos from Daniel Stenberg and Robin Marx provide deep dives into the specifics. You can also test your own setup at HTTP3Check.net.