How We Hit 100/100 Mobile PageSpeed on panarchdigital.com

Summary
We reached 100/100 mobile PageSpeed on panarchdigital.com by rendering at the edge, shipping near-zero render-blocking JavaScript, serving responsive AVIF/WebP images with explicit dimensions, and deferring everything non-critical. Field data for the site shows a 0.47-second P75 LCP and an 87ms P75 TTFB (9 July 2026).
A perfect PageSpeed score is not a vanity metric; it is the visible output of an architecture that respects the user's device and network. Here is how we got our own site, panarchdigital.com, to 100/100 on mobile, and why each decision applies just as much to a D2C storefront.
Start at the edge, not the origin
We render pages at the edge with a mix of static generation and Incremental Static Regeneration, so the HTML is served from a node physically close to the shopper. That single decision collapses Time to First Byte (we target well under 200ms) before a single asset has loaded.
Treat JavaScript as a liability
Most slow storefronts are slow because they ship megabytes of JavaScript that block the main thread. We default to server components, hydrate only what is interactive, and lazy-load anything below the fold (chat widgets, carousels, analytics). The page is usable before the heavy bundles ever arrive.
Images, done properly
- Serve modern formats (AVIF/WebP) with automatic responsive sizing.
- Always set explicit width and height to eliminate layout shift (CLS).
- Prioritise the hero/LCP image and lazy-load the rest.
Measure like an engineer, not a marketer
We test with Google PageSpeed Insights and WebPageTest under mobile throttling. Both are lab tests that simulate a single load, so the 100/100 score is a lab result. Field data (real-user Core Web Vitals from CrUX) is the scoreboard that actually matters, and we publish ours at /performance-baseline: a 0.47-second P75 LCP and 87ms P75 TTFB for panarchdigital.com (9 July 2026).
Why a D2C brand should care
Speed is a conversion lever: Akamai found that a 100ms delay can cut conversion by up to 7%, and Google uses Core Web Vitals as a ranking input. A fast storefront converts more of the traffic you already pay for and ranks better for the traffic you do not.
Frequently asked
How do you get a 100 PageSpeed score?
Render at the edge for a fast TTFB, ship minimal render-blocking JavaScript, serve responsive next-gen images with fixed dimensions, and defer non-critical work. The score follows the architecture; it is not something you bolt on at the end.
Does PageSpeed actually affect sales?
Yes. Faster pages reduce bounce and cart abandonment (Akamai found that a 100ms delay can cut conversion by up to 7%), and Core Web Vitals are a Google ranking signal, so speed compounds both conversion and organic traffic.
Sources
Related