Why We Rebuilt wpspeedopt.net as a Static Site
A site that sells WordPress speed optimization has an awkward obligation: its own pages should load fast. Ours ran on WordPress for years, and it was perfectly fine. But every time we audited our own homepage with the same tools we point at clients, the same culprits kept showing up: PHP render on every uncached request, plugin CSS that existed for features we did not use, and a page builder whose layout data lived in database tables instead of files.
So we did what we tell clients to consider when the audit says the platform is the ceiling: we rebuilt the site as a static Astro build, deployed from git on every push. This post is the honest before and after.
First, the question you are probably here to answer: can a WordPress site pass Core Web Vitals? Yes, easily, when it is properly tuned. We keep hundreds of WordPress sites green for a living; the durability data on our portfolio page tracks 635 blogs we optimized on WordPress, 94 of which still pass mobile Core Web Vitals years later. Static was not a surrender. It was the right tool for a site that publishes a few times a month from git and needs no editor, no users, and no store.
What we kept
The migration was not a rebrand. Slugs are byte-identical, so every URL
Google has indexed serves the same content. The image library moved as a
1:1 path mirror, which means legacy /wp-content/uploads/ links keep
working. Yoast’s meta descriptions carried over. The RSS feed moved from
WordPress /feed/ to /rss.xml with a 301 in place. If you arrived here
from an old bookmark, nothing looks different except the load time.
What changed under the hood
The WordPress stack behind the old site was a page builder theme, a caching plugin, an image optimizer, a database, and PHP-FPM workers whose job was mostly to serve cached pages. The new stack is a folder of HTML files.
That sounds like a joke, but it is the entire point. A static file is the cached page with the cache, the plugin, the database, and the PHP workers removed. There is no cache-miss path because there is no uncached path.
The honest numbers
Lab scores flatter static sites, and we do not sell lab scores, so we measured the boring things instead. Old-site figures come from a January 2025 Wayback Machine capture of the WordPress homepage; new-site figures are live measurements from the day we published this:
| WordPress | Static | |
|---|---|---|
| Asset requests on the homepage | 20 (2 CSS, 6 JS, 12 images) | 2 (1 CSS, 1 logo) |
| JavaScript on the homepage | jQuery + theme + 4 plugin scripts | 0 |
| HTML document size | 79 KB | 34 KB |
| Homepage TTFB for you to test | measure it yourself | 54 ms right now |
Mapped to the metrics Google judges sites by: with no PHP render and no database round-trip, TTFB collapses to disk-read speed, which gives LCP the widest possible head start. With zero JavaScript on the page, there is nothing to block the main thread, so INP degradation has nowhere to come from. With intrinsic image dimensions and one local stylesheet, there is no late-arriving element to shove the layout around, so CLS stays at zero by construction rather than by compensation. Run your own check on the homepage; the numbers in the table above are reproducible.
Every deploy is a git push: the build takes under two seconds on this server, and the deploy script swaps the document root with a rollback trap. If the health check fails, the old site comes back automatically.
When this is the wrong choice
Most of our clients should not do this. If you publish through an editor every day, need user accounts, or run a store, WordPress earns its keep, and the right work is the kind on our portfolio page: caching done right, critical CSS, sane image pipelines.
The static rebuild made sense for us because this site changes a few times a month, publishes from git, and exists to prove a point about page weight. Your site probably has more moving parts. Over ten-plus years and 500-plus client engagements, almost all of our work has been making WordPress itself fast, from a four-country bank to high-traffic WooCommerce stores, and green Core Web Vitals on a tuned WordPress site is the normal outcome, not the exception. Audit first, decide after.
The takeaway
Speed work is mostly subtractive. We removed a rendering layer, a database round-trip, three plugins, and a page builder, and the site got faster by exactly as much as you would expect. The same logic applies inside WordPress: before you add an optimization plugin, ask what it is adding to.
If your WordPress site has outgrown its performance ceiling, or you are not sure which plugins are pulling their weight, the portfolio shows what that work looks like in practice, including hosting migrations and Core Web Vitals rescues. Or skip straight to a free audit: we will tell you what is actually slowing it down, honestly, with the same numbers-first approach you just read.