Behind the Scenes of a Real-Estate Website Performance Tune-Up (Including What We Chose Not to Fix)

From the workbench: a member asked us to make their homepage faster. Here’s the behind-the-scenes account — what moved the needle, what we deliberately left alone, and why a performance “win” is never really finished.

First: why a real-estate website is a hard thing to make fast

It’s tempting to treat “make the site faster” as a checklist you run once. Real-estate sites resist that. They carry more moving parts than almost any other small-business website:

• Logged-in areas. Saved searches, favorites, and account pages can’t be cached like a plain brochure page — they’re different for every visitor, so the easy “just cache everything” answer doesn’t fully apply.
• Live listing data. Search results and map widgets pull from constantly-updating feeds, which means real work happening on real requests.
• An aggressive bot crowd. These sites get hammered by scrapers and automated traffic, so they sit behind firewalls and challenges that have to sort humans from robots before a page even loads.
• National-portal expectations. Visitors arrive having just used the big national search portals, which spend fortunes on speed. Fair or not, an agent’s site is judged against that bar.

On top of that, a platform like ours stacks several caching layers — a CDN at the edge, a web-server cache, an object cache, and a page cache inside WordPress. That’s great for speed, but it also means a “fix” can look like it did nothing simply because an older copy of the page is still being served. (More on that below — it bit us mid-project.)

Where we started — and a gentle word about that

Here’s the starting line. The homepage weighed in at close to 3 MB across well over a hundred requests, took several seconds to feel usable, and scored down in the 20s on a mobile speed test.

Before we go further, a confession and a reframe: this was a site we’re proud of. It launched fast and clean. What you’re looking at isn’t neglect — it’s the completely normal way websites gain weight over time. A marketing photo added here, a tracking pixel there, a new homepage section, a seasonal promo band. Each addition is reasonable on its own; together, over a couple of years, they add up. Performance isn’t a finish line you cross once — it’s maintenance, like an oil change. Sites drift from fast to heavy and back again, and the job is to notice and tune, not to feel bad about it.

The two changes that did the most — without touching a line of code

We always look for the highest-reward, lowest-risk levers first — especially on a live page that generates leads. But first you have to know where the weight actually is. We measured the homepage as a phone would load it, and the answer was unglamorous: photos and scripts were nearly the whole story.

That points straight at the two highest-reward levers — and neither required editing the theme, the database, or any files.

1. Optimize the images at the edge. The biggest single problem was photos. A handful of background images accounted for the bulk of the page weight — a single decorative photo was larger than the rest of the page combined. Rather than re-export and re-upload every image by hand, we turned on Cloudflare Polish — an image optimizer that re-compresses and converts photos to modern formats (WebP) at the network edge, on the way to the visitor. No markup changes, no files touched, instantly reversible. The result, verified on the live site: image weight dropped by roughly two-thirds — and because we set it at the platform level, it quietly optimized images across every site on the platform, not just this one.

2. Stop running every script on load. The homepage was loading a lot of JavaScript up front that the visitor doesn’t need in the first instant — maps, social pixels, a gallery library, and the usual marketing add-ons. Using WP Rocket’s “Delay JavaScript Execution,” we held that non-critical code until the visitor actually interacts with the page — a scroll or a tap. The browser gets to paint the page first and do the heavy lifting second. This is the setting that finally moved the score.

A candid aside on how messy that second one got: at first it appeared to do nothing. The page looked identical and the speed test didn’t budge. The culprit was exactly the caching layers we mentioned — an upstream cache was serving an older copy of the page, so the optimization never got a chance to run. We had to purge the page at the edge and learn to verify the result through the speed test itself rather than by inspecting the delivered code. A good reminder that on a multi-layer platform, “it didn’t work” often means “you’re looking at yesterday’s page.”

The fork in the road on images

“Just optimize the images” sounds like one decision. It’s really three, and they trade off differently. Because the member is on Cloudflare’s Pro plan, we had real options:

