Adobe Commerce accessibility and core web vitals

X minutes (update this in properties)

style

article-header-section

Performance and accessibility are treated as separate workstreams on most Adobe Commerce projects. This guide covers both disciplines together because on a modern Adobe Commerce storefront, the engineering decisions that improve one almost always improve the other.

Performance gets a sprint before go-live. Accessibility gets an audit after legal raises a concern. Both assumptions are expensive.

Core web vitals: The thresholds and what they measure

Core Web Vitals have been Google ranking factors since 2021. Pages that miss the LCP, INP, or CLS thresholds can see their competitiveness in search rankings affected, particularly on competitive queries. Core Web Vitals function as a ranking signal among many, not a hard eligibility gate: content relevance, authority, and quality remain significantly stronger ranking factors. Various SEO industry analyses have offered estimates of Core Web Vitals' relative weighting — figures in the 10 to 15 percent range are commonly cited — but Google has not published an official breakdown of ranking-factor weights, so any specific percentage, including that one, should be read as a directional industry estimate rather than a confirmed figure.

The relationship between performance and accessibility is not coincidental. A storefront that loads fast because it avoids heavy JavaScript also loads fast for assistive technology users, whose devices are frequently less powerful than the latest iPhone. A storefront that structures its DOM correctly for screen readers often benefits search engine understanding as well, though accessibility semantics, crawler optimization, structured data, and rendering behavior remain distinct disciplines. Good DOM structure for screen readers does not automatically guarantee optimal structure for every crawler consideration. A product image with a meaningful alt attribute is both an accessibility requirement and an SEO signal. Building for both from the start, rather than retrofitting either, is always faster and cheaper than addressing them after go-live.

Google uses three Core Web Vitals as ranking signals, measured at the 75th percentile of field data from the Chrome User Experience Report (CrUX). Google publicly categorizes results as Good, Needs Improvement, or Poor for reporting purposes; these classifications can influence rankings as one signal among many rather than functioning as a pass or fail gate on ranking eligibility. As of 2026, the current thresholds are:

Largest Contentful Paint (LCP): measures loading performance, specifically how long it takes for the largest visible content element on screen (usually a hero image, product image, or large text block) to render. Good: under 2.5 seconds. Needs improvement: 2.5 to 4.0 seconds. Poor: above 4.0 seconds. On Adobe Commerce storefronts, the LCP element is typically the hero image on the home page or the primary product image on a PDP, though page layout and template variations mean this isn't universal. Unoptimized images, render-blocking JavaScript, and slow server response times are the three most common LCP failures.
Interaction to Next Paint (INP): replaced First Input Delay (FID) as a Core Web Vital in March 2024. INP measures the response time from any user interaction (click, tap, keystroke) to the next visual frame rendered by the browser, across all interactions during a page visit, not just the first one. Good: under 200 milliseconds. Needs improvement: 200 to 500 milliseconds. Poor: above 500 milliseconds. On Commerce storefronts, the highest-risk interactions for INP are add-to-cart, filter application on PLPs, and quantity updates in the cart. Heavy React component trees and long JavaScript tasks on the main thread are the primary INP failure causes.
Cumulative Layout Shift (CLS): measures visual stability, or how much page content shifts unexpectedly while the page is loading. Good: under 0.1. Needs improvement: 0.1 to 0.25. Poor: above 0.25. The most common Commerce CLS sources are product images without explicit dimensions (the page shifts when the image loads), promotional banners injected above the fold by a CMS or tag manager, and font swaps where a fallback font renders first and then shifts when the web font loads.

The Luma baseline: Where most Commerce storefronts start

A standard Adobe Commerce Luma-based storefront with no performance optimization often scores in the 20 to 40 range on mobile Lighthouse tests. This varies enormously by extension count, hosting quality, and theme implementation and is best read as a typical range for unoptimized deployments, not a universal baseline every Luma deployment should expect. Production deployments with standard Fastly CDN, image optimization, and JavaScript bundling tuning typically score in a substantially higher range. Reaching consistent 90+ Lighthouse scores on Luma generally requires real engineering effort on feature-rich Commerce sites: custom critical CSS in lining, aggressive JavaScript deferral, Fastly VCL tuning for edge caching, third-party script isolation, and careful image lazy-loading implementation across all page templates, though lightweight Luma implementations can exceed this level with less work.

NOTE

Both the 20-to-40 unoptimized baseline and the 90+ optimized target are commonly observed patterns, not guaranteed outcomes. Large, feature-heavy enterprise Commerce deployments — with extensive third-party tag managers, personalization layers, and multiple extensions — frequently plateau well below 90 even after significant optimization work, simply because of the number of independent systems contributing to the page. Treat these figures as a starting frame of reference, not a benchmark every implementation should be measured against.

