WordPress on Hetzner: A Practical Performance Story

The first time you move a production site, you don’t fear the migration—you fear the quiet moment after, when traffic returns and you find out what you missed.

A missed header. A cache that never warms. A backup plan that looks great on paper and fails at 2 a.m.

The goal isn’t to build the fanciest stack—it’s to make WordPress on Hetzner so predictable that performance stops being a weekly project.

If you’re running WordPress on Hetzner, that moment matters even more, because Hetzner gives you a lot of control—and control is either leverage or liability.

The moment you realize “fast hosting” isn’t the point

Most hosting decisions start with a speed test and end with a bill.

Then a client asks why the site is slow only on product pages. Or why the admin feels sticky. Or why the server is “fine” but Core Web Vitals aren’t.

For WordPress on Hetzner, performance is less about raw CPU and more about eliminating friction across the whole request path.

Here’s the request path you’re really optimizing:

• DNS and TLS negotiation
• Static asset delivery and caching headers
• PHP execution and object caching
• Database query patterns and indexing
• Background jobs (cron) and third-party APIs
• Backups and storage I/O

A cheap, powerful server can still feel slow if those pieces aren’t aligned.

The hidden tax: generic stacks on non-generic infrastructure

Hetzner is cost-effective because it’s straightforward. You get predictable compute, clear networking, and simple scaling.

But many WordPress stacks are designed as if you’re on a managed platform with opinionated defaults.

That mismatch creates “performance tax” in small, annoying ways: overcaching the wrong pages, undercaching static assets, or relying on cron behavior that breaks under real traffic.

A narrative arc: from “it works” to “it’s dependable”

There’s a phase where a WordPress server is alive, and a later phase where it’s trustworthy.

If your goal is to make WordPress on Hetzner feel like a calm, boring utility (the highest compliment in ops), build around three outcomes:

1. Stable response times under real traffic

2. Fast recoverability (restore is tested, not imagined)

3. Predictable costs as your sites scale

The best optimization is the one you can keep six months from now.

A simple architecture that holds up

You don’t need an exotic setup to get serious results.

A practical baseline for WordPress on Hetzner often looks like:

• Nginx (or Apache, but Nginx tends to be simpler for caching and static files)
• PHP-FPM tuned for your CPU/RAM
• MariaDB with sane buffer sizes
• A page cache layer (plugin or server-level)
• Optional Redis object cache for dynamic sites
• Offsite backups to Hetzner Storage Box or another provider

If you like to reason from first principles, keep it boring and measurable.

The “speed stack” that doesn’t fight WordPress

When people say “cache it,” they usually mean “make the homepage fast.”

The work is making the rest fast without breaking logged-in behavior, carts, or personalization.

For WordPress on Hetzner, the winning move is to cache aggressively where it’s safe—and to be surgical everywhere else.

Step 1: Decide what can be public-cached

Start by labeling your routes:

• Public, cacheable: blog posts, docs pages, landing pages
• Semi-dynamic: category pages, search results, filtered archives
• Private/dynamic: checkout, account, cart, wp-admin

Then encode those decisions into your caching rules.

Concrete examples that usually work:

• Cache HTML for anonymous users with a short TTL (e.g., 5–30 minutes)
• Purge on publish/update
• Bypass cache on cookies like `wordpress_logged_in_*` and WooCommerce session cookies

If you need a neutral reference point for HTTP caching semantics, the MDN Cache-Control guide is a solid refresher.

Step 2: Make static assets “boring fast”

Static files are where you can get easy wins.

Set long cache lifetimes for versioned assets and ensure compression is enabled.

A quick checklist:

• Serve images in modern formats when possible (WebP/AVIF)
• Use `Cache-Control: public, max-age=31536000, immutable` for fingerprinted assets
• Enable Brotli or gzip
• Avoid shipping unneeded icon fonts and JS bundles

Your fastest page is the one that ships less.

Step 3: Use object caching for the right sites

Redis object cache can help, but it’s not magic.

It shines when:

• You have logged-in users
• You have a busy WooCommerce store
• You have complex queries repeated across requests

It’s less impactful when your site is mostly static and your page cache already handles anonymous traffic.

For implementation details, the Redis documentation is the authoritative reference.

The reliability layer: backups, restores, and the “oops” budget

Most teams don’t lack backups. They lack restores.

You only learn whether your plan works when you try to rebuild a site from scratch.

If WordPress on Hetzner is your production foundation, your restore time is a product feature.

A backup pattern that respects real-world failure

Aim for at least:

• Daily database backups (more frequent for stores)
• Daily file backups (or incremental)
• Offsite storage (same provider is fine, same server is not)
• A documented restore runbook

Hetzner Storage Box is often used as an offsite target, but the real win is the discipline:

1. Automate the backup job

2. Encrypt at rest or in transit

3. Test restore monthly

A practical “restore test” is simple: spin up a clean VM, restore the database + `wp-content`, update DNS hosts file locally, and confirm:

• Homepage renders
• Admin login works
• Media library loads
• Critical flows (checkout/contact forms) succeed

The oops budget: what downtime are you actually willing to buy?

When your stack is affordable, it’s tempting to underinvest in resilience.

