Comparison of HTTP/2 and HTTP/3 improving WordPress speed

HTTP/2 and HTTP/3 on WordPress: What Actually Improves Speed

, , , ,

Series: WordPress Performance on DirectAdmin (Rocky Linux 9)

Phase 5: Apache & Server Layer — Part 19 of 30

Introduction: HTTP/2 and HTTP/3—Do They Matter for WordPress?

HTTP/2 and HTTP/3 are modern transport protocols intended to address the performance limitations of HTTP/1.1. For WordPress sites on DirectAdmin (Rocky Linux 9), enabling these protocols can improve front-end load times—especially for resource-heavy themes and plugins. However, the gains vary depending on site, network, and stack configuration. This article details how these protocols work, what speed improvements are realistic, and how to enable and validate them safely in a DirectAdmin-managed environment.

How HTTP/2 and HTTP/3 Change WordPress Performance

  • HTTP/2 introduces multiplexing, header compression, and server push. It reduces latency by allowing multiple requests per TCP connection.
  • HTTP/3 builds on HTTP/2, using QUIC over UDP to avoid head-of-line blocking, further reducing latency (especially for users on unreliable networks).

Both protocols are backward-compatible; clients that don’t support them fall back to HTTP/1.1. For most WordPress sites, the main benefits are faster delivery of static assets (CSS, JS, images). Dynamic PHP response times are unaffected—but the perceived load time improves.

DirectAdmin, Rocky Linux 9, and Protocol Support

DirectAdmin on Rocky Linux 9 typically deploys Apache (with or without NGINX as a reverse proxy) and PHP-FPM. By default, Apache supports HTTP/2 when built with the mod_http2 module. HTTP/3 support is newer and requires recent versions of NGINX or Apache (with mod_h3), and appropriate OpenSSL/QUIC libraries.

  • DirectAdmin’s custombuild tool manages webserver and module versions.
  • Enabling these protocols may require custom webserver template edits for per-domain or global rollout.
  • No changes to PHP-FPM pools are required for protocol upgrades.

Assessing Real-World Speed Gains

  • HTTP/2 yields the most benefit for WordPress sites with many small assets (themes/plugins with many CSS/JS files).
  • HTTP/3 can improve initial load time over lossy or high-latency networks, but the gains are often modest on stable connections.
  • Dynamic PHP page generation speed is unchanged; perceived speed may improve due to faster asset loading.
  • Protocol upgrades do not fix slow plugin queries, slow database, or backend bottlenecks.

Checklist: Before You Begin

  • Have SSH/root access and a working backup.
  • Check DirectAdmin’s custombuild version (/usr/local/directadmin/custombuild/build version); update if needed.
  • Test on a staging domain before deploying to production.
  • Review existing Apache/NGINX template overrides in /usr/local/directadmin/data/templates/.

Step 1: Enable HTTP/2 Support (Apache)

Check Apache Version and mod_http2 Status

sudo httpd -v
sudo httpd -M | grep http2

DirectAdmin’s Apache builds usually include mod_http2 on Rocky Linux 9. If missing, update/rebuild Apache via custombuild:

cd /usr/local/directadmin/custombuild
sudo ./build update
sudo ./build apache

Enable HTTP/2 Globally

sudo sed -i '/^#LoadModule http2_module/s/^#//' /etc/httpd/conf.modules.d/10-h2.conf

Then, edit the main SSL vhost template. For global changes:

sudo cp /usr/local/directadmin/data/templates/virtual_host2_secure.conf \
    /usr/local/directadmin/data/templates/custom/virtual_host2_secure.conf

Insert this line inside the <VirtualHost *:443> block:

Protocols h2 http/1.1

Rebuild Apache configs for all domains:

sudo /usr/local/directadmin/custombuild/build rewrite_confs

Warning: This step restarts Apache and may cause a brief HTTP service interruption.

Step 2: Enable HTTP/2 for NGINX Reverse Proxy (if used)

Check if NGINX is enabled as a reverse proxy:

sudo systemctl status nginx

Update the NGINX SSL vhost template:

sudo cp /usr/local/directadmin/data/templates/nginx_server_secure.conf \
    /usr/local/directadmin/data/templates/custom/nginx_server_secure.conf

After the listen ... ssl; line, add:

listen 443 ssl http2;

Rebuild configs and reload NGINX:

sudo /usr/local/directadmin/custombuild/build rewrite_confs
sudo systemctl reload nginx

Step 3: Enabling HTTP/3 (QUIC)

NGINX with HTTP/3

DirectAdmin’s custombuild must be at least v2.0.0 and NGINX 1.25+ for HTTP/3 support. Confirm versions:

cd /usr/local/directadmin/custombuild
sudo ./build versions | grep nginx

Upgrade if needed (service interruption possible):

sudo ./build update
sudo ./build nginx

Edit the NGINX SSL vhost template as above. After your listen 443 ssl http2; line, add:

listen 443 quic reuseport;
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_early_data on;
http3 on;

Ensure UDP port 443 is open in firewalld:

sudo firewall-cmd --permanent --add-port=443/udp
sudo firewall-cmd --reload

Rebuild configs and reload NGINX:

sudo /usr/local/directadmin/custombuild/build rewrite_confs
sudo systemctl reload nginx

Warning: HTTP/3 is still new in NGINX; test thoroughly before deploying to production. Some clients may experience issues.

Step 4: Testing and Validation

Quick Protocol Checks

curl -I --http2 https://yourdomain.com
curl -I --http3 https://yourdomain.com  # requires curl 7.66+

To benchmark protocol impact, use wrk or k6:

wrk -t4 -c32 -d30s --latency https://yourdomain.com
# or
k6 run -e HOST=https://yourdomain.com script.js

Check logs for errors:

sudo tail -f /var/log/httpd/error_log
sudo tail -f /var/log/nginx/error.log

Validate WordPress Functionality

  • Run core and plugin updates with WP-CLI to confirm site health:
cd /home/USER/domains/yourdomain.com/public_html
wp core verify-checksums
wp plugin status

Operational Tips and Troubleshooting

  • Monitor logs after rolling out protocol changes for at least 24 hours.
  • If you see SSL errors, verify cipher suite compatibility (TLSv1.3 is required for HTTP/3).
  • For per-domain overrides, duplicate the relevant template in custom/ and rebuild configs.
  • Do not alter PHP-FPM pool configs—protocol changes are handled at the webserver layer only.
  • Revert templates and rebuild configs to roll back any problematic changes.

Good Starting Values and Defaults

  • Enable HTTP/2 on all SSL-enabled sites by default.
  • Enable HTTP/3 only if you have a recent NGINX build and can test across multiple clients/browsers.
  • Keep ssl_protocols TLSv1.3; in your configs for HTTP/3.
  • Monitor error_log and run basic load testing after each protocol upgrade.

Summary: What Actually Improves Speed?

  • HTTP/2 almost always improves perceived speed on WordPress by multiplexing asset requests.
  • HTTP/3 offers additional latency improvements, but the difference is marginal for stable networks.
  • For the majority of sites, enabling HTTP/2 is a safe, high-impact win. HTTP/3 should be considered experimental on production unless thoroughly validated.
  • Performance bottlenecks in PHP, the database, or slow plugins are not addressed by protocol upgrades—profile and optimize those separately.

Note: This article offers general technical guidance. Validate all configurations in a safe environment before applying them to production.

Previous: Understanding .htaccess Performance Rules for WordPress

Next: How to Identify Slow Apache Requests in a WordPress Site

Smart reads for curious minds

We don’t spam! Read more in our privacy policy