The reason Luma tends to start at this baseline is largely architectural. In a traditional Luma or origin-centric storefront, every page request travels to the origin server, through the Commerce business logic stack (PHP, MySQL, Redis), and the rendered HTML is then sent to the browser. Origin processing time contributes significantly to storefront performance, though page speed is not coupled to backend response time alone: frontend rendering performance is also heavily affected by JavaScript execution, hydration, third-party scripts, image delivery, and client-side rendering, all of which are independent of backend response time. Fastly caches the rendered page, but the first request to a URL after a cache miss pays the full PHP render cost. Add a JavaScript bundle that includes RequireJS, jQuery, and a dozen extension scripts, and the browser has significant work to do before it can render anything visible, which is exactly what LCP measures.

The three most impactful Luma performance improvements

Hero image optimization for LCP: the LCP element on a Luma PDP is typically the primary product image. Serving it as a WebP with correct width and height attributes, adding fetchpriority="high" to the img tag, and ensuring it is not lazy-loaded (a common mistake; lazy-loading the LCP image directly worsens LCP) reduces LCP by 0.5 to 1.5 seconds on well-tuned Luma deployments.
JavaScript deferral for INP: Luma's RequireJS dependency loader creates long tasks on the main thread that block user interactions. The primary technique is deferring all non-critical JavaScript, analytics scripts, chat widgets, and marketing tag manager scripts until after the page is interactive. Third-party scripts are the single largest source of INP failures on Commerce storefronts. A Google Tag Manager container with 15 tags can add 200 to 500 milliseconds to INP on a PDP.
Explicit image dimensions for CLS: every product image, banner, and embed on every page template must have explicit width and height attributes set. CSS aspect-ratio can supplement this for responsive images. Fixing image dimensions is the single highest-ROI CLS improvement on most Luma deployments; it requires no infrastructure changes and directly addresses the most common CLS source.

The EDS advantage: designed to start fast

Adobe Commerce Storefront powered by Edge Delivery Services takes a fundamentally different approach to the performance problem. Rather than serving pages from an origin server and caching them at the edge, EDS serves catalog and content pages from the edge itself: static, pre-rendered HTML served from globally distributed CDN nodes. For that class of page, there is no PHP render cost, no database query, and no business logic execution on the critical path.

NOTE

This applies most cleanly to browsing pages: home, category, and product pages that don't depend on a logged-in session. Authenticated account pages, cart and checkout, real-time pricing or inventory, and personalized content still involve API calls, client-side rendering, or server-side logic at some point in the flow — EDS reduces how much of the page depends on that logic, it does not eliminate backend processing from the storefront entirely. Commerce and web rendering generally are also trending toward hybrid models (server-side rendering, islands architecture, edge functions) that blend static delivery with dynamic logic, so 'static vs. dynamic' is increasingly a spectrum rather than a binary choice between architectures.

EDS storefronts are designed to support very high Lighthouse performance scores by default, with substantially less performance optimization effort than traditional architecture, often landing in the high-90s and sometimes reaching 100 on unmodified pages. Actual scores still depend on implementation choices, personalization, third-party scripts, images, custom JavaScript, and analytics tooling: a real EDS storefront that adds personalization, experimentation, or third-party widgets will see these factors materially affect Core Web Vitals outcomes, the same as any architecture.

Adobe's EDS engineering community follows a documented practice called “Keeping it 100,” published as a guide on Adobe's Experience League site: the intent on every EDS project is to start from a Lighthouse score of 100 and treat any drop as something to fix immediately rather than defer. Many EDS boilerplates wire a GitHub PR bot into the workflow that flags a pull request when the Lighthouse score (measured via PageSpeed Insights) drops below 100, generally with some built-in buffer for scoring volatility; teams can and do configure this threshold differently, and it is a project-level convention rather than a platform-enforced guarantee.

GitHub Actions are integrated into the EDS workflow so that Lighthouse scans run automatically on every pull request, showing whether a change has negatively impacted performance, SEO, or accessibility. Automated accessibility scans running at the PR level catch regressions the moment they are introduced rather than weeks later during a dedicated audit, though a passing automated scan is a guardrail rather than proof of WCAG compliance: automated tools catch only a subset of accessibility issues and should be supplemented with manual testing.

A real-world migration documented on Experience League shows a storefront moving from a Luma baseline Lighthouse score of approximately 20, with some pages taking up to 15 seconds to load, to consistently landing in the mid-to-high 90s after migration to EDS. The engineering work shifted from performance optimization to feature implementation.

style

article-content-section