Instead, decide your acceptable “oops budget”:

• 5 minutes? You need monitoring + quick rollback.
• 1 hour? You need tested restores and snapshots.
• 1 day? You still need offsite backups, because ransomware doesn’t care.

Cost control without starving performance

The reason many people choose WordPress on Hetzner is simple: value.

But cost control isn’t only “cheaper servers.” It’s avoiding recurring complexity.

The cheapest stack is the one you don’t have to babysit.

Practical levers that keep spend predictable

Use these levers in roughly this order:

1. Page caching before vertical scaling

2. Asset optimization before adding a CDN you don’t understand

3. Database hygiene before more RAM

4. Right-sizing PHP-FPM before adding more CPU

5. Move heavy jobs off-request (image processing, imports)

If you’re running multiple sites, standardize the baseline:

• Same Nginx template
• Same PHP version and settings
• Same backup destination
• Same monitoring checks

Standardization is how agencies keep margins intact.

A quick example: the “busy blog” pattern

If you publish often and hit the front page with traffic spikes:

• Cache anonymous HTML
• Preload or warm cache after publish
• Serve images with long-lived headers
• Add object cache only if admin/editor experience is slow

This keeps WordPress on Hetzner fast without turning the stack into a science project.

Why CloudStrap exists (and what it’s trying to remove)

There’s a category of WordPress tooling that’s technically impressive and operationally exhausting.

CloudStrap’s premise is the opposite: if you host on Hetzner, you shouldn’t need a maze of toggles to get reasonable defaults.

CloudStrap is about reducing setup friction so Hetzner’s strengths show up in real page loads.

Think “infrastructure-aware utilities” that make common tasks straightforward:

• Performance-focused defaults that respect Hetzner-style deployments
• Lightweight tools that don’t duplicate half your stack
• Clear configuration you can explain to a teammate

If you’re running WordPress on Hetzner across multiple sites, the real benefit is repeatability: fewer custom snowflakes, fewer surprises.

“The goal isn’t to build the fanciest stack—it’s to make WordPress on Hetzner so predictable that performance stops being a weekly project.”

A practical 7-day plan to tighten your stack

If you want momentum without breaking production, here’s a one-week plan that fits real schedules.

Small, disciplined changes beat weekend rewrites.

Day 1: Measure what matters

• Record baseline: TTFB, LCP, full load time
• Enable server metrics (CPU, RAM, disk I/O)
• Capture slow queries if possible

Use a consistent test location and repeat tests after each change.

Day 2: Fix caching headers for static assets

• Add long cache headers for versioned assets
• Confirm compression
• Remove unused assets where obvious

Day 3: Implement page caching safely

• Cache anonymous HTML
• Bypass logged-in and cart/checkout routes
• Add purge on publish/update

Day 4: Tune PHP-FPM to your box

• Set realistic `pm.max_children`
• Avoid memory thrash
• Restart gracefully and monitor error logs

Day 5: Database hygiene

• Remove stale transients
• Optimize tables where appropriate
• Review heavy plugins that generate expensive queries

Day 6: Backup + restore rehearsal

• Ensure offsite backups exist
• Do a full restore to a fresh instance
• Document the steps as a runbook

Day 7: Standardize and document

• Save your Nginx/PHP templates
• Record your “known good” plugin set
• Write a short checklist for new sites

A helpful next step: if you’re building a Hetzner-based WordPress standard for yourself or your agency, subscribe to CloudStrap updates on cloudstrap.dev so you can copy proven defaults instead of reinventing them.

FAQ

What’s the simplest way to make WordPress on Hetzner faster?

Start with caching in the right order: long-lived caching headers for static assets, then anonymous page caching, then only add Redis object caching if you have logged-in traffic or heavy dynamic pages. This sequence gives the biggest gains without making the stack harder to debug.

Do I need Redis for WordPress on Hetzner?

Not always. Redis helps most when WordPress generates repeated dynamic queries (membership sites, WooCommerce, large editorial teams), but it adds another moving piece to maintain. If your site is mostly public content and page caching is solid, Redis can be optional.

How should I handle backups when running WordPress on Hetzner?

Use automated, offsite backups and test restores on a schedule. A good baseline is daily database and file backups to a separate system (for example, a Storage Box), plus a monthly restore rehearsal so you know your process works under pressure.

FAQ

What’s the simplest way to make WordPress on Hetzner faster?

Start with caching in the right order: long-lived caching headers for static assets, then anonymous page caching, then only add Redis object caching if you have logged-in traffic or heavy dynamic pages. This sequence delivers the biggest gains with the least operational risk, and it’s easy to validate with repeatable speed tests.

Do I need Redis for WordPress on Hetzner?

Not always. Redis object caching is most valuable for dynamic sites—WooCommerce, membership platforms, or busy editorial dashboards—where the same queries repeat across requests. If your traffic is mostly anonymous and your page cache is effective, Redis may add complexity without a proportional win.

How should I handle backups when running WordPress on Hetzner?

Automate backups and make restores routine. Aim for daily database backups (more frequent for stores), daily or incremental file backups, and store them offsite (not on the same VM). Then run a monthly restore rehearsal to a fresh server and verify key flows like login, media, and checkout/contact forms.