Speed guide · November 2026

Why Next.js stores are slow on phones

Short answer: mostly they aren't slow to load, they're slow to answer a tap. We looked at 24 big US stores whose pages are built with Next.js. In Google's numbers for their real phone shoppers, 11 pass all three of Google's speed checks and 13 fail. 11 of the 13 that fail answer taps too slowly, while 19 of the 24 show their main content in time. The usual cause is how much JavaScript runs when someone taps: the store's own React code plus dozens of outside scripts.

What we measured

The whole site of 24 big US stores that use Next.js, from Google's Chrome UX Report: real phone visitors in September 2026 (3 in 4 visits get this or better). The last column is our own lab test of the home page: one load with Google's Lighthouse on a simulated mid-range phone with slow 4G, in November 2026. That is much slower than most shoppers' phones, so it only explains causes; the real-shopper numbers decide pass or fail.

Good marks: main content 2.5 s, taps 200 ms, page jumps 0.1. "Our lab test": when the main content shows in our test on a mid-range phone on slow 4G. For every store we track, see how big US store sites do for real phone shoppers.

Next.js isn't the problem by itself

The Next.js stores do a little better than the other big stores we track: 11 of 24 pass (46%), against 29 of 91 (32%) of the rest, and 11 of 24 fail on taps against 49 of 91. Across the whole web, taps are good on 71.6% of Next.js sites (p75 213 ms, 5,045 sites), close to plain React (71.9%) and behind Nuxt (84.2%) and jQuery (94.5%) (State of Web Vitals, November 2026, phones). Big stores fail more often than the web as a whole; the likely reason is how much code and how many outside scripts each of their pages carries, not the framework.

Why taps get slow

1. The store's own code re-draws too much on a tap. On Chico's, the slowest here (real shoppers' taps take 425 ms), one menu tap took 512 ms in our test on a mid-range phone, and 247 ms of it was the site's own Next.js code reacting to the tap. Outside scripts each added a little (one bot-check-style script 58 ms). Early taps are worse: while the page is still "hydrating" (React wiring up the server-made page), a tap waits.
   Check first: record one tap on your slowest page in Chrome DevTools (Performance panel, with the processor slowed 4x) and see whose code runs between the tap and the next frame.
2. Dozens of outside scripts, loaded by more than one tag manager. In our tests Chico's home page loaded scripts from 78 outside companies through two tag managers (Google's and Adobe's). Testing and personalization tools and session replay hurt taps most in web-wide data; chat widgets hurt little. Each one adds work to every tap.
   Check first: Lighthouse's "Reduce the impact of third-party code" list for your home page and a product page, and whether every tag in each tag manager is still used.
3. Page jumps. 7 of 24 stores also fail on page jumps (Target, J.Jill and Michaels jump the most). Banners, promo bars and product tiles that arrive late push the page around while people try to tap.
   Check first: reserve space for banners and anything loaded after the page; Lighthouse lists the elements that moved.

The five slowest to answer a tap: Chico's, Michaels, Belk, J.Jill and Under Armour (425 ms, 400 ms, 375 ms, 375 ms, 350 ms). 24 stores is a small sample: these are patterns we saw, not proof that one change fixes a store.

Why it matters

Shopify's 2026 study of its stores found conversion about 1.5% lower for every 32 ms slower response to taps (Shopify, "Store speed and conversion: what the data shows", April 2026). In Deloitte's 2020 study for Google (37 brands, 30 million phone sessions), when four speed measures, including how fast the page answers a tap, each improved by 0.1 s, retail sites' conversion rate was 8.4% higher (Deloitte, "Milliseconds Make Millions", 2020). Both are averages across many stores, not a forecast for yours. Google also uses real visitors' speed as a search ranking signal.

Your store