Improving a heavy Shopify product page without sacrificing accessibility semantics

What was happening

A representative product page combined a responsive gallery, variant and pricing updates, a sale timer, reviews, cross-sells, store availability, size/model content, and custom cart interactions. Earlier PageSpeed runs showed accessibility scores around 80 on mobile and 75 on desktop, while performance was roughly 26 mobile and 35 desktop. The wider site also had hundreds of pages linked to oversized images.

Why the obvious solution was not enough

Aggressively deleting scripts or delaying every resource could break product selection, add-to-cart, announcements, or visual stability. The optimization needed to distinguish critical product behavior from third-party or below-the-fold work and preserve the ARIA/live-region behavior already used by interactive components.

How the solution works

1. Right-size product media and use responsive image sources instead of shipping desktop-sized images to every device.
2. Preload and prioritize the primary product image while lazy-loading gallery images that are not needed for the first render.
3. Give images and major dynamic regions stable dimensions or minimum space so the page does not jump while media, price, reviews, timers, or cross-sells initialize.
4. Load noncritical CSS without blocking the first render and defer product JavaScript that does not need to execute during HTML parsing.
5. Audit duplicate or template-unnecessary app scripts and delay secondary widgets such as reviews, chat, or CRO modules where their loading order allows it.
6. Remove duplicated gallery markup and avoid unnecessary DOM injection when the same product information is already present in a reusable component.
7. Keep the first gallery image eager/high priority and later images lazy, but preserve meaningful alt text and button labels for media controls.
8. Retain ARIA labels and live/status regions around add-to-cart, errors, loading, and product-interaction feedback while refactoring the performance path.
9. Re-run Lighthouse/PageSpeed and accessibility tools after the performance changes because a faster page that breaks keyboard or screen-reader behavior is still a regression.

{% assign hero = product.selected_or_first_available_variant.featured_image | default: product.featured_image %}

{{ hero
  | image_url: width: 1440
  | image_tag:
      widths: '360,540,720,960,1200,1440',
      sizes: '(min-width: 990px) 50vw, 100vw',
      loading: 'eager',
      fetchpriority: 'high',
      alt: hero.alt
}}

<script src="{{ 'product.js' | asset_url }}" defer></script>

What should be verified before shipping

• Compare mobile and desktop Lighthouse runs using multiple samples because lab scores vary by run conditions.
• Verify variant changes, gallery controls, add-to-cart, sale pricing, errors, and loading announcements after deferring scripts.
• Check that lazy-loaded images still expose meaningful alternatives and do not create layout shifts when they enter the viewport.
• Verify keyboard focus and live-region behavior after removing duplicated or delayed DOM modules.
• Audit third-party scripts again after app changes because they can reintroduce blocking work without a theme-code change.
• Treat accessibility and performance scores as diagnostic signals and pair them with real interaction QA.

What changed

Observed PageSpeed category scores on the representative product-page work improved from about 80 to 97 accessibility on mobile and 75 to 97 on desktop; SEO improved from 92 to 100 on both. Performance moved from roughly 26 to 40 on mobile and 35 to 40 on desktop, while total blocking time improved from about 4,980 ms to 650 ms on mobile and 2,260 ms to 820 ms on desktop. At the wider-site level, large-image pages were reduced from 490 to 19, links to large images from 5,623 to 125, slow pages from 45 to 25, and the recorded site health score improved from 83 to 98. These were observed optimization metrics, not ADA compliance claims.

Reusable lesson

Performance and accessibility are separate quality dimensions, but the engineering work can support both: smaller media, less blocking JavaScript, stable layout, and cleaner component boundaries make the page easier to load and easier to reason about without removing semantic behavior.