Seventy percent of home buyers used a mobile device or tablet during their search, according to NAR's 2025 Profile of Home Buyers and Sellers. That single number is why website speed stopped being a technical footnote for real estate agents and became a business one.
The three numbers Google actually measures
Most conversations about website speed are vague, which is why they go nowhere. Google is not vague. It publishes three specific metrics, collectively called Core Web Vitals, and a good result on all three is the bar.
Largest Contentful Paint measures how long until the biggest visible thing on screen has finished loading, usually your hero photo. Good is under 2.5 seconds.
Interaction to Next Paint measures how long the page takes to visibly respond when someone taps or clicks. Good is under 200 milliseconds.
Cumulative Layout Shift measures how much the page jumps around while it loads. Good is under 0.1.
One detail matters more than the thresholds themselves. Google assesses these at the 75th percentile of real visitor data, which means the slower quarter of your actual traffic counts. The test you run on your laptop on office wifi is the best case your site will ever see. The person standing outside a listing on a weak cellular signal is the case Google is scoring.
Agent websites are slow for two different reasons
Almost every slow real estate site fails for one of two reasons, and they need opposite fixes. Running the wrong fix wastes a month.
The first cause is photography. This business runs on images, and a listing gallery or neighbourhood page loaded with files straight off a camera can weigh more than everything else on the page combined. Nothing warns you, because the site builder accepts a five megabyte photo without complaint and it looks fine on the desk where you uploaded it.
The second cause is scripts. A chat widget, a second analytics tool someone added during a campaign, a heatmap recorder from a consultant who is no longer working with you, a retargeting pixel, an IDX embed, and a review carousel. Each one arrived for a sensible reason. None of them were ever removed, because removing things requires someone to own the question.
You can tell which one you have in about a minute. If the page shows text quickly and then images fill in slowly, it is a photo problem. If the page sits blank for a beat and then everything arrives at once, or if it looks ready but does not respond when you tap, it is a script problem.
Fixing the photo problem
Resize before upload, not after. A full-width hero image needs to be about 1600 pixels wide. Anything larger is downloaded by every visitor and then thrown away by the browser. In-page images rarely need more than 1200.
Save photographs as WebP, a modern image format that produces a fraction the file size of an unprocessed JPEG at a quality most people cannot tell apart. Keep the original high-resolution files somewhere safe, because you will want them for print and for the next redesign.
Load images as the visitor scrolls rather than all at once. On a gallery, the first two or three images should load immediately and the rest should wait until someone scrolls toward them. Most of your visitors never reach photo 31, so there is no reason to make them pay for it.
Give every image a declared width and height. This is the single most common cause of a layout that jumps around while loading, because the browser does not know how much room to leave until the file arrives. That jump is what Cumulative Layout Shift is measuring, and it is also what makes a visitor tap the wrong thing. Our post on website photos when you have nothing to work with covers what images to use in the first place.
Fixing the script problem
Make a list of every third-party tool loading on your site. Most agents are surprised by the length of it, because the list has never existed in one place.
Then apply one test to each: has anyone opened a report from this in the last 90 days? Heatmap and session recording tools almost always fail that test. They were installed for one investigation and never uninstalled.
Consolidate analytics to one tool. Two analytics scripts do not give you two views of the truth, they give you two different numbers that nobody reconciles, at twice the loading cost.
Be honest about the chat widget. It earns its weight only if someone answers it quickly. If messages sit unread until the next morning, it is slowing your site and quietly teaching visitors that you do not respond, which is worse than not having it. Response time is the whole value of that tool.
Keep the IDX feed where people actually search. An embedded listing widget on your homepage, your bio page, and every neighbourhood page loads a heavy third-party tool for a lot of visitors who never touch it. On dedicated search and listing pages it earns its place. Whether IDX pays for itself at all is covered in our post on whether IDX brings clients.
What speed does and does not do for rankings
Speed is a tiebreaker. Google treats page experience as one signal among many, and a fast page with nothing to say still loses to a slower page that answers the question properly. Agents who spend a quarter chasing a perfect score and ignore what the pages actually say usually end up disappointed.
There is also no penalty in the sense agents mean. Nothing removes a slow site from results. What happens is quieter: when two pages are close on relevance, the better experience wins, and that is a lot of searches.
The visitor side is where the real money sits. A person who taps your listing link from a text message, waits four seconds on cellular data, and closes the tab did not see your phone number at all. No ranking factor is involved in that loss. Speed work pays for itself there first.
What to check first, in order
Start with your phone, on cellular data, away from your office. Load your homepage, one neighbourhood page, and one listing page. Count the seconds out loud. That is your real baseline and it usually tells you more than a score out of 100.
Then check the heaviest page you own, which is almost always a listing gallery or a neighbourhood page with a photo grid. Fix the images there first, because that is where the weight is concentrated.
Then audit the script list. Remove what nobody reads. Consolidate what duplicates.
Then recheck. If the numbers moved and the calls did not, speed was not your constraint, and that is worth knowing. A fast site that still produces nothing usually has a content or a conversion problem instead, which is the subject of our post on traffic without calls.
Why this drifts back
Speed is not a project that finishes. Every tool someone adds costs a little, every new listing gallery adds weight, and each addition is small enough that nobody objects. A year later the site is slow again and no single change caused it.
A quarterly check on your own phone catches that drift. Put it on the calendar next to your review requests and your profile updates. It takes ten minutes and it is the only version of this that survives contact with a busy season.
The takeaway
Website speed on a real estate site is usually a photo problem or a script problem, and the fastest way to waste a month is to fix the wrong one. Check on a phone on cellular data, find which pattern matches, and work on the heaviest page first. Google's thresholds give you a target, but the visitor who closes the tab before your contact details appear is the cost that actually shows up in your calendar.
