How I rebuilt a 4-second website to 0.4 seconds

A car dealership showed me their website on my phone once and then apologised for it. That's the part that stuck with me. They were selling six-figure cars, the photography was genuinely good, and the site took about four seconds to draw a single photo. You'd tap a Lamborghini and watch a grey box think about it. They knew, and they were embarrassed, and they'd stopped sending people the link.

This is the Project One Motors site, a supercar and luxury dealership here in Dubai. I shoot cars and I build the web stuff, so I got to see both sides of the problem, and both sides were the same problem: the website was slow and it was miserable to update.

What was actually slow

It was WordPress on shared hosting with a heavy theme and a stack of plugins, and every one of those things was quietly charging rent. Nothing exotic, just the usual pile-up. A page had to boot PHP, run a bunch of database queries, assemble the HTML on the fly, then ship a theme that loaded its own CSS and JavaScript for features nobody used. All of that happened in one data centre somewhere far from the person tapping the link in Dubai traffic.

But the real killer was the images. A dealership site is basically a photo gallery with prices on it. The photos were going out as full-resolution JPEGs straight off the camera, some of them four or five megabytes each, at dimensions way bigger than any phone would ever show. So the four seconds wasn't one slow thing, it was the server thinking, then the page bloating, then several megabytes of un-optimised photos crawling down a mobile connection. Death by a thousand cuts, and the cuts were all photos of cars.

The other cost was invisible to visitors but brutal for the team. Publishing one car meant touching it in about three different places. The listing, the gallery, some featured block on the homepage, each edited separately, each easy to get slightly wrong. So cars would sell and stay listed, or get listed with the wrong price in one spot. A slow site you can at least wait out. A confusing publishing flow just quietly rots.

The rebuild

I rebuilt it in Next.js and moved the whole thing onto Cloudflare's edge. The idea is simple: stop assembling pages on demand and start serving pages that are already finished. Instead of a server building the HTML fresh for every visitor, the pages get generated ahead of time and cached on Cloudflare's network, which has a location minutes from basically everyone in the UAE. So when someone in Dubai taps a car, the page is already sitting on a machine near them, done, waiting. No PHP booting, no database round-trip, no theme waking up. It just arrives.

Then I went after the images properly, because that was most of the four seconds. Every photo gets converted to WebP, which for this kind of glossy car photography is usually a fraction of the JPEG size at a quality difference nobody can see. Each one gets resized to sane dimensions and served at the size the device actually needs, so a phone downloads a phone-sized image instead of a print-sized one. A five-megabyte hero shot becomes a couple hundred kilobytes that still looks sharp. Multiply that across a gallery and the page stops being heavy. This is the exact conversion my WebP tool does, by the way, I just automated it into the publishing pipeline so nobody has to think about it.

And I built a custom admin so publishing a car is one workflow, not three. You fill in the car once, drop the photos in, hit publish. The listing, the gallery, the homepage, they all read from that one source. There's no place to forget to update, because there's only one place. That change did as much for the team's sanity as the speed did for the visitors.

The part everyone forgets: not breaking Google

Here's where a rebuild can quietly wreck a business. If you move a site and change all the URLs, Google treats every page as new, your rankings reset, and you can lose months of hard-won search traffic overnight. A faster site that nobody can find is not an upgrade.

So I kept the URLs the same. Every car and every page landed at the exact address it lived at before, so Google saw continuity instead of a brand-new site. I carried over the structured data too, the schema that tells search engines this is a car, this is the price, this is the dealership, so the listings kept whatever rich results they had. The migration was deliberately boring on that front, which is exactly what you want. Rankings held. Nobody had to rebuild their SEO from zero.

The result

The Project One Motors rebuild cut page load from about four seconds to roughly 0.4 seconds, measured in PageSpeed Insights. Same photos, same content, roughly a tenth of the wait. The grey box that used to think about it is gone. You tap a car and the car is there.

The dealership stopped apologising for the link. They send it now. And the team publishes cars in one pass instead of playing whack-a-mole across three screens. That second part almost matters more, because a fast site you dread updating slowly drifts back into a slow site. The speed is the headline, but the boring stuff underneath it, the WebP pipeline, the preserved URLs, the single publish flow, is what keeps it fast after I've moved on to the next thing.