Services / Performance Engineering

Speed is a business decision.

Every second of load time costs you conversions. A one-second delay in page response reduces conversions by approximately seven percent. That is not a rough industry estimate, it is a measurable loss you can calculate against your own revenue data. I do not apply generic speed tips. I trace performance problems back to their root cause and eliminate them permanently.

60–85%

Typical LCP improvement

Up to 97%

Database query reduction

Up to 98%

Page weight reduction

The problem

Why generic optimisation fails

Most WordPress developers approach performance the same way: install a caching plugin, run GTmetrix, chase the score. This produces a better-looking report and a negligible improvement to actual user experience. Sometimes it makes things worse.

Real performance engineering begins with measurement. Before I change a single configuration value, I profile your site under realistic conditions: actual page loads, authenticated users, WooCommerce cart sessions, mobile connections. I identify where time is actually being spent, not where a generic audit tool guesses it might be.

Database queries that take 800 milliseconds on a page with 200 concurrent users are not visible in a Lighthouse test run from a fast connection. N+1 query problems generated by misconfigured plugins accumulate silently. Bloated post_meta tables that grew over five years of plugin installs and removals do not appear on any speed score. These are the things I find.

What is included

Performance engineering services

Every engagement begins with a diagnostic audit. I do not propose a fixed-price scope until I have identified the root causes. You receive a complete findings report before any remediation work begins.

Core Web Vitals audit

A forensic investigation of your Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint scores across desktop and mobile, measured under realistic conditions. Every bottleneck is identified with measurement data, not guesswork. The audit produces a prioritised findings report that maps each issue to its business impact before any remediation work is scoped.

Database optimisation

Identification and elimination of unindexed queries, N+1 problems, bloated post_meta tables, and plugin-generated table sprawl that silently kills response times. I use Query Monitor and MySQL slow query logging to trace every expensive database call to its origin. On sites with years of plugin churn, database optimisation alone frequently produces the largest single performance gain.

Server-side caching architecture

Object caching with Redis, full-page caching configuration, and cache invalidation logic that works correctly under WooCommerce and authenticated user conditions. Most caching configurations break checkout, fragment-cache incorrectly, or serve stale content to logged-in users. I configure caching so it accelerates the right requests without compromising dynamic functionality.

Asset delivery pipeline

CSS and JavaScript minification, critical CSS extraction and inlining, deferred loading for render-blocking resources, next-gen image format conversion (AVIF and WebP), and CDN configuration to ensure assets arrive as fast as physically possible. LCP pre-loading, resource hints, and font display strategies are tuned to your specific page structure, not applied generically.

Hosting configuration review

PHP-FPM pool tuning, OpCache configuration, MySQL InnoDB buffer pool sizing, and HTTP/3 enablement: the server-level changes that hosting companies configure to their defaults and never revisit. These settings carry significant performance impact and are rarely touched even on managed hosting platforms.

WooCommerce performance engineering

WooCommerce generates disproportionate database load relative to standard WordPress. Cart sessions, transient accumulation, order meta, and product query complexity each contribute to checkout slowness that costs real revenue. I address WooCommerce performance as a distinct workstream, not an afterthought of general caching advice.

Who this is for

Right for you if…

Your WooCommerce store is losing conversions to slow checkout and you have the data to prove it.

Google Search Console is showing Core Web Vitals failures and you need them resolved, not just improved.

Your hosting company has recommended an expensive upgrade when the real problem is configuration.

You have tried caching plugins and the improvement was marginal, or made things worse.

Your site was fast when it launched but has gradually degraded as plugins and content accumulated.

You have a high-traffic event, launch, or campaign approaching and cannot afford performance failure under load.

FAQs

Common questions

Do I need to change hosting provider to see improvements?

Rarely. The majority of performance problems are configuration and code problems, not hardware problems. I can achieve substantial improvements on most existing hosting environments by tuning what is already there. If your hosting genuinely cannot support the changes needed, I will tell you that as part of the audit findings, not assume it at the outset.

I already have a caching plugin installed. Is there still work to do?

Almost certainly. Caching plugins address one layer of the performance stack and typically do so incompletely. Database query overhead, render-blocking assets, unoptimised images, and server-level configuration issues are all outside the scope of what a caching plugin can fix. In many cases, a misconfigured caching plugin is itself contributing to the problem.

How long does a performance engagement take?

An audit typically takes two to three days. Remediation scope depends on the findings: minor configuration work might be completed in a day; a database with years of accumulated overhead and a complex caching architecture to rebuild might take a week. I give you a fixed-price scope and timeline after the audit, before any remediation work begins.

Will performance work affect my site's functionality or appearance?

All remediation work is done on a staging environment first and verified before touching production. Changes that could affect functionality, including caching rules, deferred scripts, and image format conversion, are tested specifically against your site's features, not applied as generic settings.

What access do you need?

Typically: WordPress admin, hosting control panel or SSH access, and read access to server error logs. For database-level work I need database credentials. I operate on a principle of minimal access and request only what the specific engagement requires.

From the blog

Performance insight from the field

All articles →

Ready to find out what is slowing you down?

If your site is underperforming and you want a diagnosis before committing to any work, let's talk. I will tell you what I find before I ask for anything.

Discuss your project View case studies