• Polish (what we chose). Flat cost on the Pro plan, zero code, optimizes every image automatically. Its one limitation: it re-compresses but doesn’t resize — a full-width banner stays full-width even on a phone that only needs a fraction of those pixels. We still captured the big byte savings now.
• Image Transformations. Cloudflare can also resize images per-device on the fly — the genuinely “right” long-term answer for the phone-shows-a-huge-image waste. But it bills per unique transformation and requires routing image URLs through a special path. More power, more moving parts, more to get wrong. We parked it for a planned, deliberate pass.
• Re-export every image by hand. The old-fashioned way. It works, but it’s a one-time fix that doesn’t scale and has to be redone every time someone uploads a fresh photo. We skipped it.

We took the win that was flat-cost, zero-risk, and platform-wide today, and we wrote down the more powerful resize work as a future, scheduled task. That’s a deliberate choice, not an oversight.

What we chose not to do — on purpose

This is the part most “look how fast we made it” posts leave out. There was easily a few hundred more kilobytes on the table, and we walked past it — for now — with eyes open:

• We left the map script loading the way it was. The mapping library is heavy and could be loaded only when needed. But doing it right means editing the theme on a live homepage, and a broken map on a real-estate site is a real problem.
• We didn’t trim the third-party scripts themselves. Delaying them helped, but several add-ons still load on every page whether that page uses them or not — removing the unused ones, or loading them only where they’re needed, would cut real weight rather than just postponing it. That’s work inside the page builder and the tag setup, where it’s easy to break analytics or a gallery, so it belongs in a careful staged pass.
• We didn’t do per-device image resizing yet — the bigger image win described above — for the same reason: it deserves a staging environment and a careful pass, not a quick toggle on a Friday.

The logic is simple and a little unglamorous: on a page whose entire job is to capture leads, a broken form or a missing map costs far more than a heavier page. The reversible, no-code wins were worth taking immediately. The code-level wins are worth doing — carefully, on a staging copy, as their own project. Speed is valuable; a working lead pipeline is sacred. When the two compete, the lead pipeline wins.

Meanwhile, the member wanted the homepage to do more

Here’s the wrinkle that makes this a real-world story instead of a tidy case study. At the same time we were trying to make the homepage lighter, the member asked us to make it richer — new features that tailor the homepage to each visitor. More personalization means more code and more data, i.e. the very thing a performance pass is trying to reduce.

It would be easy to get high-and-mighty here — to say “no, that’ll slow you down.” We don’t think that’s our job. Our job is to lay out the trade-offs plainly, and then help the member accomplish their goal. The personalization has real business value; the member knows their market better than we ever will. So we didn’t refuse it — we sequenced it: ship the zero-risk speed wins first, then build the new features deliberately, measuring weight as we go so the homepage stays fast and gets smarter. That balance — teaching best practices while respecting that the client owns the decision — is most of the actual work.

Where it landed

After the two no-code changes: the mobile speed score climbed from the 20s into the mid-70s, desktop reached a perfect 100, and the page shed close to half its weight. From a multi-second page to one that feels immediate, with no code deployed.

One last caveat, because a score can lie: delaying scripts can also delay analytics and ad pixels, which can undercount conversions on ad-driven campaigns — and a delayed spam-protection widget has to be re-checked to be sure the contact form still delivers every lead. We treat a green score as a starting point to validate, not a trophy to frame. The number that actually matters isn’t 100; it’s whether a faster page still turns visitors into conversations.

Performance is maintenance, not a milestone

If there’s one thing to take from this, it’s that website speed isn’t a box you check at launch and forget. Sites gain weight the same way we all do — gradually, for understandable reasons. A good performance practice is periodic: measure, take the safe wins now, schedule the riskier ones properly, and re-measure after every big content or feature change. The goal isn’t a perfect score on a single test. It’s a site that stays fast enough to keep the visitor — and keeps doing its real job while it does.

If your site has quietly put on weight and you’d like a clear-eyed look at it — including which fixes are worth the risk and which aren’t — that’s exactly the kind of checkup we enjoy. Say hello.