A mobile product page teardown, thumb by thumb

A teardown is not a checklist run from a desk. It is a phone in one hand, the page loaded the way a buyer loads it, and a record of what happens on every screen and at every tap. Done this way it takes about forty minutes per product and finds things no analytics report will show, because the report cannot tell you that the close button on the popup sits where a thumb cannot reach. This is the method we use, with the scoring sheet at the end.

Set up like a buyer

Use a real mid-range phone, not the browser’s device simulator and not the newest flagship. Put it on cellular or throttle the connection to a slow 4G profile. Clear the cache, so this is a first visit. Arrive the way most of your mobile traffic arrives: if that is a paid social click, open the link from inside the social app’s own browser, because in-app browsers behave differently from the phone’s default browser and that is where the buyer is.

Record the screen from the tap on the link to the cart drawer. Do three products: the bestseller, the product with the most variants, and the product with the lowest add-to-cart rate for its traffic.

Screen one: the load

Watch what appears and in what order. The questions to answer from the recording:

• How many seconds until the product image is visible and stable?
• Does anything jump after it appears, pushing the price or the button down?
• Is the price visible without scrolling?
• Is the product name cut off?
• How many things cover the page before the buyer can touch it: cookie banner, entry popup, announcement bar, chat bubble, app install banner?

Write down the seconds to a usable product view and the count of overlays. Those two numbers are the first row of the score sheet, and on most stores they are the worst row.

The thumb map

Hold the phone in one hand and notice what the thumb reaches without shifting grip. On a large phone the bottom third and the centre are easy, the top corners are not. Now map the page against that:

• Where is the add-to-cart button at load? If it is below the fold, what is between it and the fold?
• Where is the close control on each overlay? Top right is the hardest place on the screen.
• Can the gallery be swiped from the easy zone, or does it sit at the top where the thumb has to travel?
• Once the buyer scrolls past the button, does a sticky bar appear, and where?

A page can be fast and complete and still lose buyers because every decision requires a grip change.

Tap one: the gallery

Swipe through every image. Note whether swiping the gallery also scrolls the page, which is a gesture conflict that makes buyers give up on the second image. Tap an image: does a full-screen viewer open, does pinch zoom work, and when it closes does the page return to the same position or jump to the top? Count the images and time the load of the third one. A gallery that loads its first image quickly and its others slowly reads as broken to a buyer who swipes.

Tap two: variants

Count the taps from landing to a fully selected variant. Then check:

• Are the tap targets large enough? Swatches and size buttons should be at least the size of a fingertip, which most accessibility guidance puts around 44 CSS pixels.
• Does a dropdown open the phone’s native picker, which is fine, or a custom list that needs precise taps?
• Does the price change when the variant does?
• Do sold-out options read as sold out, or do they simply not respond?
• Does the size guide open as a sheet over the page, or navigate away?
• Tap add to cart with nothing selected. Where does the error appear, and can you see it from where your thumb is?

The variant picker is where interaction to next paint is decided on product pages. If a tap on a swatch visibly lags, the page fails the buyer at the exact moment of commitment.

Tap three: add to cart

Tap the button and watch the first hundred milliseconds. There should be immediate visual feedback, then the drawer or the cart. Once it opens: can you reach checkout in one more tap, can you get back to shopping, does scrolling inside the drawer also scroll the page behind it, and does the drawer’s checkout button sit in the thumb zone?

Screens two to five: the scroll

Scroll down slowly and count screen heights. Note what sits between the button and the reviews, which accordions are open by default, whether tabs hide content that should be visible, and whether any horizontal carousel captures the vertical scroll. Watch for widgets that load late and shift the content under your thumb. If reviews arrive after four or five screens, most buyers will never see them.

The keyboard

Any input on the page gets tested: the quantity field, a notify-me email box, the search bar in the header. Check that the numeric field brings up a number pad, the email field brings up a keyboard with the at sign, and that the keyboard does not cover the submit button. Small things, but each one is a moment where a buyer decides the store is hard work.

Interruptions, listed

Make a table of every overlay the page produced during the session: what it was, when it appeared, whether it could be dismissed with the thumb, and whether it came back. Entry popups, consent banners, chat prompts, spin-to-win wheels, app banners, back-in-stock prompts. Then ask what each one is for and whether it is earning its place. Exit-intent popups get their own discussion because the timing changes the answer.

Pair the recording with the numbers

The recording tells you what a buyer experiences; the data tells you how often. Alongside it, pull:

• Field Core Web Vitals for the product template from Search Console, or from the Core Web Vitals checker for a quick read.
• Add-to-cart rate on mobile against desktop for the same products.
• Variant selection errors as an event, if the theme fires one.
• Scroll depth on the template, to confirm where buyers stop.

Core Web Vitals thresholds are a fair benchmark: a product image within 2.5 seconds and interactions responding within 200 milliseconds are the levels the web.dev guidance treats as good, and a page that misses them on a real phone is telling you where the engineering work is. Failing vitals on product pages and a store that is slow on mobile are usually the same fix seen from two sides.

The scoring sheet

Check	Pass	Weight
Product image visible and stable within 2.5 seconds on a throttled connection		High
No overlay before the first interaction, or one that dismisses in the thumb zone		High
Add-to-cart reachable without a grip change at load, or a sticky bar after scroll		High
Variant targets at least fingertip size, with price and image updating on selection		High
Sold-out variants visibly disabled		Medium
Missing-variant error shown where the buyer is looking		Medium
Gallery swipe does not scroll the page; viewer returns to position		Medium
Cart drawer to checkout in one tap, back to shopping in one tap		Medium
Reviews within four screen heights		Medium
Tab and accordion content present in the HTML		Medium
Inputs bring up the right keyboard and the keyboard does not cover the submit control		Low
Interaction response within 200 milliseconds on variant selection		High

Score each product and add the weights of the failures. The product with the highest total is the template problem to fix first, because it is on every product.

Fixing in the right order

Overlays and button reach come first because they cost nothing to change. Load time comes second because it affects every screen that follows. The variant picker comes third, then content order. Most of what a teardown finds is a template change, which is why one afternoon with a phone tends to be the highest-return hour in mobile conversion work. The wider question of why mobile converts below desktop has structural answers, but the gap on a specific store is usually visible in the first recording.

---

Sources

• web.dev: Web Vitals
• web.dev: Interaction to Next Paint (INP)
• web.dev: Largest Contentful Paint (LCP)