IDX Plugin Site Speed: Keep WordPress Fast at Any Scale

Does Adding MLS Listings Slow Down Your WordPress Site?

By The MLSImport Team

Last updated: October 30, 2026

You’ve found the listings you want to import, but you’re worried thousands of properties will grind your WordPress site to a crawl. It’s a fair worry, and you’re smart to ask before you flip the switch. Here’s the honest answer: no, importing MLS listings does not have to slow your IDX plugin site speed or hurt your visitors’ experience.

Most of the slowdown people fear comes from how listings reach your site, but listing count matters too: more listings mean more data to store and update. Four things decide your speed, and all four are yours to control:

• Your hosting plan
• Database indexes on the fields buyers search most (price, city, status, MLS number)
• Page caching plus a CDN (a network that serves files from servers close to the visitor)
• Importing only the market you serve, not the whole MLS

The rest of this guide shows you which settings decide that, and in which order to reach for them.

1. Does the IDX architecture you choose matter more than listing count?
2. Which IDX architecture holds up at peak demand?
3. Which failures MLSImport can fix locally, and which belong to the MLS
4. Database scale: what WordPress actually stores for 10,000 listings
5. Hosting requirements at 5,000, 10,000, and 50,000 listings
6. Caching, CDN, and object cache for large MLS sites
7. Why search pages are slower than listing pages
8. Where do listing photos actually live?
9. Sync strategy and slow-server timeouts
10. Should you filter your MLS feed or import everything?
11. Benchmarking IDX plugin site speed and hitting Core Web Vitals targets
12. Why did the site get slow after we added a property search?
13. What 20,000 DFW listings look like in practice
14. Frequently Asked Questions

Does the IDX architecture you choose matter more than listing count?

Yes, and it isn’t close. The plugin architecture you pick decides your site’s speed far more than how many listings you import. Most agents obsess over listing count and never ask what matters: where does the data live, and who serves the page?

An organic IDX plugin like MLSImport writes each listing into your own MySQL database as a native WordPress custom post type. Not an iframe, not a vendor widget, not a rented subdomain. The listing becomes content on your domain, so a caching plugin can flatten it into static HTML and your permalinks stay crawlable. Iframe IDX does the opposite: the search interface renders in a remote frame your cache can’t touch, re-fetched on every load.

That extra round-trip costs you, and the cost is structural rather than a figure we can quote. An organic cached page is a static file your own server hands over. An iframe page is that same file plus a second request to a machine you do not control, on every load, for every visitor, cache or no cache. Speed is one row of the trade; for Google credit, design, setup and what you keep if you cancel, see import vs vendor-hosted IDX.

More than one MLS? Since version 7.2, MLSImport connects up to seven boards to the same site, and your plan sets how many. Each board gets its own connection, field mapping and import tasks, one broken connection pauses only its own tasks, and a home carried by two boards shows once. Every board adds its listings to the same database, so add them all up when you size your hosting. See Can I connect two MLS boards to one website?

Comparison table: organic IDX vs iframe IDX

Get started today: right-click a listing on any IDX site you admire and check whether it’s a real URL on that domain or stuck in an iframe.

Which IDX architecture holds up at peak demand?

Native import holds up best at peak, because a cached listing page is static HTML your own server hands out and the MLS is not in the request at all. Hosted or on-domain rendering holds up exactly as well as the vendor’s platform does that day. Iframe or subdomain IDX is the most exposed of the three.

Straight disclosure, because that ranking favours our side: MLSImport is our own plugin, and it is a native-import plugin. The reasoning below is about where the page comes from under load, so you can check it against any product in the category, ours included.

Native import (MLSImport and other organic IDX plugins). At peak, full-page caching hands the same static HTML to every visitor, so a traffic spike becomes a static-file problem: more cache, a CDN, more PHP workers. The MLS feed is only in the picture during a scheduled sync, which is a background job rather than a page request.

Hosted or on-domain rendering. The pages carry your hostname, but the vendor’s servers build them. At peak your capacity is the vendor’s capacity. You cannot cache around it and you cannot buy a bigger server to fix it, so the thing to ask for before you commit is a public status page and an uptime record.

