Most WordPress sites don't 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 every request. It runs a stack of plugins that each add their own CSS and JavaScript. It leans on a page builder that ships a layout engine to the visitor. No single plugin is at fault. It's the sum. Add a slider, a form builder, a cookie banner, a security plugin, an SEO plugin and an analytics tag manager, and the browser is now downloading and running code from a dozen authors who never spoke to each other.
Astro does the opposite. 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
These figures 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.
| Metric | WordPress | Astro |
|---|---|---|
| Largest Contentful Paint | 4.2 s | 1.1 s |
| Interaction to Next Paint | 310 ms | 90 ms |
| Cumulative Layout Shift | 0.21 | 0.01 |
| Server response (TTFB) | 780 ms | 60 ms |
| Total page weight | 3.8 MB | 480 KB |
| HTTP requests | 121 | 18 |
| JavaScript shipped | 1.1 MB | 22 KB |
| Plugins to maintain | 28 | 0 |
| Lighthouse performance (mobile) | 41 | 99 |
The line that mattered to the client wasn't in the table. It was on their invoice: no more monthly plugin licences, no security plugin (there's no PHP admin to attack), and no developer on retainer applying updates every fortnight.
What the numbers don't 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. Land a rebuild back on slow shared hosting and you keep a slow first byte. Second, images are usually the real page weight, not code. A rebuild that doesn't also compress and resize images leaves most of the megabytes on the table. Third, a site with genuine interactive features (a live search, a configurator, a booking flow) will ship more JavaScript than this example. As it should.
Who edits the content afterwards
This is the question that stops most WordPress owners, and it's a fair one. You lose the WordPress admin, so we replace it rather than just remove it. For a marketing site, content moves into Markdown files or a headless CMS the team can log into. 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. Sometimes we wire it into an automated publishing workflow so drafting and publishing stay in one place, with a human approving each piece.
The ranking angle
Core Web Vitals are a ranking signal. LCP dropping from 4.2 seconds to 1.1 seconds isn't just a nicer visit. It removes a handicap. The bigger SEO risk in any rebuild is the move itself. Change URLs without redirects and you throw away years of ranking. Before launch we map every old address to its new one with 301 redirects, 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. It's 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.