Slow sites are rarely slow for the reason people think

Every active plugin measured for what it adds to a page load — queries, scripts, styles, admin-ajax calls — rather than judged by reputation. Some well-regarded plugins are expensive; some obscure ones are free.

Where a plugin is doing one small thing at a large cost, I write that one thing as lightweight custom code and remove the plugin. You keep the feature, lose the overhead, and lose one more thing that needs updating.

Commercial themes load a great deal that a given site never uses. I identify what is costing you, disable it safely, and rebuild anything genuinely needed as custom code that does not carry the rest of the theme with it.

Loading only what a page needs, minifying and combining sensibly, deferring what is not required for first paint, and hosting fonts locally rather than fetching them from somebody else's network.

Correct cropping at generation rather than in the browser, lossless compression, modern formats, lazy loading below the fold, and separate treatment for mobile so phones are not downloading desktop images.

Moved off the origin server, loaded on interaction rather than on page load, with a poster image so the page renders without waiting for it.

Slow query identification, missing indexes, orphaned rows left by plugins removed years ago, autoloaded options that have grown to megabytes, and revision and transient tables nobody has ever cleared.

Queries written when the site had two hundred rows and now run against two hundred thousand. Unbounded loops, missing limits, and archive pages loading everything to display twelve items.

Account, cart, checkout and other functional pages rarely contain Elementor content, but frequently load its full asset stack anyway. Preventing that is often the biggest improvement available, and it matters most for logged-in users, who cannot be served from a page cache.

Elementor can output widget styles either inline in the page or as separate cached files. Inline means fewer requests but heavier HTML on every view and nothing reused between pages; external means the browser caches the stylesheet once and reuses it everywhere. Which wins depends on your traffic pattern, and the default is not always right.

Elementor loads support for widgets and experiments a site never uses. Disabling the ones you do not need reduces both the JavaScript parsed and the CSS shipped.

Layouts built by nesting sections inside columns inside containers produce a very deep DOM, which slows rendering and interaction alike. Flattening it usually improves responsiveness more than any script change.

Third-party addon packs load their entire library for one widget. I replace those with lightweight custom Elementor widgets, or with plain markup where a widget was never needed, and remove the pack.

Fonts served from your own domain rather than fetched from Google, removing a third-party connection and a render-blocking dependency, with the added benefit of not shipping visitor data somewhere else.

Object cache, page cache, CDN and browser cache configured to work together rather than against each other — and correct exclusions for cart, account and checkout, which is where a badly configured cache does real damage.

PHP version and settings, OPcache, database server tuning, and whether the hosting itself is capable of the response times the rest of the work assumes.

Builder-generated meta grows quickly. Cleaning orphaned data, clearing regenerable caches and indexing what needs indexing.

Occasionally a site is asking a builder to do something it was never built for, and the honest recommendation is to rebuild that part differently. I will tell you if I think so, with the reasoning and the cost — after the audit, not before.

Real profiling against real traffic, so there is a before and an after and the improvement is demonstrable rather than asserted. Without it, both of us are guessing.

Eliminating queries running inside loops, reading the slow query log properly, adding the indexes nobody added, and rewriting queries whose cost grows with the dataset rather than staying flat.

Structures designed when the data was small and now the bottleneck. Normalising what has been flattened, denormalising where joins have become expensive, and moving high-volume data into tables shaped for how it is actually read.

Anything not required to render the response moves to a queue — emails, third-party API calls, image processing, report generation. The user should never wait for work that could happen after they leave.

Some features are slow because of how they were built, not how they were configured. Reprogramming those properly is often cheaper than another six months of working around them.

Opcode, object, application, response and CDN caching arranged deliberately. The harder half is composing pages where most of the content caches and one personalised fragment does not.

Endpoints and views that return everything, which is fine at a thousand rows and fatal at a million. Cursor pagination where offsets have got expensive.

Minification and bundling, compression at the server, code splitting so a page loads only the JavaScript it needs, and deferring everything not required for first paint.

Tag manager, chat widget, heatmap, two analytics tools and a consent banner. Frequently more expensive than everything else combined, and the one category where the client can simply decide to remove something.

Whether your current host is capable of the response times the rest of the work assumes, and whether the plan matches the traffic. Shared hosting is fine for a great many sites and hopeless for some. I will tell you which yours is, and sometimes the answer is that your hosting is not the problem.

Overprovisioning is common and quiet — paying for sixteen gigabytes of memory to run a site using two. Underprovisioning is common and expensive — a checkout that times out under campaign traffic. I look at actual utilisation and tell you what you should be paying, which is sometimes less than you are.

PHP version and memory limits, PHP-FPM pool sizing against your real concurrency, OPcache allocation, database buffer and connection settings, and web server configuration for compression, HTTP/2 and TLS. Defaults are chosen for safety on unknown workloads, not for yours.

Full-page caching at the web server rather than inside WordPress, so a cached page never starts PHP at all. Object caching with Redis or Memcached so repeated database work is not repeated. Correct browser cache headers so returning visitors fetch almost nothing.

What is cached at the edge and for how long, what must always reach the origin, image optimization at the edge, and cache invalidation that actually fires when content changes rather than leaving stale pages for a week.

Moving to hosting that suits you, with DNS time-to-live lowered in advance, files and database synced, a final delta at cutover, and the old server kept warm until the new one has proven itself. Planned so that orders placed during the switch are not lost.

A staging environment that genuinely matches production, and a deployment process that is repeatable rather than a series of file uploads. Most emergency work I am called into began with a change nobody could roll back.

Background jobs running on real system cron with proper workers, rather than firing on visitor page loads. Anything slow — imports, syncs, emails, reports — happens where nobody is waiting for it.

A Black Friday or a launch is a known event, not a surprise. Load testing against realistic traffic, deciding in advance what scales and what degrades gracefully, and knowing which part gives way first.

Uptime, response time, resource utilisation and error rates, with alerts that reach a person. Performance regressions are usually gradual, and without monitoring the first report comes from a customer.

Working from what real visitors experienced rather than a lab score. Lab tools are for diagnosis; field data decides whether you pass.

The thresholds are the same on both, but mobile is far harder to pass — mid-range phones on real networks, which is what most of your traffic is.

Whichever metric is in the poor band gets attention first. There is no value in improving a score that already passes, and INP is usually the hardest of the three because it is about work on the main thread.

Crawlable structure, structured data, redirects that survive a rebuild, correct canonicals, and confirming your site is actually reachable by the crawlers you assume are indexing it.

Field data updates on a rolling month, so nothing changes in Search Console the day after a deployment. I will tell you that at the start rather than let you wonder in week two.