Iframe or subdomain IDX. Your cache cannot flatten the second request, so your peak traffic becomes their peak traffic. When their servers slow down, your search slows down, and the visitor blames your site.

Do not buy on a latency claim, ours or anyone else’s. Ask which machine serves the page when everyone arrives at once.

Get started today: open a listing page on the platform you are considering, disable JavaScript, and reload. What still renders is what your cache can serve at peak.

Which failures MLSImport can fix locally, and which belong to the MLS

MLSImport can isolate anything that runs on your own server: the database, the cache, the PHP configuration, the cron tick, and the import job itself. It cannot isolate the MLS’s API or the MLS’s image CDN, because neither runs on your hardware and the plugin holds only credentials and URLs for them.

Local, and yours to fix. Slow filter searches from missing wp_postmeta indexes. Listing pages that keep missing the cache. Imports that die on max_execution_time or memory_limit. Syncs that never fire because WP-Cron is waiting for a visitor. Stale prices after a sync because the purge rule never ran. Every one of those is a setting.

Remote, and not the plugin’s to fix. A throttled or slow RESO API that stretches an import until it times out. A board that rate-limits your requests. An image server outage. Fields the board does not publish in its feed. The plugin retries on the next run; it cannot make a remote server answer faster.

What native import does soften. Because listings were imported into your database, an MLS API outage does not take your site down: price, address, beds and baths keep rendering from your own tables while the feed is unreachable, and the next sync catches up. Photos are the visible exception, covered in the photo section below.

Get started today: open the MLSImport sync log after tonight’s run. It separates a host timeout from an MLS API rate-limit response, so read it before you call your host.

Database scale: what WordPress actually stores for 10,000 listings

Yes, your database grows when you import listings, but predictably, and two moves keep it from becoming a problem. You won’t need a database admin to pull it off.

Every listing becomes one row in wp_posts plus several rows in wp_postmeta, one per field. At 10,000 listings, that’s 200,000-plus rows across those two tables. WordPress handles millions of rows fine, as long as you index correctly.

Here’s where sites get into trouble. Without indexing, meta queries against wp_postmeta start getting heavy past 5,000 to 10,000 records. A filter-by-price search across 20,000 listings forces MySQL into a full-table scan, reading every row to find matches, like reading every page of a phone book to find one name.

Keeping the tables to the listings you show is the other move. When you turn on the daily check, MLSImport removes listings that left the MLS or moved to a status you did not choose to keep. It deletes nothing if the MLS sends back less than 80 percent of what your site holds, so a broken feed cannot wipe the site. See how daily reconciliation works.

The four meta indexes that prevent query crawls

Add custom MySQL indexes on the four meta keys you query most: price, city, status, and MLS ID. With those in place, MySQL seeks the matching rows instead of reading the whole table. These indexes matter most on WpResidence, Houzez, Real Homes and WpEstate, where the theme runs the search against post meta.

Get started today: in phpMyAdmin, confirm whether price, city, status, and MLS ID each have an index on your wp_postmeta table. If not, add them before your next import.

Will searching thousands of listings by price or beds be slow in Standalone mode?

In Standalone mode, the search does not dig through post meta. MLSImport keeps its own search table, with one row per listing, written each time a listing comes in or changes. The row holds price, beds, baths, living area, lot size, year built, map location, city, state, ZIP, status, type, and the text used for keyword search, so a price range search over thousands of listings reads one table built for search. If property pages work but search finds nothing, the table is out of step with the posts; a developer can rebuild it with wp mlsimport reindex. See Rebuilding the search index with WP-CLI and Standalone mode on any theme.

Hosting requirements at 5,000, 10,000, and 50,000 listings

Your hosting tier is the biggest variable you control. Shared hosting often works for a few hundred listings. For thousands, the limits shared plans enforce are exactly the ones the import needs raised, so plan on a VPS or a managed WordPress plan sized for the feed. See hosting requirements and recommendations.

One trap up front: managed hosts often cap how long one PHP process may run at 60 to 120 seconds. One import task runs as one long background job, so that cap applies to the whole task, not to each batch of 25 listings. Split a big feed into smaller import tasks (by city, property type or status) that each finish inside the limit.

