I’ve lost count of the number of WordPress sites I’ve audited where every image, script, and stylesheet request queued up one after another like customers at a single checkout till. That’s what HTTP/1.1 does by default, and it’s a big part of why some sites feel sluggish even after the owner has installed a caching plugin and compressed every image on the page.
HTTP/2 fixes this at the protocol level rather than the plugin level. It lets the browser and server exchange many requests and responses over one connection at the same time, instead of opening several connections or waiting in line. In my experience, sites that move from HTTP/1.1 to HTTP/2 without changing anything else often see a noticeable drop in load time simply because the browser stops waiting around.
The good news is that enabling HTTP/2 is usually a hosting-level setting rather than something you build yourself, so this guide covers how to check what you’re currently running and the handful of ways to switch it on if it’s missing. It fits naturally alongside the other speed work covered in the step-by-step guide to building a WordPress website, since none of these changes work in isolation.
Quick Answer
Most WordPress hosts enable HTTP/2 automatically once your site runs over HTTPS, since the protocol requires an SSL certificate to work in every major browser. Check your current protocol in your browser’s developer tools first. If it isn’t on, the fix is almost always a one-click toggle in your hosting control panel or Cloudflare dashboard — not a code change.
Why This Matters
A typical WordPress page load involves dozens of separate files — the theme’s CSS, several JavaScript files, web fonts, and every image on the page. Under HTTP/1.1, browsers historically opened around six parallel connections per domain and then queued the rest, which is why techniques like combining files or using a CDN subdomain became popular workarounds.
HTTP/2 removes the need for most of those workarounds. It multiplexes requests over a single connection, compresses request headers, and lets the server prioritise which files matter most. None of this requires you to rewrite your site — it’s the transport layer underneath the same HTML, CSS, and JavaScript your site already sends. According to MDN’s HTTP/2 documentation, the protocol changes how data is framed and transported without altering HTTP semantics at all, so existing WordPress sites work over it without modification.
Since Google has repeatedly said that page speed factors into both mobile and desktop rankings, and slow sites lose visitors before content even renders, protocol-level wins like this are worth checking even if you’ve already handled caching and image optimisation.
Step-by-Step Instructions
Step 1: Check Your Current Protocol
Open your site in Chrome, right-click anywhere on the page, and choose Inspect. Go to the Network tab, reload the page, then right-click the column header row and add the Protocol column if it isn’t already showing. Look at the value next to your main document request — h2 means HTTP/2 is active, while http/1.1 means it isn’t.
If your site isn’t yet running on HTTPS, start there — HTTP/2 requires SSL in every browser that supports it, so an unencrypted site can’t use it regardless of what the server supports.
Step 2: Enable It Through Your Host
Most managed WordPress hosts and modern shared hosting plans turn HTTP/2 on by default the moment SSL is active, so there’s often nothing to configure. If your host uses cPanel, look under Domains or a dedicated HTTP/2 toggle — some hosts hide it inside their SSL or performance settings instead. If you can’t find a setting at all, that usually means it’s already handled at the server level, or your hosting plan simply doesn’t support it and you’ll need to ask their support team directly.
Step 3: Enable It Through a CDN
If your host doesn’t support HTTP/2 directly, or you’re already routing traffic through a CDN for other performance reasons, the CDN’s edge servers can serve your pages over HTTP/2 even if your origin server can’t. This setting is normally on by default in most CDN dashboards, so it’s worth a quick check rather than something you usually need to switch on manually. It also compounds well with the server response time work covered in reducing TTFB, since a faster connection and a faster server response solve two different parts of the same delay.
Step 4: Confirm LiteSpeed Cache Is Compatible
If your host runs LiteSpeed Web Server, it supports HTTP/2 and the newer HTTP/3 (QUIC) protocol natively, and a WordPress caching plugin doesn’t need any extra configuration to work alongside it. There’s no conflict between running a caching plugin and running HTTP/2 — they operate at completely different layers, one handling how pages are generated and the other handling how they’re delivered.
Step 5: Re-Test After Changes
After flipping any setting, clear your caching plugin’s cache, reload the site in an incognito window, and repeat the Network tab check from Step 1. Confirm the protocol column now shows h2 on your main document and on key static assets like CSS and JS files.
Practical Tips
- In most sites I build, HTTP/2 is already active by the time SSL goes live — checking is usually faster than trying to configure anything.
- Don’t bother combining CSS or JS files purely to reduce request counts once HTTP/2 is confirmed active — that workaround was designed for HTTP/1.1 and can actually hurt caching efficiency under HTTP/2.
- If your host offers HTTP/3 as well, there’s no reason not to enable it alongside HTTP/2 — browsers that don’t support it simply fall back automatically.
Common Mistakes
- Checking the wrong request. Some third-party scripts or ad networks load over HTTP/1.1 even when your own site runs HTTP/2 — check your main document request specifically, not a random asset in the list.
- Assuming a plugin controls it. HTTP/2 is a server and connection-level setting; no WordPress plugin turns it on, and any plugin claiming to “enable HTTP/2” is really just optimising asset delivery around it.
- Forgetting SSL is a prerequisite. If your certificate has expired or mixed content is forcing parts of the page to load over HTTP, browsers will silently drop back to HTTP/1.1 for those resources.
When to Use This vs Alternatives
HTTP/2 is worth confirming on every WordPress site since it costs nothing and requires no ongoing maintenance once it’s active. If your host genuinely doesn’t support it and won’t add it, moving to a CDN in front of your existing host is usually a smaller change than migrating your whole site to new hosting. Either approach gets you the same multiplexing benefit without touching your theme or plugins.
Conclusion
Check your Network tab for the protocol column before assuming you need to change anything — most sites already have HTTP/2 running once SSL is in place. If yours doesn’t, a host-level toggle or a CDN in front of your site will usually get you there without a single line of code.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.