Site Speed Under One Second: The Engineering Checklist

Sub-second page load isn't a marketing claim. It's a specific engineering achievement, and on modern Adobe Commerce, Shopify Plus, or BigCommerce stores, it's achievable with the right architectural decisions made in the right order. Most of the retailers who aim for sub-second loads and fall short miss the same set of items. This checklist exists to make sure you don't.

The business case for sub-second page loads is well-documented. Deloitte's Milliseconds Make Millions research quantified an 8.4% conversion lift for every 0.1-second improvement in retail site speed. The engineering case is less well-documented, because teams tend to talk about the outcomes without being specific about the work. The checklist below covers the specifics.

At Bemeir, we've built sub-second stores on Adobe Commerce with Hyvä and on headless architectures with Next.js. The patterns are consistent. The discipline to actually hit the threshold is where most teams fall short.

Frontend Architecture

• Theme choice supports sub-second performance. Magento Luma almost never hits sub-second without extreme optimization. Hyvä does out of the box. Shopify Dawn does. Custom headless does if built carefully.
• Initial JavaScript bundle under 100KB gzipped. Hyvä-equivalent bundle size. Frameworks that blow past 300KB on initial load rarely hit sub-second.
• Critical CSS inlined in head. Above-the-fold CSS renders before external stylesheets load.
• Non-critical CSS deferred or loaded async. Below-the-fold styles don't block initial render.
• Fonts loaded with font-display: swap. Custom fonts don't block text rendering.
• Preconnect and preload hints for critical resources. The LCP image and primary API endpoints are hinted in the head.
• No render-blocking JavaScript in the head. All scripts are async, defer, or placed before the closing body tag.

Image Delivery

• Modern formats (AVIF, WebP) served to supporting browsers. JPG/PNG only as fallback.
• Responsive images with srcset. Appropriate sizes served per device.
• LCP image has priority hint. <img fetchpriority="high"> on the hero image.
• Below-fold images lazy loaded. loading="lazy" on non-critical images.
• Image CDN in place. Fastly Image Optimizer, Imgix, Cloudinary, or equivalent.
• Image dimensions specified. Width and height attributes prevent CLS.
• Image quality tuned for size-quality tradeoff. 70-85 JPEG quality, similar for modern formats.

Caching Architecture

• CDN in front of the origin. Fastly, Cloudflare, or Akamai at minimum for static assets.
• Full page cache hit rate above 85%. Measured weekly.
• Browser caching headers set correctly. Aggressive max-age on static assets with cache-busting on release.
• API response caching where appropriate. Product data, category listings, search results cached at the edge when possible.
• Service worker caching strategy (if PWA). Network-first for dynamic, cache-first for static.
• Redis or Memcached for backend object cache. Adequately sized with low eviction rates.
• Varnish configured with appropriate TTLs. Configuration reviewed for cache-busting extensions.

Backend Performance

• TTFB on cached pages under 300ms. Measured from real user data.
• TTFB on uncached pages under 800ms. Even cold cache responses shouldn't drag the site.
• Database query performance measured. Slow query log reviewed. No queries over 500ms in production paths.
• Elasticsearch tuned for product search. Relevant fields indexed; query response times under 200ms.
• PHP-FPM worker configuration sized correctly. Workers don't run out under peak load.
• Database connection pooling in place. Connections don't exhaust under load.
• Application-level profiling in place. Blackfire, New Relic APM, or similar for diagnosing regressions.

Third-Party Scripts

• Third-party script inventory complete. You know every script loaded on every page.
• Critical vs. non-critical classification. Analytics may be critical; chat widget may not be.
• Non-critical scripts deferred or loaded async. No blocking third-party JavaScript.
• Tag manager used to govern script loading. Google Tag Manager or similar with loading rules.
• Consent-based script loading. Scripts requiring consent don't load before consent.
• Script performance budget. Total third-party JS kilobytes has a committed ceiling.
• Unused scripts removed quarterly. Audit performed every quarter.

Infrastructure

• Origin server appropriately sized. Not over-provisioned, not undersized.
• Autoscaling configured for traffic spikes. Infrastructure scales with real traffic patterns.
• Origin geographic placement appropriate. US-based stores have US-based origins; global stores have multi-region.
• HTTPS with modern TLS configuration. TLS 1.3, HTTP/2 or HTTP/3.
• HSTS enabled. Browsers skip the HTTP-to-HTTPS redirect.
• OCSP stapling enabled. TLS handshake faster.
• gzip or Brotli compression enabled. All text responses compressed.

Measurement and Observability

• Real user monitoring in place. New Relic Browser, Datadog RUM, or SpeedCurve capturing field data.
• Synthetic monitoring running. WebPageTest or equivalent running at regular intervals.
• Core Web Vitals tracked in production. LCP, INP, CLS measured continuously.
• Performance budget enforced in CI. Build pipeline catches performance regressions before production.
• Performance alerts configured. Team gets paged if p75 LCP crosses threshold.
• Performance dashboard visible to team. Metrics aren't hidden; they're front and center.

Mobile-Specific Optimization

• Mobile-first design confirmed. Mobile experience isn't a fallback; it's the primary design target.
• Mobile network throttling tested. Site tested on 4G and slower connections.
• Mobile device testing on real devices. Not just Chrome DevTools emulation.
• Viewport meta tag correct. width=device-width, initial-scale=1.
• Touch targets sized appropriately. 44px minimum tap targets.
• Mobile-specific cache behavior verified. CDN varies correctly on user agent if needed.

Platform-Specific Items

Adobe Commerce / Magento

• Extension audit complete. Every third-party module reviewed for performance impact.
• Full page cache working correctly. Hole-punching patterns minimized.
• Inventory management service (MSI) configured appropriately. Not causing checkout latency.
• Product flat tables considered for large catalogs.
• Admin panel performance separated from frontend performance. Admin can be slow; frontend cannot.

Shopify Plus

• Theme Liquid rendering profiled. Inefficient Liquid loops fixed.
• App performance reviewed. Heavy apps removed or optimized.
• Section rendering logic reviewed. Heavy sections optimized or deferred.

Headless / PWA

• SSR or SSG for pages that need SEO. Client-side rendering only for post-login or dynamic content.
• Hydration strategy optimized. Full page hydration avoided where possible.
• API response times measured separately from frontend. Backend performance is isolated.

Operational Discipline

• Performance review in every release. New features measured for performance impact.
• Regression detection automated. CI catches performance drops.
• Team accountability for performance. Someone owns speed as a metric.
• Business stakeholders see performance metrics. Finance, merchandising, and marketing see the numbers.
• Quarterly performance audits. Third-party or internal audit runs quarterly.

Common Failure Patterns to Avoid

Decision Point

Stores that hit 80%+ of this checklist consistently achieve sub-second load times on their most-trafficked pages. Stores that hit under 50% almost never get there. The checklist is pragmatic, not aspirational—every item represents engineering work that's well-understood and deliverable.

Bemeir has taken Adobe Commerce retailers from 4-second LCP to sub-second through systematic work against this kind of list. The work is real engineering, but it's not mysterious. The retailers who get there are the ones who treated performance as a discipline rather than an event.

Sub-second page loads aren't for everyone—some stores can't justify the engineering investment, and that's fine. But for retailers whose conversion math makes the investment pay back, this checklist is the roadmap. Pair it with Google's web.dev performance resources for deeper technical context on specific techniques.