Speedtest

An IDX site is almost always going to feel heavier than a simple brochure site because it’s doing a lot more work, in real time.

When a page has live MLS data, the server (or your browser) has to run search queries, join property records, and build results on the fly. That dynamic nature limits how aggressively you can cache pages at the edge—every user runs different filters, prices change hourly, and listings flip from active to pending all day. Less cache = more round-trips to databases and APIs, which adds latency.

Then there are the assets. Property pages often load 20–50 high-resolution photos per listing, plus maps, school data, mortgage calculators, and chat/CRM widgets. Even with lazy loading, that’s a lot of HTTP requests and JavaScript to hydrate. Many IDX vendors also embed content via iframes or heavy front-end libraries; those sandboxes and scripts don’t block everything, but they do slow down rendering and push out “time to interactive.”

Finally, the architecture itself can add drag. Some IDX feeds still sync on schedules or throttle requests, so you’re waiting on their API—not just your own hosting. WordPress + IDX plugins can pile on database queries; React or Vue front-ends add hydration cost; and compliance requirements (attribution, disclaimers, map tiles) add more assets you can’t easily strip out.

None of this means an IDX site has to be painfully slow—but it does mean performance takes intentional engineering: image CDNs with WebP/AVIF, strict lazy loading, pre-rendered category pages, server-side caching of common queries, deferring non-critical scripts, and ruthlessly trimming third-party widgets. If you don’t do those things, the default experience of “live data + big images + many dependencies” will make an IDX site feel slower every time.