What hosting has MLSImport actually run, and with how many listings?

Two managed hosts have carried large imports in our own tests, both recorded on video: Kinsta with about 6,000 listings on a single site plan, and Cloudways with about 8,000 listings. These are not a promise for every feed: your theme, your filters and your host’s limits all play a part. They show that thousands of listings is a normal size, not an edge case.

PHP settings every MLSImport installation needs

Verify these before you start an import, not after a timeout. They are the values we test against:

• memory_limit: 512 MB, and 1 GB for very large feeds like NTREIS.
• max_execution_time: 600 seconds at least, or 0 for no limit. This decides whether a large import task finishes, and the plugin shows a warning in wp-admin for any positive value under 600. Ask your host: “What is the longest a PHP process can run on this plan, and can you raise it?”
• max_input_vars: 10,000, so long filter lists (like many cities on one import task) save without silently dropping values.
• PHP version: run PHP 8.3 or newer. WordPress’s own minimum is 7.4, but 7.4 is end-of-life and no longer receives security patches. Moving off PHP 7.x onto 8.x is one of the biggest free speed wins available.
• OPcache: enabled.
• Storage: SSD running MySQL or MariaDB.

Hosting tier decision table

Find your active listing count and plan the next upgrade from there. Read the counts as planning guidance, not measured breakpoints.

Caching, CDN, and object cache for large MLS sites

Caching turns a database-heavy MLS site into something that feels nearly instant. Without it, every listing page hits MySQL on every request.

Three layers work together on a large site. Full-page caching (WP Rocket, LiteSpeed Cache, Varnish, or Nginx FastCGI cache) turns listing pages into static HTML served from memory. Object caching (Redis or Memcached) stores query results in RAM. A CDN like Cloudflare serves static assets from edge nodes near the visitor.

MLSImport ships no cache engine of its own; it leans on your host and caching plugins. The detail that separates a production setup from a naive one is cache purge on sync. When MLSImport updates a listing’s price or marks it pending, the cache for that page must invalidate so visitors see the fresh number.

Which caching plugins work with MLSImport?

These four full-page caching plugins are confirmed compatible:

• WP Rocket
• W3 Total Cache
• LiteSpeed Cache
• SiteGround Optimizer

One caveat: aggressive JS minification and combining can conflict with interactive map features, so test your map after enabling them. Wordfence and Sucuri are fine alongside MLSImport, as long as you allowlist the MLS/RESO API endpoint in your firewall rules so the firewall doesn’t block your sync.

Get started today: install WP Rocket or LiteSpeed Cache, clear the cache, then load your slowest listing page twice. The second load is the cached speed visitors actually feel.

Why search pages are slower than listing pages

Search results usually skip the page cache. A page cache saves a finished copy of a page and hands it to the next visitor, but every mix of filters (city, price, beds) makes a new web address, so most searches have no saved copy and the database answers from scratch. That is why search can be slow while your listing pages are fast.

• Add an object cache such as Redis, so the same search does not hit the database again.
• Keep the search form short. Each extra filter is extra work for the database. Load fewer homes per page and paginate.
• Keep bots out of endless filter addresses. Crawlers that click every filter mix can load a server all day. Block the search results address in robots.txt or mark it noindex, and let Google reach your listing and area pages instead.
• Cluster map pins. A map with hundreds of pins is heavy for a phone. Group nearby pins (MLSImport does this on its own maps, see how pin clustering works), load the map only on pages that need it, and show the list first on phones.

Where do listing photos actually live?

MLSImport does not copy listing photos into your WordPress media library, even with tens of thousands of photos. Each photo stays on your MLS photo server, and your site saves only its web address. Some other plugins download every photo, and WordPress can make up to six extra sizes of each one, so one photo turns into seven files. Ask any IDX vendor which way they do it before you buy.

A typical listing carries 20 to 40 photos, and luxury listings push 60 to 100.

With remote addresses, backups stay small and a migration that would take hours takes minutes. You don’t lose image SEO either: alt text, captions, and schema are built from the listing fields in the HTML markup.

