Static site vs WordPress performance: the honest numbers

Someone proposes moving a site off WordPress to make it faster, and the conversation immediately stops being technical. One side says WordPress is bloated. The other side points at a fast WordPress site as proof it is not. Both are describing real sites and both are right, which is a good sign the question is being asked badly.

The useful version of the question is narrower. For a given page, how much work has to happen between the request and the moment a visitor can read and use the thing they came for, and which parts of that work does the platform decide for you.

What we are measuring against

It helps to have thresholds that are not a matter of opinion. Google publishes them as the Core Web Vitals, and web.dev's reference page sets three: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less. Interaction to Next Paint became a stable Core Web Vital in 2024, replacing First Input Delay.

One detail in that page does more work than the numbers themselves. The target is the 75th percentile of page loads, segmented across mobile and desktop. Not your machine, not an average. Three quarters of real visits have to clear the bar, which is why a site that feels fine on a developer's laptop on office wifi can still fail.

Google Search Central's page on Core Web Vitals puts the ranking question carefully, saying that good Core Web Vitals, along with other page experience aspects, aligns with what its core ranking systems seek to reward. Note what that does not say. It does not promise a position, and it does not quantify the weight against relevance. Anyone selling you a migration on a ranking guarantee is going beyond what the documentation supports.

Where the difference actually comes from

A static site and a WordPress site can serve byte-identical HTML. Nothing prevents it. The differences that matter in practice are defaults, and defaults are what a platform decides on your behalf when nobody is paying attention.

The row that decides most real cases is the plugin row. A plugin that is used on one page usually enqueues its assets on every page, because it cannot know where you will use it. Twelve plugins is not twelve features, it is twelve sets of stylesheets and scripts arriving before the browser can finish laying out an article that needed none of them.

The last row is the honest one. Static sites do not get slow, they get stale, and a stale site is a content operations problem rather than an engineering one. That trade is the actual decision, and it is easy to miss while arguing about milliseconds.

When WordPress is the right answer anyway

• Non-technical people publish several times a week and need to do it without a deploy.
• The site depends on a plugin ecosystem you would otherwise rebuild, such as a membership wall or a mature store.
• The current site is fast enough at the 75th percentile, in which case a migration buys you nothing you can measure.
• Nobody on the team can own a build pipeline, and a static site with no owner degrades into a site nobody updates.

That third bullet is the one that saves the most money. Measure before you migrate. If the field data already clears 2.5 seconds and 0.1, the platform is not your problem and the redesign you actually want should be argued on its own merits.

When the platform genuinely is the ceiling

The case for moving is strongest when the page is mostly read and rarely changed, when the plugin list has grown past anyone's ability to justify it line by line, and when caching has already been tried. Caching is the tell. A site that is fast only when warm, and slow for the first visitor after every publish, has been patched rather than fixed.

The diagnostic order matters more than the platform choice, and we set it out step by step in why a website is slow on mobile. Run that first. It routinely finds an oversized hero image doing more damage than the entire framework argument.

The cost nobody puts in the proposal

A migration is not a performance task, it is a content task wearing performance clothes. The engineering is usually the small half. Redirects, media libraries, editor training and the long tail of pages nobody remembers are the large half, and they are what makes the timeline slip.

Before committing, it is worth reading the running costs on both sides, which we broke down in what a web app costs per month to run, and the scoping discipline in how to scope a software project before anyone writes code. If you are commissioning the work rather than doing it, how to choose a software development company covers the questions worth asking.

The commercial argument for any of this, stripped of the technical framing, is in why a slow site is a revenue problem.

The honest limit

A well-maintained WordPress site beats a badly built static site, comfortably and often. Platform sets your ceiling and your default, it does not set your result. If the team that builds the static site is the team that let the WordPress site accumulate twelve plugins, the new site will be fast for about four months.

For readers working in Arabic, KF Agency covered the same thresholds from a marketing rather than an engineering angle in تحسين الموقع لتجربة الصفحة Core Web Vitals, which is written in Arabic and argues whether the work is worth the effort at all.