WordPress to Astro: the before-and-after numbers

Most WordPress sites do not start slow. They get slow, one plugin at a time, until a page that began as a few hundred kilobytes ships four megabytes and takes five seconds to settle on a phone. Moving that site to Astro is less about a faster framework and more about shipping far less to the browser. Here are the numbers from a site we moved recently, and what sits behind them.

Why WordPress gets heavy

A typical business WordPress site renders every page in PHP on each request, runs a stack of plugins that each add their own CSS and JavaScript, and leans on a page builder that ships a layout engine to the visitor. None of that is a fault in any one plugin. It is the sum. Add a slider, a form builder, a cookie banner, a security plugin, an SEO plugin and a analytics tag manager, and the browser now downloads and runs code from a dozen authors who never spoke to each other.

Astro takes the opposite approach. Pages are built once, at deploy time, into plain HTML and served from a CDN. JavaScript is opt-in per component, so a page that needs no interactivity ships none. The content still lives somewhere you can edit; the visitor just never pays for the editing tools.

The measured result

The figures below are from a business-services site we moved in mid-2026: WordPress on managed hosting with a page builder and about 28 active plugins, rebuilt in Astro on Cloudflare. Field metrics are mobile, measured on a mid-range Android over 4G. Treat them as one representative case, not a guarantee. Your starting point and your content decide how far the numbers move.

The line that matters to the client was the last one on their invoice, not the table: no more monthly plugin licences, no security plugin because there is no PHP admin to attack, and no developer on retainer to apply updates every fortnight.

What the numbers do not tell you

Three caveats keep this honest. First, hosting does a lot of the work. Serving static files from an edge network is why TTFB drops from three digits to two; a rebuild that lands back on slow shared hosting keeps a slow first byte. Second, images are usually the real page weight, not code, so a rebuild that does not also compress and resize images leaves most of the megabytes on the table. Third, a heavy site with genuine interactive features (a live search, a configurator, a booking flow) will ship more JavaScript than this example, because it should.

Who edits the content afterwards

This is the question that stops most WordPress owners, and it is a fair one. You lose the WordPress admin, so we replace it rather than remove it. For a marketing site, content moves into Markdown files or a headless CMS the team can log into, and the people who wrote posts before still write them, in an editor, without touching code. If an ongoing publishing workflow matters, we scope that first and sometimes wire it into an AI marketing system so drafting and publishing stay in one place with a human approving each piece.

The ranking angle

Core Web Vitals are a ranking signal, so LCP going from 4.2 seconds to 1.1 seconds is not only a nicer visit, it removes a handicap. The larger SEO risk in any rebuild is the move itself: change URLs without redirects and you throw away years of ranking. We map every old address to its new one with 301 redirects before launch, keep the page titles and structure that already earned rankings, and add the structured data that helps search engines and AI answer engines read the site. The work is closer to careful removals than demolition.

If your WordPress site has slowed to a crawl and the plugin list keeps growing, the WordPress to Astro conversion page covers how we scope and price a rebuild. We also do this work as part of a broader store build when the site sits in front of a shop.