Which performance plugin do you install?

Often none. If the theme emits bloated markup and the queries are inefficient, a caching plugin hides the symptom for anonymous visitors and changes nothing for anyone else. Where plugins help, the choice follows the host. WP Rocket and Perfmatters are useful on DigitalOcean or Kinsta. On WordPress VIP and Ymir we avoid them: those platforms handle caching at the infrastructure layer, and a plugin fighting the platform makes things worse. Critical CSS helps on largely static pages. WebP and AVIF depend on host and browser support.

How do you find what is actually slow?

Query Monitor, in development and staging. It surfaces the things a synthetic score cannot: Slow or repeated database queries. Scripts and styles loading on pages that never use them. Hooks with high execution time. Problems in AJAX, the REST API and transients. We enable SAVEQUERIES in wp-config.php while investigating, and we document any query over 100 milliseconds. Nested loops and expensive functions in pre_get_posts are the patterns that show up most. Query Monitor never runs in production.

What numbers do you hold the build to?

LCP under 2.5 seconds. CLS under 0.1. TBT under 300 milliseconds. Validated in PageSpeed Insights, GTmetrix and WebPageTest, on mobile and on a simulated 3G connection. A desktop score on a fast office connection is not evidence. After launch the same metrics are checked in Search Console, because lab data and field data disagree more often than teams expect.

How much of this depends on our hosting?

Enough that we plan around it, not enough to be an excuse. Modern hosting with HTTP/2 or newer and a CDN is a prerequisite. Below that line there is a ceiling no amount of frontend work will lift. Above it, the caching strategy is platform-specific, which is why we configure it per host instead of shipping the same plugin everywhere. What does not change is the code. Bloated markup and unbounded queries are slow on every one of them.

Will the site still be fast once marketing starts publishing?

Editors add pages faster than engineers review them, so the block library has to be light by construction, not by discipline. Our block system is built for that: blocks are lightweight and responsive by design, images are compressed before upload, and dimensions are set so a new page cannot introduce layout shift. ThreatModeler is the reference point: their Core Web Vitals have stayed green on every release since the migration.

Do we need a rebuild, or can our current site be optimized?

It depends on what produces the HTML. Targeted optimization works when four things are already true: A design optimized before it was built. A clean theme: a WordPress VIP custom theme or Sage. Modern hosting with HTTP/2 and a CDN. Access to PageSpeed Insights or Search Console. When the theme is page-builder output, that output is the constraint. That was the situation at ThreatModeler, and replacing the builder is what produced the improvement. Core Web Vitals sit inside the search surface, so this work runs alongside enterprise SEO rather than after it.

Performance

Enterprise WordPress performance that survives real traffic

Speed is a property of how a site is built, not a plugin you add afterwards. We engineer the theme, the queries, the asset pipeline and the caching layer so Core Web Vitals stay green long after launch week.

Home
Capabilities
Performance

What we engineer

Seven places WordPress performance is won or lost

Enterprise sites are rarely slow for one reason. They are slow because seven decisions were each made in isolation. These are the ones we take deliberately.

Lean markup and an unblocked render path

Semantic HTML with no decorative wrapper nesting, and blocks built so nothing in the critical path delays the first render. Page-builder output is the most common cause of a slow enterprise WordPress site, and no caching layer undoes it.

Script and style loading discipline

Assets are enqueued with async or defer wherever the dependency graph allows, and nothing non-essential loads globally. jQuery is avoided unless a dependency requires it. Bundling runs through Vite with Tailwind JIT, so the CSS that ships is the CSS the page uses.

Database queries that scale with the content

WP_Query is tuned rather than trusted, repeated queries are removed, and expensive work stays out of pre_get_posts. The query that is fine at 500 posts is the one that fails at 50,000.

Image and font delivery without layout shift

Images are compressed at the source and served as WebP or AVIF where host and browser support it, with explicit width and height so nothing jumps while the page paints. Fonts are preloaded when needed, with font-display set to swap.

Third-party weight kept to what earns it

JavaScript libraries are added sparingly rather than by habit, because every dependency is weight the browser pays for on every visit. Images below the first screen are lazy-loaded, so early bandwidth goes to what the reader can already see.

Caching and CDN matched to your host

WordPress VIP gives you a CDN and full-page caching, Kinsta adds server-level caching, Ymir is serverless behind an edge CDN, and DigitalOcean with Trellis caches at the server. We configure to the platform rather than installing the same plugin everywhere.

Numbers the build has to hit

Validated against thresholds, not impressions: LCP under 2.5 seconds, CLS under 0.1, TBT under 300 milliseconds, measured on mobile and on a throttled connection, because that is how most traffic arrives.

Proof

What lean output did for a cybersecurity platform

ThreatModeler, an enterprise threat modeling company, was running on Elementor. The page builder inflated load times and dragged Core Web Vitals down. We rebuilt the frontend on lean Gutenberg markup. Measured outcomes on their platform:

40%+

Faster site performance after replacing page-builder output with lean Gutenberg markup

Every release

Core Web Vitals have stayed green since the migration, not only on launch day

3x

Faster campaign turnaround, because the lighter block system is the one marketing edits

How we work

Three phases, because an audit is not a fix

An audit tells you what is slow today. These phases keep it from being slow again two quarters from now.

Development

Performance constraints apply while the code is written. Non-essential scripts never load globally, blocks ship without render-blocking assets, and the design is optimized before it reaches a browser: no unnecessary elements in the Figma file, images compressed at the original.

QA before go-live

Query Monitor runs in development and staging to expose what a synthetic score hides: slow or repeated database queries, styles loading where they are not used, hooks with high execution time, and problems in AJAX, the REST API and transients. We then validate in PageSpeed Insights, GTmetrix and WebPageTest.

After launch

Core Web Vitals are reviewed in Search Console on real field data, corrective actions are documented rather than remembered, and Lighthouse CI can gate every pull request so a regression is caught in review, not by your users.

What enterprise teams ask us about WordPress performance

Worth reading even if you never hire us.

Related insights

Keep reading on WordPress performance

Optimization practice, monitoring tooling, and what changes when traffic scales.

Three people collaborate at a wooden desk in a modern, sunlit office, discussing documents and notes, with a computer displaying a website dashboard. Coffee cups, papers, and sticky notes are scattered on the desk.

Feb 18, 2026

WordPress

Request a WordPress performance audit

We will measure LCP, CLS and TBT on mobile, review your caching and CDN setup against the platform you run on, and tell you what is holding the site back. You get the findings either way.

Request a performance audit Talk to a WordPress engineer