We Tested 367 US Online Stores on a Phone. Here Is What Slows Them Down.

Most US online stores are slow on a phone, and the main reason is not the platform, the theme or the hosting. It is the pile of third-party apps and tags each store loads on its home page. On September 30, 2026 we ran Google's PageSpeed Insights phone test on the home pages of 367 US brands that sell direct to shoppers. The median store scored 34 out of 100 and took 11.7 seconds to show its main content on Google's simulated mid-range phone, where 2.5 seconds counts as good. Only 3 of the 367 made it. The median store also ran 20 third-party apps and tags, and the relationship was plain: stores with up to 10 scored a median of 49, stores with more than 30 scored a median of 28. The full numbers, the method and a CSV are in the study, US Store Speed 2026. This article is about what they mean for a store owner deciding what to do next.

The short version

• The lab is harsh, and real shoppers still feel it. Google's lab test simulates a mid-range phone on a slow mobile connection. Real Chrome shoppers see the median store's main content in about 2 seconds at the 75th percentile. Even so, only 46.2% of the 353 stores with real-user data pass all three Core Web Vitals.
• Responsiveness is the weakest vital. 63% of stores pass Interaction to Next Paint, fewer than pass loading (73.1%) or layout stability (79.3%). Shoppers tap, and the page answers late.
• The page is heavy. The median home page weighs 7.1 MB over 341 requests, with 2.6 MB of it JavaScript.
• Apps are the lever. Each band of extra apps costs points: median score 49, then 37, then 32, then 28 as the count climbs past 10, 20 and 30. Blocking time grows from under half a second to 2.4 seconds.
• Google flags the same few things everywhere. Too much main-thread work on 91.6% of stores, files that block the first paint on 90.2%, and scripts that keep the phone busy on 87.5%.

How we tested, in plain terms

We started from a list of 418 well-known US direct-to-consumer brands across twelve categories, from apparel and beauty to pet food and outdoor gear. It is a curated list, not a random sample of every store in the country, so read it as a picture of established brands that have teams and budgets, not of the average side project. We removed brands based outside the US, domains that now point somewhere else, sites that would not load for an automated test, and duplicates that land on the same store. That left 367.

Each home page was tested once with Google's PageSpeed Insights API on its mobile setting, run from a US server so every store served the version a US shopper sees. That detail mattered: our first pass ran from outside the US, and several stores answered with international versions, different currency scripts and all. We threw that pass away. Where Google has enough real traffic for a store, we also read the Chrome UX Report, which is 28 days of real Chrome visits.

Two limits are worth saying out loud. A lab score moves a few points between runs, so any single store's number is a snapshot. And a home page is not a product page or a checkout. The medians across 367 stores are what carry weight.

Why the lab and real shoppers disagree, and why both matter

The gap between 11.7 seconds in the lab and about 2 seconds for real shoppers surprises people, and it is the first thing a skeptical team member will raise. The lab test is deliberately pessimistic: a mid-range Android phone with its processor slowed down and a connection throttled to slow 4G. Plenty of real shoppers are on newer iPhones on Wi-Fi, and repeat visitors have much of the store cached already.

Both numbers are useful, for different reasons. The real-user number tells you whether Google's ranking systems see a problem, and for more than half of these stores they do. The lab number tells you how the store behaves for the shoppers you are not measuring well: the first visit from an ad, on an older phone, on a train. That shopper is exactly the one a paid campaign pays for, and the lab shows what they wait through.

For deciding what to fix, start from the lab number, because it is reproducible. You can change one thing, run the test again, and see the effect the same afternoon. Real-user data takes 28 days to move, which makes it the scoreboard, not the workbench.

The apps are the story

Every store in the study had a reason for each app it runs. Reviews sell. Email and SMS capture pays. Analytics and ad pixels feed the campaigns. Consent banners keep the lawyers calm. None of those decisions is wrong on its own. The problem is that nobody owns the total, and each app loads its own code on every page view whether that visitor will ever see what it does.

