Web design

August 2026 · 7 min read

Page speed for property websites: what actually makes them slow.

A tenant rep pulls into your center, reads the sign, and taps the code on it while sitting in the car on one bar of cellular. Everything you spent money on is now downstream of one question: does the page show up. Property websites are the heaviest sites in commercial real estate, because the media is the product. Here is where the weight hides, what the standards actually require, and how to check your own site before a prospect does it for you.

What "fast" means now, in numbers you can check

Google publishes a small set of thresholds called Core Web Vitals, and they are the only speed targets worth arguing about because they are the ones measured on real visits. There are three. Largest Contentful Paint, the moment the biggest thing on screen finishes rendering, should land at 2.5 seconds or less. Interaction to Next Paint, the delay between a tap and the screen responding, should be 200 milliseconds or less. Cumulative Layout Shift, the amount the page jumps around while loading, should be 0.1 or less. All three are judged at the 75th percentile of visits, meaning three out of four people have to get that experience, not the average person on your office wifi. The definitions and current thresholds live on web.dev under "Web Vitals," and they do change: Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024, per the Chrome team's announcement.

One distinction saves a lot of confused conversations. When you run a URL through Google's PageSpeed Insights, the top section is field data from the Chrome User Experience Report, aggregated from real Chrome users over the trailing 28 days. The bottom section is a Lighthouse lab test, a single simulated load on a throttled connection. A brand new listing site will not have field data for weeks, so early on you are reading a simulation. That is fine, as long as nobody mistakes the score out of 100 for a fact about your visitors.

Why property sites get heavy

Not through carelessness, usually. Through ambition. A good property site is a drone film, a photo gallery, an annotated aerial, a site plan, a map, sometimes a 3D tour, and a downloadable flyer. Each of those is a legitimate part of the pitch. Together, uncompressed, they are a 40 megabyte page that behaves beautifully on the desk it was built on and badly everywhere else.

The most common single mistake we see is the hero: a full 4K drone clip set to autoplay as the first thing on the page, with no poster frame. Until it decides to render, the visitor is looking at a dark rectangle. The second most common is the gallery: twelve photos exported at 6,000 pixels wide straight out of the camera, served at that size to a phone that will display them at 390. The third is accumulation, a chat widget here, a tag manager there, a tour embed, a font family with six weights, none of which felt like a decision at the time.

Where the weight actually is

• Images, sized for the screen they land on. Modern formats first: Google's own WebP compression study reports lossy WebP files 25 to 34 percent smaller than comparable JPEGs at equivalent quality, and AVIF generally does better still. Then serve multiple sizes with srcset so a phone gets a phone-sized file. Lazy-load everything below the fold, and do the opposite for the hero: load it eagerly and preload it, because it is almost always your Largest Contentful Paint element.
• Video that never blocks the page. A film should not be the first thing that has to finish loading. Use a poster image so there is something to look at instantly, keep any auto-playing loop short and muted, and put the full tour further down where someone chooses to play it. Compress for the web rather than uploading the export you sent to the client for review.
• Fonts, self-hosted and trimmed. Two weights, subset to the characters you use, served from your own domain with font-display set to swap so text is readable while the file arrives. Six weights loaded from a third party is a request chain nobody notices until they are on cellular.
• Third-party embeds, behind a click. Maps, 3D tours, and chat widgets each ship their own JavaScript, and they load whether or not the visitor ever uses them. The fix is a placeholder image that looks like the map or the tour and loads the real embed only when tapped. On most listing pages this is the change that buys back the most time for the least effort, and it costs nothing visually. We wrote about when a scan is worth the money at all in 3D tours and Matterport for commercial real estate.
• The flyer, which is part of the page experience. A 60 megabyte PDF is a slow site with extra steps. Flatten it, compress the images inside it, and host it at a stable link on the property site so it can be updated without re-sending anything.
• Whatever the platform adds by default. Builder-based sites carry a page builder's runtime, a slider plugin, an animation library, and a form plugin before your content weighs anything. That cost is structural rather than fixable, which is part of the case we made in CRE website templates: what they actually cost you.

