Performance·January 2026·9 min read

How AMP Pages Affect Mobile E-commerce Performance

AMP still renders fast, but it hasn't been a ranking shortcut since 2021, and Next.js is dropping the feature entirely in version 16. Keep it only where load speed is worth more than the scripting and UI it takes away.

AMP pages load fast. That part was never in question. The harder question is whether faster load times alone move conversion, and for most mobile storefronts they don't.

What conventional AMP adoption gets wrong

Speed-only thinking

AMP optimizes for page load speed, not usability, content richness, or checkout friction. Treating speed as the whole strategy leaves conversion gains on the table.

Split analytics

AMP pages often report through separate tracking paths, which fragments session data and makes funnel analysis harder than it needs to be.

Feature limits

AMP's stripped-down architecture restricts third-party scripts and complex UI. Simplifying too aggressively can cut the personalization and interactive features that actually drive purchases.

What AMP historically got right

Google introduced the AMP Project in 2015 as a response to a real problem: publisher pages loaded slowly, mobile ad tech made it worse, and readers bounced before content rendered. Restricting scripts and enforcing inline critical CSS was a blunt but effective fix at the time.

That trade made sense when most teams had no other lever for mobile speed. It makes less sense now that Core Web Vitals give teams a target to hit without giving up their own stack.

A shrinking SEO edge

AMP pages once got preferential placement in Google's Top Stories carousel. Google removed that requirement in 2021, opening Top Stories to any page that meets the same page-experience bar.

Google now indexes and ranks AMP pages the same as any other page. The old SEO argument for AMP no longer holds, and framework support is following the same trend: Next.js 15.5 deprecated its built-in AMP support, with full removal planned for Next.js 16.

Structured data doesn't depend on AMP

Rich results in Google Search depend on structured data markup, not on whether the page is built with AMP. Teams sometimes conflate the two because AMP pages were once a reliable path into the Top Stories carousel alongside that markup. Neither requirement needs AMP today.

A feature that trades scripting and UI flexibility for speed only earns its keep as long as the speed advantage is real and exclusive to it. Once Core Web Vitals close that gap, AMP is just a constraint.

Where AMP still earns its place

Real performance gains

AMP still delivers fast mobile rendering, and speed still correlates with lower bounce rates on slow connections. The gain isn't free SEO credit anymore. It's fewer people leaving before the page finishes loading.

Mobile page speed remains a ranking input through Core Web Vitals, independent of whether the page is built on AMP. The three metrics that matter today are Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP), which replaced First Input Delay as the responsiveness metric.

AMP's architecture makes LCP and CLS easier to hit by default, since it restricts render-blocking resources and requires explicit image dimensions. It has no special effect on INP, which depends on how heavy your JavaScript is at interaction time, not how the page loaded.

Measuring what AMP actually buys you

Don't take the speed claim on faith. Pull the Chrome DevTools Performance panel against both the AMP and canonical version of the same template, on the same throttled connection profile.

Open DevTools, set network throttling to "Slow 4G" and CPU throttling to a 4x slowdown, to approximate a real mid-range mobile device
Record a page load on the AMP version, then the canonical version, noting LCP and CLS from the Performance panel's summary
Check the Rendering tab's Layout Shift Regions overlay on each version to see exactly which elements cause shift
Cross-reference against field data in PageSpeed Insights, since lab data from DevTools won't match real-user Chrome UX Report numbers exactly

Lab data tells you what could go wrong. Field data tells you whether it did, for real users, on real networks.

The field data matters more than the lab run. A canonical page that scores worse in DevTools but performs fine in the Chrome UX Report doesn't need AMP to fix a problem real users aren't hitting.

Read that field data with its timing in mind. The Chrome UX Report is a 28-day rolling window, so a change shipped this week won't fully show up in PageSpeed Insights field data for roughly a month. Judge a fresh AMP-vs-canonical change on lab data first and confirm it with field data once the window catches up.

Balancing speed against UX

AMP restricts certain scripts and UI elements, so teams need to decide which features are load-bearing for conversion: product configurators, live chat, personalized recommendations. Those need an AMP-compatible version or a hybrid setup, not a cut.

Visual consistency between AMP and canonical pages matters too. A jarring difference in layout or branding adds friction for returning visitors.

Checkout is the clearest case for hybrid. AMP works well for browsing and content pages, but payment forms and security features are usually easier to build and maintain on the canonical page.

Measurement discipline

AMP pages need to report into the same analytics pipeline as everything else, or funnel data splits and conversion analysis gets unreliable fast.

Not every product page benefits equally from AMP. Test AMP against canonical variants by segment before rolling it out site-wide, and keep measuring load time, interaction delay, and conversion rate as the page evolves.

Segmenting the decision by page type

A single AMP-or-not decision for the whole storefront hides more than it reveals. Category and blog pages, product detail pages, and checkout have different UI needs and different traffic profiles.

