A lot of WordPress performance work focuses on what’s in the page: images, scripts, plugins and themes. Those matter enormously. But there’s another layer that’s easy to overlook: how the page is delivered. The protocol your server speaks and the compression it uses affect how quickly every file reaches the visitor’s browser.
Modern protocols like HTTP/2 and HTTP/3, and modern compression like Brotli, can make a noticeable difference, especially for visitors on mobile networks or far from your server. Many sites already benefit through their host or CDN without realising it. Others are still running older settings from years ago.
Here’s what these technologies do, whether you need to change anything and how to check what your site actually uses.
A quick history of HTTP
HTTP is the protocol browsers use to request web pages and the files they depend on.
HTTP/1.1
For many years, sites used HTTP/1.1. Its main limitation was that each connection could only handle one request at a time. Browsers opened several connections per domain to work around this, but pages with dozens of files still waited in queues. That’s where old performance advice came from: combine files, use image sprites and spread assets across multiple domains.
HTTP/2
HTTP/2 allows many requests and responses to travel over a single connection at the same time, called multiplexing. It also compresses headers and makes more efficient use of connections.
For WordPress sites with many stylesheets, scripts and images, HTTP/2 removes much of the queueing that slowed HTTP/1.1. It’s supported by all modern browsers and typically requires HTTPS in practice.
HTTP/3
HTTP/3 keeps the benefits of HTTP/2 but runs over a different transport protocol called QUIC, which uses UDP instead of TCP. Its advantages show up mostly on less reliable networks:
- Faster connection setup, combining the connection and encryption handshakes.
- Better handling of packet loss. With HTTP/2 over TCP, one lost packet can delay everything on the connection. QUIC handles streams independently, so one lost packet doesn’t block the others.
- Connection migration, letting connections survive network changes, such as a phone switching from Wi-Fi to mobile data.
Visitors on mobile networks, in places with unreliable connectivity or far from your server benefit most.
Compression: gzip and Brotli
Text-based files, like HTML, CSS, JavaScript, JSON and SVG, compress very well. Compressing them before sending reduces transfer size dramatically, often by 70 percent or more.
gzip
gzip has been the standard compression method for decades. Almost every server supports it, and it’s usually enabled by default on hosting.
Brotli
Brotli is a newer compression algorithm that typically produces smaller files than gzip for web content, particularly for text files like CSS and JavaScript. All modern browsers support it over HTTPS.
Brotli at high compression levels is slower to compress, so it’s best used either with pre-compressed static files or at moderate levels for dynamic content. CDNs often handle this automatically.
Newer compression methods are emerging too, but Brotli and gzip remain the practical standards for most sites today.
Do you need to change anything?
Many sites already have some or all of these:
- Managed WordPress hosts commonly enable HTTP/2, often HTTP/3, and Brotli or gzip compression.
- CDNs usually support HTTP/2 and HTTP/3 to visitors and compress content automatically, regardless of what your origin server supports.
- Self-managed servers may need configuration, depending on the web server version and modules installed.
Before changing anything, check what your site currently uses.
How to check your site
Browser developer tools
Open the network tab, right-click the column headers and enable the Protocol column. You’ll see h2 for HTTP/2 and h3 for HTTP/3 next to each request. Note that the first visit to a site may use HTTP/2 even when HTTP/3 is available, because browsers discover HTTP/3 support through a header on an initial response and use it on subsequent connections.
Check the response headers for content-encoding. You’ll see br for Brotli or gzip for gzip.
Command line
| <code>curl -sI –http2 https://example.com | head -1 |
|---|---|
| curl -sI -H "Accept-Encoding: br" https://example.com | grep -i content-encoding</code> |
Online testing tools also report protocol support and compression.
Enabling HTTP/2 on Nginx
On Nginx, HTTP/2 is enabled per server block alongside HTTPS. In recent Nginx versions:
In older versions, HTTP/2 was enabled by adding http2 to the listen directive instead. Check your version’s documentation.
On Apache, HTTP/2 requires the http2 module and usually the event MPM, then a Protocols directive in the virtual host configuration.
Enabling HTTP/3
HTTP/3 support in web servers has matured more recently. Nginx added HTTP/3 support in version 1.25 and later, but it requires a build with QUIC support and configuration for UDP on port 443, plus an Alt-Svc header to advertise HTTP/3 to browsers. Your firewall must allow UDP traffic on port 443.
For many site owners, the simplest way to offer HTTP/3 is through a CDN or a host that supports it. The CDN speaks HTTP/3 to visitors and connects to your origin however it likes. That gives visitors the benefit without changing your server.
If you run your own server and want native HTTP/3, test carefully on staging, check that your Nginx build includes QUIC support and monitor for issues. HTTP/2 remains a solid fallback, and browsers automatically use it when HTTP/3 isn’t available.
Enabling Brotli
On Nginx, Brotli support comes from a separate module, not included in every build. Some distributions and repositories provide packaged modules. Once installed:
Keep gzip enabled as a fallback for clients that don’t support Brotli:
Moderate compression levels balance size and CPU usage for dynamic content. For static files, pre-compressing at higher levels during deployment gives the smallest files without runtime cost.
Don’t compress images like JPEG, PNG, WebP or AVIF with gzip or Brotli. They’re already compressed, and recompressing wastes CPU for no gain.
If you use a CDN, it may apply Brotli compression for visitors regardless of your origin’s settings. Check your CDN’s settings.
Old advice to stop following
Some performance techniques from the HTTP/1.1 era are now unnecessary or even harmful:
- Domain sharding, splitting assets across several subdomains to get more connections, now adds extra connection setup and defeats HTTP/2 multiplexing.
- Aggressively combining all CSS and JavaScript into single huge files. With HTTP/2, several smaller files load efficiently, and combining everything can hurt caching, because changing one small part invalidates the whole combined file.
- Image sprites for icons are less necessary; inline SVGs or individual files work well.
- HTTP/2 server push, once promoted, has been removed from major browsers. Use preload hints instead.
What these technologies won’t fix
Faster protocols and better compression reduce delivery overhead, but they don’t fix:
- Slow server response times caused by heavy PHP, slow database queries or missing caching.
- Huge images and videos.
- Too much JavaScript running in the browser.
- Render-blocking resources and poor loading order.
Think of protocols and compression as making the road faster. You still need to make the vehicle lighter.
Checking your CDN and origin separately
If you use a CDN, check both layers. The protocol and compression visitors see come from the CDN; the connection between the CDN and your server may use different settings. Improving the origin still matters for cache misses, admin traffic and requests the CDN can’t cache. Test the origin directly, if your setup allows, as well as through the CDN.
A sensible order of priorities
When improving delivery on a WordPress site, I work through these in order: make sure HTTPS is correct, confirm HTTP/2 is active, enable Brotli or gzip for text files, put a CDN in front for global audiences and offer HTTP/3 where the CDN or host supports it. Each step is low risk and quick to verify.
These steps are usually a one-time setup, so they’re well worth an afternoon.
Watch for regressions
Server upgrades and CDN changes can quietly switch protocols or compression off. Add a quick protocol and content-encoding check to your post-change testing routine.
Frequently asked questions
Does my WordPress site support HTTP/2?
Check the Protocol column in your browser’s network tab. Most HTTPS sites on modern hosting or behind a CDN already use HTTP/2.
Is HTTP/3 worth enabling?
It helps most for mobile visitors and those on unreliable networks. The easiest way to get it is through a CDN or host that supports it.
Should I use Brotli or gzip?
Use Brotli where supported, with gzip as a fallback. Brotli typically produces smaller files for web content.
Do I still need to combine CSS and JavaScript files?
Usually not. With HTTP/2, several smaller files load efficiently. Focus on removing unused code and loading only what each page needs.
Final thoughts
Modern protocols and compression quietly speed up every request your WordPress site serves. Make sure HTTP/2 is active, offer HTTP/3 through your CDN or a properly configured server, use Brotli with gzip as a fallback, stop following outdated HTTP/1.1 workarounds and verify everything with developer tools. Then keep working on the content itself, because the fastest delivery in the world can’t make a heavy page light.