A tenant rep on one bar of cellular does not wait for your drone film. They wait for a photograph of the storefront, and not for long.

How we build for it

Our approach is old-fashioned and deliberate: hand-written HTML and CSS, no page builder, no plugin stack, static hosting. There is no framework runtime to download because there is no framework, and nothing gets added to a property page that does not earn its bytes.

On the Marbella Plaza site, a 66,124 square foot grocery-anchored center with every suite, an interactive site plan, and a full trade-area section, that discipline is what keeps a content-rich page from behaving like one. The Marbella case study covers what went into it. On 5801 Lincoln, a 2,660 square foot corner suite taken from brief to live in three days, the media came entirely from raw drone footage: a short muted loop at the top of the page, with the longer property tour placed below where a visitor plays it on purpose. The seven-page flyer is flattened so it scrolls smoothly in a browser rather than stalling in a viewer.

We do not publish speed scores as a marketing claim, because a Lighthouse number depends on the network and device it was measured on and can be made to say almost anything. What we do is simpler and harder to fake: before a property site goes live, it gets opened on an actual phone, on cellular, with the cache cleared. If the hero photograph is not there by the time you have looked up from the sign, it is not finished.

What speed is actually worth in leasing

Be careful with the abandonment statistics that circulate in marketing decks. The most quoted one, that 53 percent of mobile site visits are abandoned when a page takes longer than three seconds to load, comes from a Google and SOASTA study published in 2016 and was measured on consumer retail sites. It is directional, not a benchmark for a tenant rep who is actively hunting for space and has far more reason to wait than a shopper does. Treat it as a reason to care, not a number to put in a proposal.

The search argument is similarly modest, and worth stating honestly. Google's own Search Central documentation on page experience describes it as one consideration among many and says relevant, quality content still wins over pages with better page experience. Speed is a tiebreaker between two comparable pages rather than a ranking strategy. Our guide to SEO for commercial real estate puts it in context.

The real case is more concrete than either. Every serious channel in a leasing campaign ends in a tap on a phone, frequently outdoors and rarely on good signal: the code on the sign panel, the link in the announcement email, the referral out of a portal. We covered the sign panel case specifically in leasing signs and QR codes that actually get scanned. Those visitors are your highest-intent audience of the entire campaign, and they arrive under the worst network conditions of the entire campaign. A slow page loses them quietly, and they never appear in any report as anything but a session that did not convert.

A ten-minute test you can run today

• Run PageSpeed Insights on your busiest property URL. Read the mobile tab, and read the field data section first if it exists. If it says there is not enough real-world data, that itself is worth knowing.
• Open the site on your own phone, on cellular, not office wifi. Force-quit the browser first so nothing is cached. Count seconds until the main photograph appears. That number is the honest one.
• Check the weight. In Chrome on a desktop, open DevTools, go to the Network tab, check "Disable cache," and reload. The total transferred at the bottom tells you what a phone has to pull down.
• Tap your own flyer link and watch the file size. Owners are often surprised by this one.
• Re-test a month after anyone adds a widget. Sites do not get slow in a day. They get slow one well-intentioned addition at a time.

Three questions for whoever builds it

If you are commissioning a property site, or looking at one you already own, the questions that produce useful answers are narrow. What will the hero weigh on a phone, and what loads before it. Which third-party scripts ship by default, and can they be deferred until a visitor asks for them. Who is responsible for the site still being fast in six months, and what gets measured to prove it. A vendor who answers those three specifically is thinking about the visitor in the parking lot. You can see how we scope this work in our services, and the case for a dedicated site in the first place in single-property websites.

Speed is not a feature you buy once. It is a constraint you accept at the start, and then keep accepting every time someone suggests adding one more thing to the page.