DEV Community

Scott Steinmetz
Scott Steinmetz

Posted on Originally published at scottsteinmetz.biz

Why a Client's Homepage Took 13 MB to Load on a Phone (and How I Cut It to Half a Megabyte)

A client of mine had a homepage that felt sluggish on phones. On a desktop with fast internet, it seemed fine. On a phone with one or two bars of signal, it crawled.

My client had a good reason for how the page was built. They carry products from five different suppliers, and they wanted customers to be able to browse all five suppliers' catalogs right on the homepage. So each catalog was embedded on the page, one after another.

The problem was that the phone did not wait to be asked. The moment someone opened the homepage, their phone started downloading all five catalogs at once, including the four they could not even see yet. Before a customer scrolled an inch, the page had pulled down 13.1 MB of data across 167 separate requests. Speed plugins and "lazy loading" settings did not fix it on their own, so I took a closer look.

How the System Works

  • Load What the Customer Can See: Each catalog now waits quietly until a customer scrolls near it, then loads just in time to be ready when it comes into view.
  • Nothing Removed: All five supplier catalogs are still on the homepage, exactly where my client wanted them. Customers who scroll still see every one.
  • A Safety Net: Anyone with an older browser, or with scripts turned off, still gets the catalogs the old way. Nobody is left with a blank page.

Overcoming the Friction

1. The Built-In Setting Only Fixed Two of Five

Modern browsers have a built-in "don't load this until it's needed" setting, and I tried that first. It only delayed two of the five catalogs. Phone browsers start loading things well before you scroll to them, and that head start was long enough to grab three catalogs on page load anyway. I replaced it with a small instruction that waits until the customer is actually close to each catalog.

2. The Fix Was Live, But Nobody Could See It

After the change, the homepage still looked slow from the outside. A speed service in front of the site had saved a copy of the old homepage and kept serving it. Clearing just that one page did not work. Only clearing everything at once finally pushed the new version out to visitors.

3. Being Honest About the Score

The "before scrolling" download dropped dramatically, but the speed score Google shows only moved a little. The slowest part of the page is now the welcome text at the top, waiting on its fonts. That is a separate, smaller fix for another day, and I would rather say so plainly than promise a perfect score.

The Business Win

  • About 96% Less Data Up Front: The homepage went from 13.1 MB to about 567 KB before a customer scrolls.
  • 75% Fewer Requests: From 167 separate downloads down to 42.
  • No Lost Content: Every supplier catalog is still there. Customers just do not pay for the ones they never scroll to.

If your homepage has embedded videos, maps, or catalogs from other companies, open it on your phone using cellular data and count how long it takes to settle. If it is more than a few seconds, embedded content is a likely suspect. The next step for this site is the welcome text and fonts, which is where the remaining load time lives.

Curious what this looks like for something you need built? See more of these side by side on the case studies page.

Top comments (0)