Skip to main content
From 4 seconds to under 200 ms

WordPress Performance

Your website takes four seconds to load. Visitors expect under two. Google penalizes anything above 2.5. FrankenPHP Worker Mode changes the equation entirely.

Slow website?
Google has already noticed

Google has confirmed that Core Web Vitals affect rankings. Each additional second of load time increases bounce rate by up to 32%. For a business website that depends on search engine visibility, slow performance is the same as paying for invisibility.

Most WordPress sites on shared hosting take 2-5 seconds to load. Plugins load JavaScript you don't need. The theme runs database queries it never should. And the server boots WordPress from scratch for every single page view.

We've probably seen this hundreds of times. And the answer is rarely "install a caching plugin". The answer is architecture.

<30ms

TTFB with FrankenPHP

98/100

Lighthouse Performance

32%

Increased bounce rate per second

0ms

Total Blocking Time

What makes WordPress slow?

Performance issues are rarely WordPress's fault. They're the consequence of wrong architecture, wrong hosting and too many plugins.
01 / 04

Too many plugins

Each plugin adds JavaScript, CSS and database queries. 20 plugins can mean 400 KB of extra JavaScript and 50+ database queries per page view.
02 / 04

Slow database

WordPress's EAV database model is flexible but slow at scale. Without object cache, the database repeats the same work for every visitor.
03 / 04

Shared hosting

You share a server with hundreds of other websites. When a neighboring site gets a traffic spike, you feel it. The PHP version is outdated and you have no control.
04 / 04

No caching strategy

A caching plugin is better than nothing, but it's a band-aid on an architecture problem. Proper caching happens at the infrastructure level with Redis and Varnish.

FrankenPHP Worker Mode
the application in memory

Traditional WordPress hosting boots PHP from scratch for every page view. Loads the framework, connects to the database, initializes plugins, builds the page. And repeats the whole process for the next visitor.

FrankenPHP Worker Mode changes this fundamentally. The application starts once and stays in memory, ready to respond instantly. Startup cost eliminated. The result is TTFB under 30 milliseconds, compared to 200-300 ms with traditional PHP-FPM.

In addition, FrankenPHP provides automatic HTTPS, HTTP/2 and HTTP/3 out of the box, plus Early Hints that let the browser start loading resources before the page has finished generating.

Performance optimization at every layer

01 / 06

Redis Object Cache

Database queries cached in memory. Shopping carts, sessions and transient data fetched from Redis instead of MySQL. Dramatically lower database load.
02 / 06

Image compression

Automatic conversion to WebP/AVIF with responsive srcset. Images served at the right size for the device's screen. No 4 MB JPEGs to mobile.
03 / 06

Critical CSS

Above-the-fold CSS inlined in HTML. The rest lazy-loaded asynchronously. Eliminates render-blocking and delivers faster First Contentful Paint.
04 / 06

Lazy loading

Images, iframes and heavy components load only when they enter the viewport. Reduces initial page load and improves Time to Interactive.
05 / 06

CDN and edge caching

Static resources served from edge nodes near the user. Traefik handles intelligent cache invalidation on deploy.
06 / 06

Database optimization

Query Monitor identifies slow queries. Indexing, query optimization and transient cleanup done systematically, not randomly.

Before and after optimization

butikken.no4.2s
19 plugins · Shared hosting
butikken.no180ms
4 plugins · FrankenPHP + Redis

Same website, two different architectures. The difference isn't about WordPress. It's about how WordPress is set up [1].

  1. [1]Google/SOASTA — The State of Online Retail Performance

Core Web Vitals: Typical vs. optimized

Typical WordPress
LCP
3.2s (poor)
INP
280ms (needs improvement)
CLS
0.15 (needs improvement)
TTFB
1.2s
FCP
2.8s
Total Blocking Time
450ms
Lighthouse Score
45-65
PXL-optimized
Google recommends
LCP
0.8s (good)
INP
12ms (good)
CLS
0.01 (good)
TTFB
28ms
FCP
0.6s
Total Blocking Time
0ms
Lighthouse Score
95-100

How we measure performance

We don't use "it feels faster" as a metric. We measure concrete numbers and set thresholds.
01 / 04

Lighthouse CI

Automated Lighthouse runs in the CI/CD pipeline. The build is blocked if performance drops below the threshold. No regressions slip through.
02 / 04

Real User Monitoring

Core Web Vitals from real users, not just lab data. We see the difference between mobile and desktop, between Norway and the rest of the world.
03 / 04

Synthetic monitoring

Regular performance tests from multiple geographic locations. Trend lines show whether performance is improving or degrading over time.
04 / 04

Query Monitor

Detailed analysis of database queries, hooks and PHP memory usage per page view. Identifies bottlenecks with surgical precision.

When do you need performance optimization?

Some signals are clear:

  • Your website takes over 2 seconds to load — even with a caching plugin
  • Lighthouse Performance score is below 70
  • Google Search Console warns about Core Web Vitals issues
  • Visitors leave before the page finishes loading
  • Your website is noticeably slower on mobile than desktop
  • You notice performance drops during campaigns or traffic spikes

Then it's probably not about a better caching plugin. It's about infrastructure.

SB
CG
JB
About us

Time to build something proper?

Whether you're starting fresh or fixing legacy — we can help.

Contact usOur services