Fast sites are a sign of careful work.
Most performance pages sell speed as a way to recover lost sales. The relationship is real, but it’s been oversold to the point of cliché. The better reason to care about performance is that a fast site is what a well-built site looks like – everything else is downstream of that.
I take slow WordPress sites and make them fast. Sometimes that’s a one-off project, sometimes it’s the start of an ongoing relationship. Either way, you get the work done properly, with measurements before and after.
Sounds familiar?
Your site is slow and you know it
Pages take five, six, eight seconds to load. You’ve tested it on your own connection and watched it crawl. Your team has stopped using parts of the admin because it’s painful.
Customer complaints or comments
Someone told you the site was slow. Or you’ve seen it in support tickets, in a Google review, in feedback your sales team passed along. Once is anecdote. Twice is a pattern.
Bad Core Web Vitals scores
Your Search Console is showing failed Core Web Vitals – LCP too slow, CLS too high, INP unresponsive on mobile. You’ve been meaning to do something about it. The notification keeps coming back.
Post-launch let-down
The site went live and felt fine, but a year of plugins, content, and tracking pixels later it’s sluggish. Nothing changed dramatically. The accumulation did the damage.
Your competitors are faster
You ran your site through PageSpeed Insights and then ran a competitor through the same tool. The gap was wide. That’s not a small thing if you’re competing on the same search terms.
What I do
Measure first
Before any work starts, I take a baseline. Real-world load time from the locations your customers are in, Core Web Vitals from the Chrome User Experience Report, page weight, request count, server response time. Without a baseline, “we made it faster” is just an opinion.
The caching layer
Caching is where most performance gains come from on a typical WordPress site. LiteSpeed Cache if you’re on OpenLiteSpeed hosting – it’s free, fast, and integrated at the server level. If you’re on standard nginx, I’ll set up caching at that layer instead. Either way, the goal is that most page loads never touch PHP or the database.
Image and asset diet
Most slow sites are slow because they’re heavy. Images uploaded at camera resolution. Background videos that autoplay. Fonts loaded but never used. Plugins each adding their own JavaScript and CSS to every page, whether the page needs them or not.
I run images through ShortPixel for compression and proper format conversion, and use Perfmatters to disable scripts and styles where they’re not needed – on a typical site that’s where a lot of the weight comes off.
Cloudflare in front
For most sites I’ll put Cloudflare in front of the hosting. It’s a content delivery network that serves cached assets from the location nearest the visitor, plus DDoS protection and a web application firewall as a side benefit. The free tier covers what most sites need. For sites with global audiences, the speed difference for international visitors is hard to overstate.
Hosting review
Sometimes the site is slow because the hosting is slow. Cheap shared hosting where one neighbour’s traffic spike becomes your downtime. Servers in the wrong region for your audience. PHP versions years out of date. If your hosting is the bottleneck, I’ll say so and help with the migration if that’s the right call.
A report at the end
You get a written summary of what was measured, what was changed, and what the numbers look like now. Same metrics as the baseline, so the before/after is honest. If something didn’t move as much as expected, that’s in the report too.
When fast isn't possible
Sometimes the site is built on choices that can’t be optimised around. A page builder generating a thousand DOM nodes for a hero section. A theme with twenty thousand lines of unused CSS. A plugin doing live API calls on every page load. In those cases I’ll tell you what’s possible within the current build, and what would require rebuilding the affected parts. You decide which path makes sense.
How it's priced
Fixed price for most sites
For typical WordPress sites – up to a few dozen pages, standard plugin stack, no exotic build – performance optimization is a fixed-price project. €450 covers the audit, the work, and the report. Usually one to two weeks from start to delivery.
Scoped individually for complex sites
Larger sites, eCommerce stores with hundreds or thousands of products, sites with custom development, sites where a previous developer made unusual choices – those get scoped from an audit. Audit alone from €400, full optimization work from there based on what’s in the audit.
Ongoing as part of maintenance
Performance isn’t a one-time fix – new content, new plugins, and new tracking pixels accumulate over time. Monthly retainers from €100 include ongoing performance monitoring as standard, and follow the optimization project – I don’t take on retainers for sites I haven’t worked on first.
Process
Step 1
You email me the URL and tell me what's prompted the concern. A description of the situation is fine.
Step 2
I run a quick assessment to confirm the fixed-price project will work, or whether the site needs scoping individually.
Step 3
Once you confirm, I take measurements, do the work, and run final tests. 2-3 working days for typical sites, longer for complex ones.
Step 4
You get a report of what was measured, what changed, what the numbers look like now. If anything needs follow-up I flag it.
For one-off projects, that’s the end of it. If the site would benefit from ongoing maintenance, I’ll suggest a retainer once the project completes – the optimization comes first because I need to know the site before I can keep it running. Retainers are optional and the project stands on its own.
A note on SEO
A faster site does help search rankings. Core Web Vitals are a Google ranking factor and have been since 2021. But speed is one signal among many, and a faster site won’t fix a thin-content or backlink problem. If your traffic is down, performance is worth ruling out, but it’s rarely the whole story.
Worth saying something else here too. Core Web Vitals scores are useful, but they aren’t the same thing as a fast site. Chase them in isolation and they turn into a synthetic benchmark – the page scores green in PageSpeed Insights but still feels sluggish to a real user, because the optimisations that move the score don’t always match what the visitor actually experiences. Lazy-loading the wrong things, deferring JavaScript that the page genuinely needs, hiding content from the initial render to make the LCP number look better. The score goes up. The site doesn’t feel any faster.
I optimise for both – the scores, because they affect rankings, and the actual experience, because that’s the point of the work. When those two pull in different directions, real-world speed wins. I’ll tell you straight whether speed is the right thing to fix, or whether the budget would do more good somewhere else.
Let's talk
Send me your URL. I'll tell you what's slowing it down.
A few sentences is enough. The site address, what’s prompted the concern, whether anyone’s complained, any deadline you’re working to. I usually reply within a day or two with an honest assessment and a price.