For galleries, do not lazy load the main photo, because it is usually the largest thing on the page (Google’s LCP item). Lazy load the rest with loading=”lazy”, and show the first 8 to 12 photos at first, loading the rest on scroll or click.

The trade-offs of photos staying on the MLS server

• Photo speed depends on the MLS server. If the MLS photo server is slow or down, galleries show empty boxes until it is back, while price, address, beds and baths still show from your database. The photos return on their own.
• Some share previews show no picture. Facebook and other apps sometimes cannot fetch a photo from the MLS server. See Facebook shows the wrong image or no image.
• No watermarking of MLS photos. Compress and watermark plugins work on files in your media library, and these photos are not there.

There is no setting that copies photos to your server. If you want one photo on your own site, for a watermark, a Facebook preview, or a luxury listing whose main photo must always show, upload it to your media library and set it as the property’s featured image by hand. The gallery stays on the MLS server. A featured image set by hand goes back to the MLS photo when that listing’s photos change in your MLS, so reapply it on the listings you market.

Get started today: right-click any photo on one of your listing pages and open it in a new tab. The address points at your MLS photo server, not at your own domain. Then open one image-heavy listing on your phone over cellular and watch the gallery load.

Sync strategy and slow-server timeouts

The schedule is hourly, and hourly is the whole of it. There is no setting that makes the sync run more often, because your feed does not update faster for being polled harder. Each run asks the RESO Web API for the listings changed since the last check, which the plugin stores, then adds and updates only those, never the whole board, so each run stays short.

Auto update is switched on per import task, so the thing you control is how many tasks sit on that hourly schedule, not how often it fires. A task with the switch off imports once and is never updated again. The hourly update checks every task marked for auto update in one run, so a host may finish one import task but stop the larger update job; test that run too. See memory and large imports.

The sync schedule (hourly, fixed) is not the same as the system-cron tick (how often the server pokes wp-cron.php). Use a real server cron that hits wp-cron.php every 5 to 15 minutes, because visit-triggered WP-Cron misses runs on quiet and very large sites alike. Most managed hosts have a cron panel in their dashboard.

Some regional MLS systems run slow or throttled APIs, the most common cause of timeout pain. Two fixes, in order: take some tasks off auto update, so a weak feed is not answering several queries in the same run, and check the sync log to tell a host timeout from an MLS API rate-limit response. Runs do not pile up on each other, because an hourly run exits immediately if the previous one is still going. On a modest host the first import can run for hours, but it’s a one-time cost.

Get started today: check the MLSImport sync log tomorrow morning to confirm your overnight price and status changes came through cleanly.

Should you filter your MLS feed or import everything?

No, you don’t have to import your entire MLS. Filtering to your target markets is one of the highest-return moves you can make, for speed and relevance both. Importing your whole board when you serve three cities is waste, and it adds thousands of pages that copy every other site on your MLS; see what Google does with duplicate listing pages.

There is no cap on how many listings your whole site can hold, but one import task brings in at most 10,000 listings. A bigger market is split across several import tasks, for example one per county, with filters that do not overlap. A metro board like NTREIS might hold 150,000 records when your site needs about 20,000. MLSImport scopes by city, county, price range, property type, status, agent ID, and office or agency ID. See How many listings can you import.

The payoff: scoped imports can cut post counts by 30 to 60 percent, shrinking the database, speeding every meta query, and dropping you a full hosting tier. Many solid sites land in the 3,000 to 8,000 active-listing range; an agent farming one neighborhood may need only 1,000 to 3,000. With more than one board, filter each one the same way.

Benchmarking IDX plugin site speed and hitting Core Web Vitals targets

Benchmark before you adjust anything, and benchmark your own build: your host, your theme, your listing count. A listing page loads one listing whether your site has 500 or 20,000, so a large import does not by itself set your scores. How each page is built and served does.

We publish no latency or throughput figures for MLSImport, because we have no load test with reproducible conditions to publish beside them. The targets worth holding are the ones Google publishes, each measured at the 75th percentile of page loads:

