Most people do not think about how fast a website is. They just leave.
That is the whole problem in one sentence. Nobody sits on a slow page and thinks about JavaScript payloads. They wait a beat, decide it is not happening, and go back to Google. On a phone, on patchy signal, that decision gets made long before the page has finished arguing its case.
Rockfig Lodge is a private safari lodge in the Madikwe Game Reserve. Someone finds it, taps through to look at the villas, and either sends an enquiry or does not. Everything else on the site exists to serve that one moment.
On a phone, the home page took 21 seconds to show its main image.
It now takes 4.4 seconds, at roughly a tenth of the weight. Across the six main page types, the site is 80% lighter.
One thing to say up front, because it changes how you should read the rest of this. We built the original. Rockfig has been a client of one2love, our web design and development studio in Plettenberg Bay, since 2022, and the site we rebuilt in July 2026 is the site we shipped four years ago. This is us going back into our own work with better tools and a harder standard.
The results in brief
- Home page time to appear: 21.0 seconds down to 4.4 seconds on mobile.
- Combined weight of the six main templates: 17,082 KB down to 3,475 KB, a reduction of 80%.
- Home page weight: 4,878 KB down to 507 KB, a reduction of 90%.
- Plugins: 16 down to 10, with all ten in active use.
- Builder: Elementor and the Crocoblock suite replaced with Bricks and ACF.
- Design: unchanged. The rebuild was held to 1:1 visual parity.
- Found along the way: 13 pages publishing as blanks, 2 features rendering at zero pixels, a media library where only 12 of 697 images carried a real description, and an article archive with no way to reach older posts.
Below is what changed, what it cost, and the part I find more interesting than the speed: what we found once we had to take the site apart in order to move it.
Table of Contents
The stack that worked in 2022: Elementor and Crocoblock
The original site was built on Elementor, with the Crocoblock suite alongside it. If those names mean nothing to you, they are page-builder tools: one handles layout, the other handles custom content like villas, experiences and reviews.
It was a sound call at the time, and I would make it again with the same information. That combination gave a small lodge genuinely custom content, filtering, pop-ups and a booking journey, without a bespoke build and a developer on retainer to change a price. That mattered. It ran for four years and the client could manage their own site the whole time.
Three things changed underneath it.
1. The measure moved. On 12 March 2024, Google replaced First Input Delay with Interaction to Next Paint as a Core Web Vital. The old measure asked how quickly a page responded to the first tap. The new one asks about every interaction, all the way through the visit. A page carrying a lot of JavaScript could pass the old measure comfortably and fail the new one, and page-builder stacks carry a lot of JavaScript.
2. The tools moved. Bricks Builder 1.0 shipped in March 2021, so it was about a year old when we built Rockfig. The combination we used for this rebuild, Bricks for layout and ACF for the content model, was not a realistic option back then. It is now, and it does the same job at a fraction of the front-end weight.
3. Sites drift. A large plugin stack changes beneath you. Plugins update, renderers change, and a feature that worked can quietly stop working with no error, no warning and nothing in any dashboard to tell you. I will come back to this, because two of the more embarrassing findings on this job are exactly that.
So the honest framing is not that the old stack was a mistake. The weight was the price of that feature set with those tools, and that price is no longer necessary.
The brief: rebuild the foundation, not the design
The client did not ask for a new website. They asked for the one they have, working better.
So the constraint was 1:1 visual parity. Same layout, same brand, same content, same booking journey, rebuilt on a foundation that does not cost a visitor nearly five megabytes to look at a photograph. Every intentional deviation from the original had to be written down, justified and signed off before it shipped. There is a document listing all of them.
That constraint is the useful part. When you are not allowed to hide behind a redesign, the only place performance can come from is the engineering.
What we replaced: Elementor and Crocoblock out, Bricks and ACF in
- Elementor and Elementor Pro out, Bricks in. Bricks writes leaner code and loads far less by default, so pages arrive smaller before anyone optimises anything.
- The Crocoblock stack out, ACF in. JetEngine, JetElements, JetPopup and JetSmartFilters all came off. The custom content they managed, meaning villas, lodge experiences, reviews and galleries, moved to ACF, which does the same job without the front-end overhead.
- Plugins: 16 down to 10, and all ten are in use. Nothing dormant, nothing loading on every page for a feature that was switched off years ago.
- Leftover builder data cleared. 34 old builder records and 1,417 rows of orphaned builder data removed from the database.
- The third-party font origin eliminated. The site pulled its typeface from Adobe Fonts, which is still served from Typekit’s own domain. That is about 50 KB and a blocking request to somebody else’s server before any text could appear. Fonts are now served from the site itself.
None of that is visible to a visitor. All of it is felt.
The numbers: Rockfig before and after
Measured with Lighthouse 13.4.1, run from the command line rather than the web version, driving headless Chrome 150 on its default mobile preset. That simulates a mid-range phone on a throttled 4G connection, which is a deliberately unkind set of conditions and closer to how a lot of people actually arrive at a lodge website than a desk on fibre is.
The baseline was captured on 25 July 2026 and the rebuilt site on 28 July 2026. Same machine, same tool, same settings, both on the live domain behind the same CDN. We waited until after go-live to take the second set rather than measuring the new build on staging, because comparing a live site sitting behind Cloudflare against a staging site that is not behind anything is not a comparison. It is a way of producing a nicer number.
“Time to appear” is how long a visitor waits before the main image or heading actually shows on screen. It is the metric Google calls Largest Contentful Paint.
Page weight
| Page | Before | After | Reduction |
|---|---|---|---|
| Home | 4,878 KB | 507 KB | 90% |
| Villas | 2,572 KB | 699 KB | 73% |
| Individual villa | 3,435 KB | 789 KB | 77% |
| The Lodge | 2,264 KB | 541 KB | 76% |
| Journal archive | 2,403 KB | 591 KB | 75% |
| Journal article | 1,530 KB | 348 KB | 77% |
| All six templates | 17,082 KB | 3,475 KB | 80% |
Time to appear and speed score
| Page | Time to appear before | Time to appear after | Speed score before | Speed score after |
|---|---|---|---|---|
| Home | 21.0s | 4.4s | 53 | 84 |
| Villas | 13.2s | 5.4s | 60 | 74 |
| Individual villa | 17.7s | 5.5s | 55 | 78 |
| The Lodge | 13.8s | 4.5s | 58 | 84 |
| Journal archive | 13.5s | 5.2s | 60 | 79 |
| Journal article | 12.8s | 3.2s | 59 | 93 |
A few supporting figures:
- On desktop, four of the six page types now score a perfect 100. The article template scores 97 and the home page 93.
- Total Blocking Time is 0ms on every template. That is the lab measure of how long a page is busy processing rather than able to respond to a tap. It is the closest thing you can check before real visitors arrive, and it stands in for Interaction to Next Paint, which can only be measured from actual visits. There is no longer any blocking time to speak of.
- Layout shift is at or below 0.038 everywhere, comfortably inside Google’s 0.1 threshold. Nothing jumps under your thumb as the page settles.
- Best practices scores 100 on every page. Accessibility moved from a range of 91 to 92 up to a range of 95 to 96. SEO sits between 92 and 100.
One honest caveat, because it matters more than a rounder number would. Treat the speed scores as a range, not a fixed figure. Simulated throttling is the reason. Lighthouse fetches the page once and then models what a slow connection would have done with it, so small variations in that single fetch get amplified into several points of score. On repeat runs of identical mobile pages we watched a 74 come back as 82, and an 84 come back as 93. Page weight and time to appear do not move like that, which is why we quote those exactly.
Two things worth knowing if you want to check any of this yourself. PageSpeed Insights runs the same engine, so the lab scores it gives you should land within a few points of ours rather than matching exactly. But PageSpeed Insights also reports field data, meaning Core Web Vitals collected from real Chrome users, and that is a different measurement entirely. It needs roughly 28 days of traffic before it populates at all. So if the two numbers on that page disagree with each other, or with us, nothing is broken. If you want a figure that does not move, use the page weight.
What we are not claiming yet
The obvious question is what this did for the business, and the honest answer today is that it is too early to tell you. The site relaunched recently, enquiry volume for a lodge moves with season as much as anything else, and a fortnight of analytics is not evidence of anything. I would rather say that than put a number here that flatters us.
What we have committed to is measuring it properly. We will publish a follow-up with the post-launch data once there is a meaningful window to compare against, including real-world Core Web Vitals from actual visitors rather than lab tests, and whatever the enquiry and search figures turn out to say. If they say very little, we will publish that too.
The part nobody could see
Here is the thing about a conversion. You have to open every template, read every field and account for every element. You cannot skip a page because it looks fine. And “looks fine” turned out to be doing a lot of heavy lifting.
Some of what follows was a decision that did not age well. Some of it drifted, meaning a plugin updated, a renderer changed, and a working feature quietly became a broken one. Four years later I cannot always tell you which was which, and it does not much matter. The point is that none of it was visible from the outside, and nothing reported it.
Thirteen pages were publishing as blanks
The lodge experience pages, meaning bird watching, star gazing, game drives and ten others, were live, indexable and empty.
The copy existed. It had been written for a pop-up on the lodge page, and the underlying pages existed only to feed that pop-up. They were never meant to be destinations. But they were published, so search engines found them and indexed thirteen blank pages.
That is a small architectural choice with a consequence nobody sees for four years, because nothing about the site looks wrong. The copy now lives in the page content where it belongs: visible, indexable, and editable in the normal editor without touching a builder.
Two features that were zero pixels tall
The lodge highlight cards were meant to open a pop-up. The element that triggered it computed to a height of zero, because its only child was an empty link. So there was no clickable area anywhere on the card. The pop-up existed. It could not be opened.
Then, during the accessibility pass after launch, we found the second one. The previous and next navigation on journal articles was rendering as an invisible link, zero pixels by zero pixels. Readers finishing an article had no way to move on to another one.
I cannot tell you when either of them stopped working, and I am not going to pretend otherwise. What I can tell you is that nothing anywhere reported it. No error, no broken link in a crawl, no drop obvious enough in analytics to trace back to a cause. A feature that renders at zero pixels looks exactly like a feature nobody uses.
Both are now real, working, indexable navigation. Together with the blank pages, that is three things the website was designed to do and simply was not doing.
The image descriptions had two different causes
Every image on the old site appeared to have a description attached. It did not. The old builder was echoing image filenames and titles into that field as the page rendered. So the automated checks passed, and a screen reader announced DSC_4471-1-scaled.jpg.
The media library itself had proper descriptions on 12 images out of 697.
That is what happens when a tool papers over a gap helpfully enough that nobody notices there is a gap. A rebuild inherits the library, not the improvisation, which is exactly why it had to be fixed at source rather than patched at render time again.
407 images were backfilled from their captions and titles. 278 were deliberately left blank, because they are logos, icons and decorative marks, where a filename as a description is actively worse than nothing. The gallery went from 151 images with no description to one.
That distinction is the whole job. Filling in every field would have scored better on an automated audit and been worse for an actual person using a screen reader.
It is also the most durable thing this rebuild produced. It lives in the media library now, not in a builder’s render step, so it survives the next rebuild too.
The gallery was a 12,000 pixel page
170 images, all loaded upfront, on a page over 12,000 pixels tall.
No gallery is built at 170 images. It gets there, four or five at a time, over four years, and no single upload is the one that breaks it. Rebuilt to load in batches as you scroll, the first load is roughly a quarter of the length. The lightbox and the tab filtering work exactly as before.
The journal had no way to reach older articles
The archive loaded its first batch of posts and stopped. There was no pagination of any kind, so most of the 38 articles could not be reached from the journal at all, only through search or a direct link.
Same shape of problem as the gallery. With eight posts you do not notice. With thirty-eight you have a dead end. The archive now loads continuously as you scroll, and every article is reachable.
The home page hero was renting a megabyte from YouTube
The background video was a YouTube embed, which is still how most sites put a background video on a home page. Before a single frame plays, it pulls in around thirty separate requests and roughly a megabyte of YouTube’s own player code, on the critical path of the most important page on the site.
On phones the page now shows a still photograph and the player never loads at all. Not hidden with CSS, genuinely absent. We checked and confirmed zero requests to YouTube on mobile, because hiding an embed rather than removing it is a very common way to not fix this problem.
That single change took roughly a megabyte off the most important page on the site, before we had optimised anything else on it.
What this has to do with SEO and AI search
Two questions come up every time we talk about a rebuild, so it is worth answering both plainly.
Does speed affect your search ranking? Yes, but less than people think. Google uses Core Web Vitals as a ranking signal, and the measure changed in March 2024 as described above. It is a real signal. It is also, in our reading, a modest one, and it will not lift a page above genuinely better content. Speed is a tiebreaker between comparable pages and a quiet tax on everything else you do. What it definitely affects is whether a visitor stays long enough to become an enquiry, which is the part that pays.
Does speed affect whether AI assistants recommend you? This is the question I get most at the moment, and the honest answer is not the one people expect.
Speed itself is not what gets you cited. Being readable is.
When someone asks an assistant to recommend a lodge, the tools behind that answer fetch your pages and read the code. Many of them do not run a page the way a browser does, so anything that only appears once the page has finished assembling itself may not be there when they look. They also give up on slow responses, in the same way any other crawler does.
So look at what this site was presenting to a machine before the rebuild. Thirteen experience pages that returned nothing at all. A gallery where 151 images had no description. Image descriptions that were camera filenames. Most of the journal unreachable from its own archive. An imagery-led site with junk descriptions is close to invisible to something trying to read it.
None of that is a speed problem. All of it was fixed by the same rebuild, because it is the same work. Making a site fast is mostly the work of removing whatever sits between your content and the thing reading it, whether that is a person, a search engine, or an assistant answering a question on your behalf.
One check I would add for anyone thinking about this, and it has nothing to do with your website. Confirm that nothing at your hosting or CDN level is blocking AI crawlers. A number of providers switched that on by default over the last year or two, and it is easy to inherit without knowing. If it is active, the quality of your content is irrelevant, because the tools cannot see it at all.
The optimisation we took back out
This is the part I would want you to read if you only read one section.
Near the end of the build we tried to squeeze one more gain out of the site for free, by serving images in a modern, much smaller format at the website level rather than paying for it at the network level.
We tested it properly. It worked, and then it did not. The server never sent the caching instruction that tells the network who a stored image was built for, which meant the site would happily hand a modern image format to browsers that cannot display it. In practice, some visitors on older iPhones would have seen broken images where the villas should be.
We reversed it the same day and told the client exactly what had happened and why. The correct way to do this is at CDN level, which is what we have recommended. It costs about US$20 a month and we would expect it to cut image weight by roughly another 30% on top of the figures above. It has not been implemented, so none of the numbers in this article depend on it.
We could have shipped it quietly. Most of the time nobody notices, because most of the time nobody tests on a five-year-old iPhone.
That is also how a link ends up at zero pixels and stays that way. Not because anyone was careless, but because nothing tests the thing nobody thinks to look at.
The takeaway: WordPress site speed is the baseline, not a feature.
The version of this article that writes itself is “Bricks is faster than Elementor”. It is, and the tables above are one more data point. But it is the less useful conclusion, and it would be a slightly dishonest one coming from us, given who built the site we are comparing against.
Two things are more useful.
The bar moved, and it keeps moving. Speed used to be a differentiator, the thing a fast site had and its competitors did not. It is not any more. It is the baseline, the price of being taken seriously by a search engine and by a person with a phone and no patience. A site that comfortably cleared the bar in 2022 can be under it in 2026 without a single thing about it changing.
A rebuild is the only audit a website cannot argue with. Thirteen blank pages, two invisible features, an unreachable archive and an image library that had been improvising for years. None of that appeared in a plugin dashboard, and no amount of caching or compression would have surfaced it. It was found because somebody had to open every template and account for every element in order to move it.
You do not get to 80% lighter by installing a caching plugin. You get there by taking out the things that were making the site heavy, which means first finding out what they were.
Short version: website speed is the baseline, not a feature. Everything above is what the baseline actually costs. And I would rather find this in our own work than have a client find it in theirs.
Elementor to Bricks: frequently asked questions
Is Bricks really faster than Elementor, or is that just marketing?
It is structural, not magic, and it is not a knock on Elementor. We have built plenty of good sites on it. Bricks writes far less code and loads far fewer files by default, so a page starts lighter before anyone optimises it. On Rockfig the six main templates went from 17,082 KB to 3,475 KB, and we published the same kind of before-and-after for a WooCommerce rebuild at Jewels & Time. That said, most of the gain on any given project comes from what a rebuild lets you remove, meaning builder add-ons, duplicate plugins and third-party embeds, rather than from the builder swap on its own.
Will my website look different after a Bricks rebuild?
Not unless you want it to. Rockfig was rebuilt to 1:1 visual parity: same design, same content, same booking journey. We keep a written record of every intentional deviation, whether that is a heading level corrected, a button colour fixed for contrast or a gallery set to load progressively, and each one is signed off before it ships. If you want a redesign as well, that is a separate decision, and it is usually cheaper to make it once the foundation is sound.
Do I lose my content, URLs or SEO rankings when moving off Elementor?
No, and this is where a migration is won or lost. Every address, page title and search directive is crawled before and after, then compared line by line. On Rockfig all 77 pages in the sitemap returned the same status and the same title on both. Thirteen pages gained a description they had never had, and 38 articles gained structured data. The aim is that search engines see continuity first, then improvement.
Does a faster website help me get recommended by AI assistants?
Not directly, and be wary of anyone who tells you otherwise. What matters is whether the tools can read your pages: clean code, content that is actually in the page rather than assembled afterwards, real descriptions on your images, and structured data. Speed correlates with all of that because the same rebuild produces both, but it is not the cause. Worth checking separately: that your host or CDN is not blocking AI crawlers by default.
What happens to content built with JetEngine or other Crocoblock plugins?
It moves to ACF. A Crocoblock to ACF migration takes the content across field by field, and ACF handles the same custom content without the front-end overhead. Where the old setup had trapped copy somewhere unhelpful, as it had on thirteen Rockfig pages, that is the moment to put it back into the page content where search engines and your content team can both reach it. The old fields are left in place until the migration is verified, so there is always a way back.
How often does a WordPress site actually need rebuilding?
Not on a schedule, and not because it looks dated. It needs rebuilding when the foundation stops serving the site. For a plugin-heavy WordPress build that tends to land somewhere around four to six years, at the point where the tooling has moved on, the content has outgrown the structure, and enough has drifted underneath that patching costs more than replacing. Rockfig was four years old and it was ours. That is roughly the shape of it.
Is it cheaper to just optimise my existing site?
Often, yes, and if that is the honest answer for your site we will tell you. Caching, image compression and clearing out unused plugins go a long way. But optimisation has a ceiling, and that ceiling is whatever your builder loads before you get a say. When a site is already carrying nearly five megabytes on its home page and half a dozen builder add-ons, you spend real money for a modest improvement and you still own the same foundation afterwards.
Do I need to change hosting to get results like these?
Not necessarily. Rockfig’s numbers were measured on the client’s existing hosting and CDN, so the improvement came from the site itself, not from moving it. Good managed hosting compounds the effect, and a fast server cannot rescue a five megabyte page. If your hosting is the bottleneck we will say so, with the measurement that shows it, rather than selling you a migration you do not need.
Thinking about a rebuild?
If your site runs on Elementor, Divi or WPBakery and it has been getting slower every year, the first useful thing is a measurement, not a quote. Send us the address and we will run the same before-picture we ran on Rockfig: page weight, time to appear, what is loading and why. Then we will tell you honestly whether an Elementor to Bricks migration is worth it or whether an optimisation pass will do.
If we built your site between 2018 and 2023
Then this article is partly about you. The same drift that we found on Rockfig is sitting in other sites we shipped in those years, and we would rather find it than have you find it. Same offer, same measurement, and we will go first.
