Real estate website speed in Sacramento is mostly slow on a phone. We loaded 43 brokerage websites the way a typical mid-range phone on a slow 4G connection would, three times each, on September 27, 2026. The median site took 7.6 seconds to show its main content. Google counts 2.5 seconds or less as good. Two of the 40 we could test cleared that line, and 14 took longer than ten seconds.
The short version:
Brokerage sites tested (3 more could not be tested)
Median time to show the main content
Showed it within Google's 2.5 seconds
Took longer than 10 seconds
Median page weight
Loaded a video file
Median time for those 10
Our own homepage
| What we measured | Result |
|---|---|
| Brokerage sites tested (3 more could not be tested) | 40 |
| Median time to show the main content | 7.6 seconds |
| Showed it within Google's 2.5 seconds | 2 |
| Took longer than 10 seconds | 14 |
| Median page weight | 2.2 MB |
| Loaded a video file | 10 |
| Median time for those 10 | 11.8 seconds |
| Our own homepage | 2.76 seconds |
We build websites for brokerages and our own homepage is in the test, so read this with that in mind. Everything here is measured, the method is at the end, and the firms that did well are named. The rest are not, because the pattern is the point.
Why a phone is the test that matters
Most of the people who will judge your website are holding a phone. In the National Association of Realtors' 2025 Profile of Home Buyers and Sellers, 70% of buyers "relied on mobile or tablet devices in their search", and 46% said their first step was looking online for properties for sale. A seller who hears your name from a friend does the same thing: they look you up, on whatever is in their hand.
Google's position is measured. Its page experience guidance says its "core ranking systems look to reward content that provides a good page experience," and also that good scores do not guarantee top rankings. Its developer site sets the targets we used: main content in 2.5 seconds or less, and the first thing on screen in 1.8 seconds or less.
You have probably also seen the statistic that 53% of mobile visitors leave a page that takes longer than three seconds. We traced it. It comes from a September 2016 post on Google's advertising blog, based on "a sample of mWeb sites opted into sharing benchmark data, n=3.7K," from March 2016, and Google never said what counted as leaving. Google still repeats it today without the footnote. We do not lean on it. The two numbers above are enough.
Video is the single biggest cause
Ten of the 40 sites load a video file, most of them a looping background on the homepage. Those ten have a median page weight of about 22 MB and take a median 11.8 seconds to show their main content. The other thirty have a median of 1.4 MB and 6.9 seconds.
The individual files are the story. One commercial firm's homepage banner video is about 50 MB. Two more are about 36 MB each, and others run 23, 22, 18 and 17 MB. One residential homepage downloads 87 MB in total, more than thirty times the median home page on the web. HTTP Archive's 2025 Web Almanac puts that median at 2.56 MB on mobile.
A video that plays behind a headline looks good on a desktop in the office. On a phone it is a large download for something the visitor did not ask for, and a still image with a play button does the same job.
Big images, and pages that wait
The rest of the slow sites fail in three ordinary ways.
- Oversized images. Two homepages each lead with a single image of 6 to 7 MB, several times the weight of an entire fast website. A phone screen needs a fraction of that.
- Fonts that hold the page. Thirteen of the 40 load their fonts from Google's font service in a way that stops the page from drawing anything until the font instructions arrive. On a slow connection the test estimates that alone costs two of the smallest sites in the sample about two seconds each: a 134 KB site and a 91 KB site, both light enough to be fast, both waiting on fonts.
- Script before content. One site is built as an app, and its code kept the phone busy and unable to respond for about 2.4 seconds in total. Across the sample, 30 of 40 sites had at least one file that blocks the page from drawing until it finishes.
Weight alone does not decide it. A 52 MB site showed its main content in 6.3 seconds, while a 2.5 MB site took 16.6. What matters is what the page makes the visitor wait for before the main content appears, not only the total.
Even with the video sites set aside, the median is 6.9 seconds. Video makes a slow site slower. It is not the only reason sites are slow.
The two that pass
Broker100, Sacramento. The fastest site in the sample by a distance: main content in 0.9 seconds, the whole page 248 KB. One image, almost no code, and nothing that makes the page wait. It is not elaborate, and that is the lesson.
The second, at 1.7 seconds, is a site made with a website builder. Three more came close, between 2.8 and 3.1 seconds, and by the test's own estimate two of those three would pass with nothing more than a change to how they load their fonts.
Our own homepage
We ran www.flarebuilt.com through the same test as a control. It showed its first content in 1.2 seconds and its main content in 2.76 seconds, a quarter of a second past Google's line, at 593 KB, about a quarter of the sample median.
In a real browser the main content appears at the same moment as the first paint. The test's phone simulation adds the cost of the script behind the homepage's interactive parts, and on a slow phone that script pushes the main content over the line. It is the same failure we describe above, in a smaller dose, and we are cutting it.
A five-minute real estate website speed check
- Run your homepage through PageSpeed Insights and read the mobile result. The number labelled Largest Contentful Paint is the one in this article: when the main content appears.
- Look for a video on your homepage. If there is one, check its size. Anything over a few megabytes on a phone is a cost you are choosing.
- Check your largest image. A hero photo over 500 KB is almost always larger than a phone needs.
- Open your site on your own phone, on cellular data, not Wi-Fi, and count how long it is before you could read the page or tap a button.
What we would build
This is the part we sell, so read it as a specification you can hold anyone to, including us.
A homepage that shows its main content inside Google's 2.5 seconds on a mid-range phone, which means no autoplay video on phones (a still image with a play button instead), photographs sized for the screen they land on, fonts that never hold the page, and as little script as the page genuinely needs. Then the rest of the checks from our Sacramento brokerage website audit, from the licence number to a phone number you can tap.
A launch site starts at $900 and is live in 48 hours, and a full brokerage site starts at $4,500 and is live in about a week, with Flare Care for the months after. What a new firm actually needs is worked through in what a brokerage website costs.
If you want this test run on your site, tell us about your brokerage, or build your package in about two minutes.
How we tested
The sample is every live website from our two earlier Sacramento-area audits: the brokerage corporations licensed in Sacramento County since 2024 (residential), and the Sacramento-region corporations with Commercial or CRE in their licensed name (commercial). Three firms were in both, which leaves 43 sites, plus our own as a labelled control.
Each homepage was loaded three times on September 27, 2026 with the open-source test engine behind Google's PageSpeed Insights, version 13.5, at its default phone settings: a simulated mid-range phone with a four-times-slower processor on a slow 4G connection. We report the median of the three runs. Every run identified itself as an ordinary Android phone browser, because testing tools that announce themselves get turned away by some sites' bot protection, and a blocked test looks like a slow site.
Three sites could not be tested, and they are not counted as slow. Two refused our automated browser on all three runs while loading normally for an ordinary request, and one has a broken security certificate that every browser rejects. One site produced a single valid run of three, and two produced two, because of errors in the test engine; we used what completed.
This is a laboratory test on one simulated device and connection, not a measurement of real visitors, and times vary by hour and by network. What it does show, reliably, is which sites make a phone wait, and for what.