Measure with PageSpeed Insights for Google field data, GTmetrix and WebPageTest for waterfall analysis, and k6 or Locust to load-test under simulated traffic. Test a staging copy with your real feed, theme, search forms and filters before you launch or change hosting:

1. Time the search, map and property pages before the import.
2. Start with a 25-listing import task and check that it finishes, then add your full market in tasks your host can finish.
3. Repeat the page tests while an import runs and after it ends.
4. Try a search you have not opened before. A saved page can load fast while a new search stays slow.
5. Check that the hourly updates finish and that listings which leave the feed come off your site.

Keep the listing count, host plan, theme and results together, and re-test after major plugin or theme changes, hosting migrations, or every one to three months. If your numbers miss target, fix them in order: caching first, hosting tier second, meta-key indexes third. The plugin comes last, because it’s almost never the plugin.

Get started today: test two pages in PageSpeed Insights on mobile: a listing page and a search results page with three filters picked. The listing page shows your caching; the search page shows your hosting and your database.

Why did the site get slow after we added a property search?

A property search adds three things a plain site never had: listing data, dozens of photos per page, and extra scripts like maps. One of those is slowing the site, and you can find which in about 30 minutes. Run these checks in order and stop at the first problem:

1. Compare pages. Test a plain page, the search page and one listing page on a phone. If every page slowed, look for map or search scripts loaded across the whole site. If only search pages are slow, see the search section above. If only listing pages are slow, check photo size and when images load.
2. Check if the search is framed. Right-click a listing, choose View Page Source and search for the street address. If it is not there, the listings load from another company’s server and your page cache can’t help.
3. Look at the wait before the page starts. In your browser’s Network tab, the time to first byte (TTFB) is how long your server takes to answer. A long wait means the server or the database. A fast answer but slow drawing points to the theme, the map or the photos.
4. Find slow database searches. Install Query Monitor, a free WordPress plugin, and run a price or city search with a few filters on. If one query takes most of the time, add the meta indexes above.
5. Open your host’s CPU graph. Spikes at the same time each hour point to the import or update job. Move it to a real server cron.
6. Turn the search plugin off on a staging copy. If the copy gets fast again, you have confirmed the cause.

Real estate themes load a lot by default: maps, sliders, a page builder, calculators and chat widgets. Turn off the features the site does not use and remove plugins nobody needs. Change one thing at a time, so you know which fix worked. Sites built on the same theme and host usually share the cause, so one fix often carries over.

What 20,000 DFW listings look like in practice

NTREIS, the MLS covering the Dallas and Fort Worth metro, holds 20,000 to 30,000 active listings at any given time. It’s one of the country’s largest boards and a real stress test of this guide. At that scale the database reaches hundreds of megabytes, and a VPS is the requirement, not a suggestion.

At full NTREIS scope, indexing, Redis, full-page caching, and Cloudflare are what make it viable, and staging is where you find out whether your theme agrees.

But most DFW agents don’t need all 20,000 to 30,000 listings. Filter to your county or price corridor first. A few target suburbs instead of the whole board leaves a load an entry VPS handles fine.

Frequently Asked Questions

Does changing hosting providers require new MLS approval?

No, as long as your domain stays the same. MLSImport uses token-based RESO credentials rather than IP whitelisting, so moving to a new host needs no fresh MLS approval. You can start on a smaller plan and move up as your listing count grows.

Will overlapping import filters create duplicate listings?

No. MLSImport uses the MLS ID as a stable de-dupe key, so a listing lives on your site once even when two import tasks match it. The first task that brings it in decides which agent it belongs to.

Will an MLSImport update slow my site or break it?

Usually not. An update swaps the plugin’s code and does not touch your MLS login, your import tasks or your listings. When a site breaks after an update, the usual causes are old PHP, a theme or page builder clash, or a copied template. Update on a staging copy first and keep a backup. See Will an MLSImport update break my site?

Can I test my full feed during the free trial?

Yes. The 30-day trial has no trial listing cap, so load your real market on a staging copy and run the tests in the benchmarking section before launch. Your host’s limits still apply. See the free trial and what limits actually exist.