One WordPress page, built three ways: 63 → 99 on PageSpeed
I took one landscaping-company homepage and built it three ways: a bloated Elementor build, the same Elementor optimized in place, and a lean hand-coded rebuild. Each one measured on Lighthouse mobile. Below is exactly what changed, by how much, and why.
Three states, one page
| Build | Perf | A11y | BP | SEO | LCP | Weight |
|---|---|---|---|---|---|---|
| Beforebloated Elementor | 63 | 96 | 100 | 85 | 26,5 s | 5111 KiB |
| In placeElementor kept | 71 | 96 | 100 | 85 | 5,9 s | 1183 KiB |
| Lean rebuildhand-coded, no builder | 99 | 100 | 100 | 100 | 2,0 s | 461 KiB |
All three render the same full-width landing (hero, about, gallery, contact form). Only the build and the speed differ. Desktop scored high from the start; the problem lives on mobile.
One landscaping homepage, built on a page builder
Fictional brand Greenfield Landscaping, a single full-width homepage. Built on OceanWP + Elementor, the same stack as most of the sites people hand me to speed up. Every measurement is Lighthouse on the mobile preset with simulated throttling, so the numbers reflect a mid-range phone, not a desktop on fibre.
What was dragging it down
- Hero and gallery photos served as full-size 2400px JPEGs (~5 MB) into small slots on the page.
- The hero is a CSS background image, discovered late by the browser, so LCP waited behind everything else. That is the 26.5 s.
- OceanWP + Elementor + Happy Addons + Contact Form 7 + Font Awesome + AddToAny each enqueue CSS and JS site-wide. Three of them are not even used on this page.
- Render-blocking Google Fonts (Roboto + Roboto Slab, every weight), with no preload.
In place: fix it without touching Elementor
First the version for someone who does not want to change how they edit the site. Everything goes through one mu-plugin, no rebuild, the editor stays exactly as it was.
- Images converted to display-sized WebP with a Python script (Pillow): ~5 MB down to ~0.8 MB.
- Deactivated the three unused plugins, removed Google Fonts, fell back to system fonts.
- Lazy-loaded the below-the-fold images, preloaded the hero (the LCP element).
Result: 63 → 71 Performance, LCP 26.5 s → 5.9 s, page weight down 77%. Big, real wins, and the editor is untouched.
The remaining ceiling is the page builder's render-blocking CSS. Hand-rolling critical CSS made it worse (more HTML plus layout shift), so the honest in-place ceiling on free tooling is the low-to-mid 70s. Going higher needs a paid optimizer that does automatic critical CSS and JS delay.
Lean rebuild: same page, no builder
Same content, same layout, no WordPress and no page builder. One HTML file with the CSS inlined, so nothing blocks the first render.
- One HTML file, CSS inlined (zero render-blocking stylesheets).
- System fonts, so no font download on the critical path.
- AVIF with a WebP fallback for the photos.
- Responsive hero with preload; below-the-fold images lazy-loaded with width and height set, so CLS is 0.
Result: 99 / 100 / 100 / 100, LCP 2.0 s, 461 KiB. The page weight is 91% lower than the bloated build, on the same content.
A page builder has a ceiling, and it is honest to say so
The page builder's render-blocking CSS costs a chunk of Performance that free tooling cannot claw back without a rebuild. In-place optimization still delivers large, real wins (weight down 77%, LCP 26.5 → 5.9 s) without changing how you work. The high 90s on mobile need either a paid optimizer or a lean rebuild. Anyone promising a page builder at 100 on free tooling is either measuring desktop or not measuring at all.
"Speed up my WordPress"
You keep the editor. I optimize in place: images, fonts, unused plugins, lazy-load, preload. Large wins, honest about the ceiling.
"Rebuild it properly"
Same page, hand-coded. I remove the builder's render-blocking CSS entirely and the page reaches 99/100 on mobile.
Send me your site's URL
I measure it on mobile and tell you which path is worth it, before any contract.
Get a speed check