Most of the loss sits in one place, and it is probably not your plugins.
What is actually making your WordPress site slow
Your server takes too long to send the first piece of the page. WordPress builds each page fresh from code and a database read, every time. Then your photos, the heaviest thing you load. Then the theme and page builder, loading style and code files that hold the page back from showing. Then the plugin pile and outside scripts on top.
The site is slow to show up. It is not laggy to tap once it is there. In HTTP Archive’s March 2026 measurement of 8.9 million sites, WordPress passed the tap-response measure 90.6% of the time, against 82.0% for the web as a whole.
That is the usual order, not a diagnosis of your site. To know yours, run the test on your own address, on the mobile tab.
A score of 40 is poor, and it is normal for WordPress
Google’s Lighthouse documentation sets the bands: 0 to 49 poor, 50 to 89 needs improvement, 90 to 100 good. So 40 is poor. It is also ordinary. In HTTP Archive’s March 2026 measurement, the middle WordPress site scored 43 on mobile, and 40 for sites running Elementor.
Click the mobile tab. The same measurement puts the middle WordPress site at 63 on desktop, a kinder number than the one real visitors live through. Lighthouse’s documentation says the mobile test simulates a 150 millisecond round trip, 1.6 Mbps, and a processor slowed four times, the bottom quarter of 4G.
In the same measurement, the middle Astro site scored 68 on mobile against WordPress’s 43.
Your server takes too long to answer
In HTTP Archive’s March 2026 measurement, 24.2% of WordPress sites had a good server response time on mobile. Across the web it was 45.1%, Squarespace 80.2%, Shopify 85.6%.
The reason is in WordPress’s own documentation. It needs PHP and a database to build a page. Its memory cache is thrown away at the end of each request, the documentation says, unless a plugin keeps it. So every visit re-runs the code and re-reads the database.
web.dev calls a server response of 0.8 seconds or less good. Chrome’s documentation says the test fails the page when the browser waits more than 600 milliseconds.
The same series ran 24.2% in March 2024, 26.3% in 2025, and 24.2% again in 2026. Other measures improved over those two years. This one did not.
A faster host lowers this number. It does not change how the page is put together. Moving hosts is the cheapest fix here, and the one with the smallest ceiling.
Your photos are the heaviest thing on the page
HTTP Archive’s March 2026 measurement puts the middle WordPress page at 1.0 MB of images on mobile, 1.08 MB on Elementor sites, against 784 KB across the web.
Plugins piling on megabytes of code is not what the numbers show. WordPress ships 683 KB of JavaScript at the middle, under the 743 KB web median. The weight is in pictures, most of it uploaded straight off a phone.
The 2025 Web Almanac found 62% of mobile pages carry images with no width and height set, and 16 to 17% delay loading the main image.
Shrink your photos before you upload them. A plugin can resize and compress them on upload, and that works. It cannot stop a page builder that asks for the full-size file.
What a caching plugin fixes, and what it does not
All of these come from HTTP Archive’s March 2026 measurement, on mobile.
| Setup | Passes with real visitors | Good server response | Middle score |
|---|---|---|---|
| WordPress, no cache plugin | 48.7% | 24.2% | 43 |
| WP Rocket | 52.2% | 32.0% | 50 |
| WP Fastest Cache | 55.7% | 43.0% | 41.5 |
| W3 Total Cache | 44.6% | 21.8% | 39 |
W3 Total Cache sits under the plain WordPress baseline on all three. Sites running NitroPack post a middle mobile score of 62.5, almost 20 points up. Only 56.1% pass with real visitors, and 26.4% have a good server response, barely above plain WordPress. Twenty points on the test, and almost nothing at the door.
A caching plugin does fix things. It saves a finished copy of the page, so the server stops rebuilding it for every visitor. It shrinks photos on upload and combines code files.
There are two things it cannot touch. The style and code files your theme and page builder insist on loading before the page will show. And the page is still assembled on request, so the copy gets rebuilt every time it expires.
What a rebuild fixes, and what we cannot promise
A different kind of site skips the assembly. Pages are built once, saved as plain files, and handed over with no code run and no database read when someone clicks. In the same March 2026 measurement, Astro sites pass Google’s real-visitor measures 67.7% of the time against WordPress’s 48.7%. Good server response, 60.2% against 24.2%. Middle mobile score, 68 against 43. Middle page weight, 1.66 MB against 2.73 MB.
That comparison has limits. Astro sites are 0.3% of the sites measured and mostly built by developers, so it is not a controlled test. JavaScript is only 7% lower, 633 KB against 683 KB. Static files remove the server work and the photo weight, not code you choose to add. Google says its page experience measures are one signal among many, and a good score does not ensure a ranking. The number Google uses comes from real visitors, not from the test. We do not publish client results. A rebuild does not fix a wrong phone number, a bad photo, or a visitor on a weak signal.
We rebuild sites like this on Astro as static files on Cloudflare. See the website build and the current complete pricing.