Field notes
Does page speed affect Google rankings? What we measured when we left WordPress
Matt Pearce · 26 August 2026
Yes, but not the way it is usually sold. Page speed is a real ranking signal, but a lightweight one; its bigger effects on your visibility are indirect. This week we replaced our WordPress site with a static build and measured both versions under identical conditions. Same server, same pages, same test, the new site is twice as fast. Here are the numbers.
This week we retired our WordPress website and replaced it with a static site, plain HTML and CSS, generated in advance, with no database and no PHP between the visitor and the page. Because we kept the old site running (privately) after the switch, we had a rare opportunity: measuring the old and new sites on the same server, over the same network, with the same test, minutes apart.
Most “we made it faster” posts compare a neglected old site on cheap hosting against a new site on better infrastructure. This is not that. Same VPS, same nginx, same pages. The only variable is the software.
The numbers
We loaded each page three times with a fresh browser under Google’s mobile lab conditions - the “Slow 4G” network profile with a 4× CPU slowdown, the same conditions Lighthouse uses - and took the median. LCP is *Largest Contentful Paint*, Google’s measure of when the main content is visible.
| WordPress (old) | Static (new) | |
|---|---|---|
| LCP - homepage | 1.16 s | 0.62 s |
| LCP - service page | 1.09 s | 0.60 s |
| Fully loaded - homepage | 1.8 s | 1.0 s |
| Fully loaded - service page | 2.1 s | 1.0 s |
| Requests per page | 21-25 | 6 |
| Page weight | 213-341 KB | 104 KB |
Roughly twice as fast to first meaningful paint, with a quarter of the requests and a third to half the weight - and the third-party tools agree. GTmetrix (testing from Sydney) scored the new site **A, 100% performance: LCP 511 ms, zero blocking time, zero layout shift**. Google’s PageSpeed mobile lab puts LCP at 1.2 s against a “good” threshold of 2.5 s.
Two honesty notes. First, our WordPress site was lean by WordPress standards - a typical Divi or Elementor site ships one to three megabytes and would look far worse in this table. Second, the old site previously ran a server-side page cache that the archived copy no longer has; that flatters the new site’s server-response gap slightly, but does nothing to close the payload gap, which is where most of the difference lives.
Where the difference comes from
When someone opens a WordPress page, the server assembles it on demand: PHP starts, queries a database, runs the theme and every plugin, and only then returns HTML - which references twenty-odd files of theme CSS, plugin scripts and builder JavaScript the browser must also fetch and execute.
A static site did all that work before anyone visited. The server’s whole job is handing over a file that already exists. Our build ships no JavaScript framework at all - which is why “total blocking time” is literally zero - and self-hosts its two fonts, so nothing waits on a third party.
So does speed change your Google ranking?
Here is the honest version, in three parts.
As a direct signal: yes, but modestly. Google has confirmed page experience - including Core Web Vitals, the metrics above - is used in ranking. It behaves like a tie-breaker between comparably relevant results, not a trump card. A slow site with the best answer still beats a fast site with a worse one. Anyone promising “top of Google” from speed alone is selling something.
Indirectly: more than the direct signal. Slow pages lose visitors before they load - and visitors who bounce straight back to the results page are their own negative evidence. Speed also affects crawling: Google allocates finite attention per site, and a server that answers in 70 milliseconds gets more pages crawled, and re-crawled sooner, than one that takes two seconds. Fresh content that gets indexed faster compounds.
For AI search: increasingly important. A growing share of discovery now happens through AI assistants, and many of their crawlers do not execute JavaScript or wait around - they fetch a page, read the HTML they receive, and move on. A fast page whose entire content is present in plain HTML is trivially easy for machines to read and cite. That describes a static site exactly.
What this means for your business
If your website is slow and your content is thin, you have a compounding problem - but fix the content first, because that is the part that ranks. Speed then removes the drag: fewer lost visitors, better crawling, cleaner Core Web Vitals, and pages that machine readers can actually digest.
And if your site runs on WordPress with a page builder, it is worth knowing what it costs you. You can test any site free at pagespeed.web.dev - if your mobile LCP is over 2.5 seconds, you are giving away performance your competitors do not have to beat you on.
Ours is public: run pearceit.com.au through it and you will see the numbers in this post. We publish them because we build and run websites on this stack
- for ourselves first, and for clients who want the same result.
Pearce IT is a managed intelligence provider in Greater Melbourne. If any of this maps to your business, book a 30-minute review.
← All posts