The most common ones in the study were Google Tag Manager (74.7% of stores), Google Ads (63.8%), Klaviyo (53.4%), Facebook (42%), Bing Ads (41.1%), TikTok (29.7%) and Pinterest (27.8%). Tag Manager deserves a special mention because it is usually a container for more tags, so its cost is really the cost of everything inside it. It was also among the heaviest by the time the phone spends running it, at a median of half a second.

The heaviest by main-thread time were not the famous names. An accessibility overlay, a fraud-screening script, a support widget and a consent manager each cost the phone between 0.5 and 1.3 seconds at the median. These are the tools nobody thinks of as marketing, so nobody questions them in a marketing review.

The pattern across the four bands is the clearest finding in the study:

Correlation is not proof, and stores with fewer apps may differ in other ways. But the direction is consistent across every band, and blocking time, the part apps are directly responsible for, rises with every step.

What Google flags most, and what it usually means

Google's report lists opportunities in its own vocabulary. Translated into what a store owner would recognize, the most common were:

1. Too much work on the main thread (91.6% of stores). The phone is busy running code and cannot respond to taps. This is mostly the apps above.
2. Files that block the first paint (90.2%). Stylesheets and scripts the browser must fetch before it draws anything. Often theme files and app stylesheets injected into the page head.
3. Scripts that keep the phone busy (87.5%). The same story as the first item, counted per script.
4. Scripts downloaded but never used (80.7%). Code for features that are not on this page, or apps that were uninstalled but left their snippet behind.
5. Files not cached for returning visitors (72.8%). Repeat shoppers download the same files again.

The median saving Google estimates for the top items is between one and one and a half seconds each on the lab phone. They overlap, so they do not simply add up, but three or four of them together are the difference between a red score and an orange one.

The order we would work in

If your store looks like the median store in this study, this is the order that has paid off for us, because each step is cheap to test and easy to undo.

1. List every app and tag, with an owner. One spreadsheet: name, what it does, who asked for it, and when it last earned its keep. Most teams find two or three that nobody can defend.
2. Load what you keep later. Chat, reviews below the fold, pop-ups and most pixels do not need to run before the page appears. Loading them on the first interaction, or a few seconds after load, keeps their data and removes their cost from the first impression.
3. Make the hero image the fastest thing on the page. On 86.1% of stores the main content Google times is an image, usually the hero banner. Serve it at the right size, in a modern format, discovered early, and never hidden behind an animation.
4. Stop blocking the first paint. Inline the little CSS the top of the page needs, and defer the rest.
5. Cache static files for returning shoppers. A configuration change, not a rebuild.

We ran this same order on our own site this morning, before publishing the study. It is not a store, but it had the same symptoms: a booking widget pulling about 3 MB on every visit, analytics loading before the first paint, and a hero image hidden behind an entrance animation. It scored 37 on Google's phone test at the start of the day and between 96 and 100 at the end, with nothing removed that a visitor would miss. We did not publish numbers about other people's stores while ours was slow.

Is it worth fixing?

Speed is worth money only where there is traffic and a conversion rate to improve, so the honest way to decide is with your own numbers. The research most often quoted, Deloitte's Milliseconds Make Millions study for Google, found retail conversions rose 8.4% for every tenth of a second saved across mobile sites. Your store will not match an average exactly, which is why the Store Speed Grader lets you put in your own monthly revenue and see what a proven gain would be worth.

What the study does settle is where most stores stand. If yours scores in the 30s, it is in the middle of the pack of established US brands, which is not a comfortable place to be when the pack is this slow. A store that gets to 60 is faster than about nine in ten of them.

Check your own store

The Store Speed Grader runs the same Google test used in this study, names the apps slowing your page, compares you with up to two competitors, and now tells you where your score sits among the 367 stores. The complete aggregates, the method and a CSV are in US Store Speed 2026, free to quote with a link.