Website Speed for Real Estate Sites: Core Web Vitals on Photo-Heavy Pages

The three Core Web Vitals

Core Web Vitals measure loading, responsiveness and visual stability, using data from real Chrome users. web.dev recommends assessing each at the 75th percentile of page loads, split by mobile and desktop.

How speed affects real estate search

Google's documentation on page experience says Core Web Vitals are used by its ranking systems and recommends achieving good scores, while also noting that relevance and helpful content matter most. In practice, speed rarely lifts a weak page to the top, but a slow page can hold back a strong one, especially on mobile where most property searches happen.

The bigger effect is on people. A slow listing page loses visitors before they see the photos, and a laggy inquiry form loses them at the moment they were ready to act.

Images: the biggest win

Photos are the heart of a property page and the main cause of slow ones. The fixes are well established:

• Serve each image at the size it displays, with responsive sizes for phones and desktops.
• Use modern formats such as WebP or AVIF, compressed for the web rather than print.
• Set width and height on every image so the layout doesn't jump as images load.
• Load the hero image immediately and with high priority; it is usually the LCP element.
• Lazy-load gallery images below the first screen using the browser's native loading attribute.
• Avoid huge carousels on the first screen; show one strong image and let people open the gallery.

Maps, tours and video

Interactive maps, 3D tours and embedded video players each load substantial scripts, even if the visitor never uses them. On a property page they can easily outweigh everything else.

Load them on request instead. Show a static map image with a button to open the interactive version, a tour thumbnail that loads the viewer when tapped, and a video poster frame that loads the player on play. web.dev's guidance on lazy-loading iframes describes the technique. Visitors who want the tour still get it; everyone else gets a fast page.

IDX, listing widgets and third-party scripts

Much of the weight on real estate sites comes from code you didn't write: IDX search widgets, property management listing embeds, chat tools, review widgets, analytics, ad pixels and call tracking. web.dev's guidance on third-party JavaScript recommends auditing each script, removing what isn't needed and loading the rest efficiently.

Make a list of every third-party script on your key templates and ask what each one produces. Remove duplicates and abandoned tools. Load chat and non-essential widgets after the page is interactive. Where a listing widget is slow, consider showing a lighter summary on the page and linking to the full search.

Responsiveness and INP

INP measures how quickly the page responds when someone taps a filter, opens a gallery or types in a form. Poor INP usually comes from heavy JavaScript running on the main thread, often from search widgets, sliders or tag managers.

The remedies are to ship less JavaScript, break up long tasks, and avoid running expensive work on every tap. Sites built mostly as static HTML with small, focused scripts tend to do well by default. Filters that re-render an entire listing grid on every change are a common culprit on property search pages.

Fonts and layout stability

Web fonts can delay text or cause it to jump when they load. Limit the number of font files, preload the one or two used above the fold, and use fallback fonts with matching metrics so text doesn't shift when the web font arrives.

Layout shift also comes from images without dimensions, banners inserted at the top of the page after load, and embeds that expand. Reserve space for anything that loads later, and place cookie or promotional banners so they don't push content down.

Measuring real users

Lab tools such as Lighthouse are useful for diagnosing problems, but they test one load on one device. Field data shows what real visitors experience. The Chrome UX Report (CrUX) provides field data for sites with enough traffic, and Search Console's Core Web Vitals report groups your URLs by status using that data. PageSpeed Insights shows both field and lab data for a single page.

1. 01

   Check Search Console

   Open the Core Web Vitals report and note which groups of URLs are poor or need improvement.

2. 02

   Test real templates

   Run PageSpeed Insights on a property page, a listing search page and a guide, not only the home page.

3. 03

   Find the LCP element

   Identify what the largest element is on each template, usually a hero image, and optimize it first.

4. 04

   Audit scripts

   List every third-party script and remove or defer what isn't essential.

5. 05

   Re-check field data

   Field data updates over about a month, so compare before and after on that timescale.

Set a speed budget for each template

A speed budget is a limit agreed before design starts: for example, a maximum total page weight, a maximum number of third-party scripts and a target LCP for each template on a mid-range phone. It turns speed from an afterthought into a design constraint, so decisions like adding another widget or a video background are made knowingly.

Real estate sites usually need separate budgets for a few templates: the home page, a property or community page, a listing search page and a guide. Property pages get the most generous image budget; everything else on them has to earn its place. Check each budget before launch and again whenever a new tool is added.

Common speed problems we fix

Across brokerage, management and commercial sites, the same handful of issues account for most slow pages.

• A hero slider loading five full-size photos before anything else appears.
• Original camera files uploaded straight to the CMS, several megabytes each.
• An interactive map loading on every page, including pages that never show it.
• Two or three analytics and advertising tags doing the same job, left from past vendors.
• A chat widget loading its full application on page load rather than when opened.
• Web fonts in many weights and styles, most of them unused.

Hosting and architecture

Where and how a site is served matters too. Static pages delivered from a global edge network start fast everywhere. Sites that build every page on a single server for every visit, with heavy plugins, tend to be slow before any image loads. When a site is being rebuilt, choosing an architecture that serves pre-built pages and adds interactivity only where needed avoids many speed problems from the start.

Speed is designed into every site we build, tested on real templates before launch. See real estate web design and our real estate website design guide.