Run the comparison separately for each template type instead of extrapolating from one. A category page result rarely predicts what happens on a product detail page with a configurator or a size guide.

AMP against the alternatives

Approach	Speed profile	UI/scripting freedom	Where it fits
AMP	Fast by default, enforced by the format's restrictions	Low; whitelisted components only	High-traffic content and category pages with simple UI
Well-optimized canonical page	Depends entirely on implementation discipline	Full	Checkout, product configurators, anything needing rich interaction
Hybrid (AMP for entry, canonical for deep engagement)	Fast entry, full-featured once engaged	Full past the landing step	Storefronts where browsing and checkout have different needs
PWA / instant-loading canonical	Fast on repeat visits via service worker caching	Full	Sites with a returning-visitor base worth caching for

Running an honest AMP-vs-canonical test

Don't assume. Run the comparison as an actual test, the same way you'd test any other page change.

Split traffic between AMP and a well-optimized canonical version of the same template, matched on device and connection type
Track LCP, CLS, and INP through the Web Vitals field data, not just Lighthouse's lab score
Measure conversion rate and bounce rate for each variant over a full business cycle, not a single week
Segment the result by connection speed, since AMP's advantage shrinks on fast connections and grows on slow ones

Testing AMP against canonical without segmenting by connection speed is how teams convince themselves AMP won when it only won for the slowest quartile of visitors.

If the canonical page matches AMP on Core Web Vitals and converts better, AMP isn't buying you anything on that template. Drop it there and keep it where the gap is real.

Automating the comparison instead of eyeballing it

A one-off DevTools run is a snapshot. Wire the AMP-vs-canonical comparison into a script that runs on every deploy, so a regression on either version shows up before it reaches production traffic.

npx lighthouse https://example.com/amp/product/123 --output=json --output-path=amp.json
npx lighthouse https://example.com/product/123 --output=json --output-path=canonical.json

Feed both JSON outputs into a Lighthouse CI budget so a template that regresses past your LCP or CLS threshold fails the build, the same way a broken unit test would. Pull the equivalent field data from the PageSpeed Insights API on a schedule, since lab scores from a single CI run can miss what real devices on real networks experience.

Run the same comparison nightly against production, not just PR branches, and post the delta to a shared channel. A regression that ships quietly on a Tuesday is easy to miss without an automated nightly diff surfacing it.

A common migration mistake

Teams that decide to drop AMP often remove the AMP templates before the canonical redirects are live and verified. That window turns indexed AMP URLs into 404s, which costs more organic traffic than AMP itself was ever worth.

A migration checklist if you're moving off AMP

With Next.js retiring built-in AMP support in version 16, teams on that stack need a plan regardless of how the performance comparison turns out.

Audit which templates actually rely on AMP-exclusive traffic, by checking Search Console's legacy AMP report or server logs for the amp query parameter
Rebuild the canonical version to hit the same Core Web Vitals thresholds AMP was hitting by default
Set up 301 redirects from AMP URLs to canonical URLs before removing the AMP templates, not after
Re-run the field data comparison 30 days post-migration to confirm Core Web Vitals didn't regress

Keep a rollback path open during that window. If a canonical template regresses unexpectedly, reverting the affected pages to AMP should take minutes, not a redeploy from a stale branch.

The real takeaway

AMP's value today is conditional. It buys speed and a Core Web Vitals head start, not a ranking shortcut, and the tradeoffs it forces on scripting and UI need to be weighed against what those features are worth on the page in question.

We treat AMP as one implementation option for hitting Core Web Vitals targets, not the default. On mobile storefronts, the honest comparison is AMP against a well-optimized canonical page on the same stack, tested against real conversion data instead of assumed speed wins.

FAQ

Does AMP still help SEO rankings?

Not directly. Google dropped the Top Stories carousel requirement in 2021 and ranks AMP and canonical pages the same way, through the same Core Web Vitals thresholds.

Is AMP being deprecated?

Framework support is shrinking. Next.js deprecated built-in AMP support in version 15.5 and plans full removal in version 16. The AMP project itself is still maintained on GitHub.

Can a canonical page match AMP's speed?

Yes, with the same discipline AMP enforces by default: minimal render-blocking resources, explicit image dimensions, and limited third-party scripts.

Should checkout ever run on AMP?

Generally no. Payment forms and security features are easier to build, test, and audit on the canonical page, which is why hybrid setups keep AMP for browsing and canonical for checkout.

What replaces AMP for teams moving off it?

A well-optimized canonical page, measured against the same Core Web Vitals targets, often with a service worker for repeat-visit caching if the audience has meaningful return traffic.

Is it safe to run Lighthouse audits in CI on every deploy?

Yes, and it catches regressions faster than a manual spot check. Budget the CI run's lab thresholds a little looser than production targets, since CI hardware and network conditions rarely match a real device exactly.

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.