The WordPress installation was not the problem. The marketing team’s confidence in the WordPress installation was the problem. Every edit was slow. Every update broke something. Every campaign launch was a fire drill. So they stopped touching it, and the rot accelerated. Then they started talking about a rebuild. That is when I was called in.
The audit found no single catastrophic cause. It found seven medium-sized causes, each adding two to three seconds, each on its own forgettable, stacked into a 15-second average load time on mobile. The cleanup did not require new technology. It required the marketing site to be looked at as a system, by someone whose job that was, for the first time in two years.
Most Slow WordPress Sites Have No Single Cause
The HTTP Archive Web Almanac 2024 CMS chapter reports that 40% of WordPress sites passed all three Core Web Vitals on mobile in 2024, up from 28% in 2023[1]. By mid-2025, that figure was around 43%. Half of the WordPress web is still in “needs improvement” or worse. This client’s site was not an outlier; it was an example.
The platform gap is real. The CrUX Tech Report comparing CMSs on mobile in mid-2025 put WordPress at 43.4% passing CWV, against Drupal 59.1%, Squarespace 67.7%, Wix 70.8%, Shopify 75.2%, and Duda 83.6%[2]. The reason is not WordPress itself. The reason is what teams do to a WordPress installation over three years of light attention: stacked plugins, outdated themes, default hosting tiers, no consolidated image pipeline.
That gap is also why the rebuild conversation gets brought up. Marketing teams that have lived inside the slow WordPress experience for a year or more often assume the platform is the problem. The CrUX comparison disagrees. A clean, attentively maintained WordPress installation lands in the same performance band as Shopify or Squarespace. The decay sits in the stack on top of WordPress, not in WordPress.
What an Audit Finds: A Stack of Small Problems
When the audit on this client’s site finished, the breakdown was unsurprising in retrospect. The Web Almanac 2024 Page Weight data is the structural answer: the median desktop WordPress page carries roughly 1,054 KB of images, 613 KB of JavaScript, 131 KB of fonts, 78 KB of CSS, and 18 KB of HTML[3]. The image and script layers dominate. The WordPress core itself is the smallest component.
On this client’s site the JavaScript layer was the worst offender. Two analytics scripts, a chat widget, a heatmap tool, an A/B testing platform, and three legacy tags that no one could trace. The Web Almanac JavaScript chapter found that approximately 44% of delivered JavaScript bytes remain unused at page load, with the median mobile page carrying 206 KB of unused JS[4]. The client site exceeded that median in three categories at once.
The PHP layer was the second offender. WordPress.org’s published statistics show that only around 48% of WordPress installations run a PHP version still receiving security patches[5]. This client was running PHP 7.4, which left active security support in late 2022. The Time to First Byte on the homepage was 1.4 seconds against a target under 600ms. Half of that was server-side rendering on an outdated PHP interpreter doing more work than it needed to.
The remaining components followed a pattern. Theme files from a 2021 purchase that had not been updated. Caching plugin configured wrong (page cache on, object cache off, opcache disabled). Plugins firing unnecessary database queries on every page load. No CDN. No image optimization layer. No CSS bundling. None of these were catastrophic on their own. Each added one to three seconds. Stacked, they produced the 15-second average.
Why Marketing Teams Stop Touching the Site
The fragility loop is the part of the audit nobody asks me to fix because it does not show up on PageSpeed Insights. The site got slow. Editing pages got slow. Plugin updates broke things in unpredictable places, so the team stopped running updates. Theme tweaks risked the build, so the team stopped tweaking. The whole installation entered a stasis where touching anything risked a regression, so the marketing team stopped touching anything.
This is the structural problem marketing teams cannot get dev to prioritize describes from a different angle. When the site becomes fragile, the engineering team’s caution is correct (one wrong update breaks things). When the marketing team’s caution is added on top, the site stops getting any work at all. That is when rot accelerates, because passive entropy keeps moving even when active maintenance stops.
The other failure mode is the workaround. Marketing teams that cannot ship through the main site build around it. Off-platform landing page builders. Third-party form vendors. Microsites with separate domains. Each workaround adds another tracking layer, another brand asset to maintain, another point of inconsistency. The audit on this client’s site found three subdomain microsites for campaigns that had ended six months earlier. They were still indexed, still receiving (tiny amounts of) traffic, still contributing nothing.
What Cleanup Actually Looks Like, in Order
The cleanup followed roughly the same order on this site as on the previous five I had audited. The order is not technical; it is risk-managed. Start with the moves that are highest-leverage and lowest-risk, then progress to moves that require more coordination with the marketing team’s campaign calendar.
The PHP version came first. The hosting provider supported 8.2, the staging environment confirmed compatibility, the migration took 90 minutes and dropped TTFB from 1.4 seconds to 480 milliseconds. That single move was responsible for roughly 30% of the eventual speed improvement. Plugin and theme audit came next: 23 active plugins reduced to 11, the theme updated through three minor versions, child theme overrides documented and verified.
Caching configuration was the third pass. Object cache enabled at the host level, opcache turned on at the PHP level, page cache configured to respect logged-in users and dynamic content correctly (the previous configuration was caching too aggressively and serving stale data on contact-form pages). Script audit followed: defer attribute on every non-critical script tag, three legacy tracking scripts removed entirely, the A/B testing platform reconfigured to load conditionally only on test-eligible pages.
Images and CDN closed the work. WebP conversion via an image-optimization plugin, responsive `srcset` attributes generated automatically, lazy loading on below-the-fold images. CDN setup through Cloudflare with their WordPress optimization layer. Cloudflare’s own documentation on Automatic Platform Optimization reports approximately 72% improvement in TTFB and approximately 23% improvement in First Contentful Paint on WordPress sites[6]. On this site the actual numbers were 65% and 28%, consistent with the published ranges.
The final mobile load came in at 0.8 seconds. The team had a working site for the first time in two years.
Audit First. Rebuild Almost Never.
The team had been having the rebuild conversation for six months when I was brought in. The budget proposal had reached the CFO. The estimated cost was six figures and the timeline was four months of disrupted marketing operations. The audit took three months from kickoff to final cleanup, ran inside the existing site with zero migration risk, preserved all SEO equity (impressions on the top 30 ranking pages stayed flat or improved through the cleanup), and produced a site that is, by every measurable performance dimension, better than the proposed rebuild would have been on day one.
The pattern repeats. The marketing P&L case for site speed walks through why this work belongs on the marketing side of the org. The Website Ownership Gap is the structural reason it gets neglected in the first place. The difference between maintenance and ownership is the operational reason rebuilds become the proposed answer when audits would have produced the same outcome with less disruption. The three ownership models describes who should be running the audit-and-improve loop quarter over quarter.
The rebuild conversation is almost always downstream of an audit conversation nobody had. If your marketing site is slow and the team is talking about replatforming, the first move is not to evaluate platforms. The first move is to evaluate the current installation honestly. The hidden cost of website neglect compounds quietly. Most of it is recoverable. Most teams just never look.
Sources
- HTTP Archive Web Almanac 2024, CMS chapter – Q4 2024 publication; 40% of WordPress sites passed all three Core Web Vitals on mobile in 2024 (up from 28% in 2023); WordPress trails competing CMSs on aggregate CWV pass rate ↩
- WP Tavern, New Core Web Vitals Technology Report (reporting CrUX Tech Report data) – June 2025 CrUX-derived comparison across major CMSs on mobile; WordPress 43.4%, Drupal 59.1%, Squarespace 67.7%, Wix 70.8%, Shopify 75.2%, Duda 83.6% ↩
- HTTP Archive Web Almanac 2024, Page Weight chapter – Q4 2024; median desktop page is 1,054 KB images + 613 KB JavaScript + 131 KB fonts + 78 KB CSS + 18 KB HTML; mobile page weight grew 357% over the last decade ↩
- HTTP Archive Web Almanac 2024, JavaScript chapter – Q4 2024; approximately 44% of delivered JavaScript bytes remain unused at page load; median mobile page carries 206 KB of unused JavaScript ↩
- WordPress.org, Statistics (PHP version distribution) – Live data retrieved May 2026; significant share of WordPress installations still run end-of-life PHP versions; only approximately 48% of WordPress sites run a PHP version still receiving security patches ↩
- Cloudflare, Automatic Platform Optimization for WordPress (product documentation) – 2024-2025; Cloudflare reports Automatic Platform Optimization reduces Time to First Byte by approximately 72% and First Contentful Paint by approximately 23% on WordPress sites; supporting evidence for the audit-cleanup pattern’s effectiveness ↩
Seeing these patterns at your company?
Book a free WebOps Diagnostic. I'll review your site before the call and share specific observations.
Book a Free Call →Frequently Asked Questions
Run PageSpeed Insights on five different page templates (home, blog index, single post, landing page, contact). If every page shows the same handful of issues in different proportions, the cause is platform-level: theme, plugins, server, caching. If one page is dramatically worse than the others, the cause is page-level: an unoptimized image, a third-party embed, a broken script. Stacked problems are the more common pattern at 20-200 person B2B SaaS marketing sites in 2026.
Updating PHP, in the cases where it has been left on a version no longer receiving security patches. PHP 8.x can be 40-60% faster than older 7.x versions on identical WordPress workloads. The fix takes about an hour with a competent host and a staging environment, and it shows up immediately in TTFB (Time to First Byte) and overall page load. It is the single highest-leverage move on most neglected WordPress installations.
The audit itself is 2-3 days of focused work: page-template testing, plugin and theme inventory, server-side measurement, image and script analysis, hosting review, caching audit. The cleanup work that follows usually runs 2-3 months for a site that has had no maintenance attention in a year or more. Most of that time is not technical effort; it is coordination with the marketing team to test changes against live campaigns and avoid disruption during launches.
Audit first, almost always. WordPress on current PHP with a tidy plugin set, configured caching, and image optimization can hit good Core Web Vitals on commodity managed hosting. The reasons to rebuild are platform reasons: the CMS cannot represent the brand, headless migration is overdue, the database has unrecoverable rot from a botched plugin years ago. Almost no team at the 20-200 person B2B SaaS stage actually has those reasons. Most rebuild conversations are downstream of an audit conversation nobody had.
Partially. The diagnostic stage (where you confirm there is a problem) is accessible: run pagespeed.web.dev with the mobile toggle, screenshot the result, and compare against Google's good thresholds. The remediation stage requires WordPress-specific knowledge: PHP version management, plugin auditing, caching layer configuration, theme rendering pipelines. The split is roughly: marketing can run the diagnostic, but the remediation requires either an embedded technical owner or a competent contractor.
