Why your real estate website is invisible to Google: how heavy IDX and bloated templates wreck your Core Web Vitals
You can publish every week and still not rank. What Core Web Vitals actually measure, why real estate templates fail them so reliably, and what fixes it.
You can publish a post every week, hire a genuinely good photographer, and get written up locally, and still watch your site sit on the third page of results. When that happens the problem is usually not the content. It is that the site is slow enough that Google has stopped treating it as a good result to send someone to.
Core Web Vitals are the three measurements Google uses to put a number on that. They are not a style opinion. They are timings, taken from real visits by real people on real connections, and they are unusually harsh on how real estate websites are typically assembled.
Why this industry fails them so consistently
The standard agent site is a template carrying an autoplaying video header, photographs uploaded straight off a camera, a third party search widget in an iframe, and a stack of tracking and popup scripts. Every one of those is a defensible decision on its own. Together they are the exact recipe these three metrics are designed to catch.
| Metric | What it measures | What breaks it on an agent site |
|---|---|---|
| LCP | How long until the biggest thing on screen has actually painted | A 15 MB photo dropped into the homepage slider at full camera resolution |
| INP | How quickly the page reacts when someone taps a filter or a menu | Heavy map and popup scripts occupying the main thread when the tap lands |
| CLS | Whether content jumps around while the page is still loading | An IDX iframe that arrives late and shoves everything below it down the page |
The three, and what actually fixes them
1. Largest Contentful Paint, the wait before anything
LCP is the clock running from the click to the moment the main image or headline is genuinely on screen. On an agent site that element is almost always the hero image, which means the hero image is the whole score.
The fix is unglamorous: serve it in a modern format at a sensible resolution, from a CDN close to the visitor, and tell the browser it is the priority so it fetches it first instead of lazily. A hero that is deferred by the same lazy-loading that helps everywhere else is one of the most common own goals we find.
2. Interaction to Next Paint, the lag after the tap
INP measures the gap between someone tapping a filter and the screen actually changing. It replaced the older first-input measurement because it looks at every interaction in the visit rather than only the first, which is a much fairer picture of what using the site feels like.
It goes wrong when too much JavaScript is competing for a single thread. Two mapping libraries, a chat widget, an exit popup, and an analytics bundle will make a fast connection feel broken, because the phone is busy at the exact moment the visitor asks it to do something.
3. Cumulative Layout Shift, the page that moves
CLS is the one everybody has experienced and nobody has a name for: you go to tap something, the page shifts, and you tap the wrong thing. On agent sites the usual culprit is an embedded search that loads late and pushes the page down when it arrives.
The fix is to reserve the space before the content arrives, so the layout is settled from the first paint and nothing has to move. Every image and every embed gets its dimensions declared up front.
Nobody bounces because your site failed a metric. They bounce because it felt slow, and the metric is just the part of that you can measure.
Speed is not only a ranking question
Ranking is the argument that gets attention, but it is the smaller half. A visitor who waits several seconds on a phone, on a cellular connection, standing outside a property, frequently just leaves, and you never learn they were there. That loss happens whether or not the page would eventually have ranked.
This is why we treat performance as part of the build rather than something to tune afterwards. A site assembled from heavy parts cannot be optimized into a fast one at the end; the weight is structural by then.
2.5s
The LCP threshold a good page stays under
200ms
The INP ceiling before a tap feels laggy
0.1
Maximum layout shift before it is noticeable
The IDX widget question
Almost every conversation about this ends at the same place: the search. An embedded third party search is usually the single heaviest thing on an agent site, and it is also the feature nobody is willing to remove, which is how sites end up stuck.
The way out is not to drop the search. It is to stop treating it as a foreign object dropped into the page. A search built as part of the site loads with the site, reserves its own space, and shares the same code rather than hauling in a second framework behind an iframe. Same feature for the visitor, an entirely different weight.
How to find out where you stand
Run your homepage and one property page through PageSpeed Insights and read the field data rather than the lab score, because field data is what actual visitors experienced. If the hero is slow, the taps lag, or the layout shifts, you now know which of the three you are dealing with, and each one has a different fix.
Test on a phone on cellular, not on your laptop on office wifi. The gap between those two experiences is where most of this problem lives, and it is the one your buyers are actually having.
