A custom Shopify theme engineered for speed on real phones
Scenario: DTC brand with a catalog-heavy storefront
Our reference design for storefront speed — the architecture and measurement discipline we bring to every Shopify theme build.
The problem
Most Shopify themes are slow for structural reasons, not accidental ones: they ship JavaScript for every feature any buyer of the theme might enable, load app scripts before content, and treat images as an afterthought. Merchants then buy speed apps that add more JavaScript to fix the JavaScript. The result is a storefront that scores badly on Core Web Vitals and feels sluggish exactly where most traffic is — mid-range Android phones on mobile networks.
Requirements
- Fast on a mid-range phone over 4G — measured on every build, not scored once on a desktop simulator
- Fully merchant-editable: sections, blocks, and settings for every component
- No JavaScript framework on the storefront; JS only where interaction demands it
- Cart, filtering, and search interactions without full page reloads
- A disciplined image pipeline: responsive sizes, lazy loading, no layout shift
The solution
A theme architecture on Online Store 2.0 with server-rendered Liquid as the default and small vanilla-TypeScript islands only where interactivity earns them (cart drawer, predictive search, filters). CSS is written to a strict budget per template; images go through a single reusable snippet that enforces srcset, dimensions, and lazy-loading rules; and third-party scripts are treated as a budget item the merchant spends knowingly, not a default.
Architecture
Server-rendered Liquid templates with progressive enhancement: each interactive island (cart drawer, search, filtering) is an isolated TypeScript module that hydrates one custom element and speaks to Shopify's Section Rendering API for partial updates. No framework runtime, no global state, no bundler output larger than the content it serves. The image snippet centralizes every responsive-image decision so template authors can't accidentally ship a layout shift.
Challenges & resolutions
Filtering and cart updates without page reloads usually pull in a framework, and the framework becomes the performance problem.
Resolution — Shopify's Section Rendering API returns re-rendered section HTML from the server — so islands stay tiny: they request the section, swap the DOM, and manage focus. Interactivity without shipping a client-side rendering engine.
Keeping a theme fast is easy on launch day and hard in month six, when apps and pixels accumulate.
Resolution — The design includes a documented 'script budget' pattern: third-party scripts load through one audited entry point with a written register of what each one costs. Speed decay becomes a visible decision instead of silent drift.
Merchant editability and performance pull in opposite directions — every flexible setting is a potential foot-gun.
Resolution — Settings are designed as constrained choices (spacing scales, image ratios, color roles) rather than free inputs. Editors compose within a system that cannot express a broken layout, which is also what keeps the design coherent.
Why this design exists
Every agency claims their themes are fast. We'd rather make the claim testable: this is the theme architecture client builds start from, paired with a written measurement protocol — Lighthouse and WebPageTest runs on a mid-range Android profile over throttled 4G — executed on every build, so speed is demonstrated project by project instead of asserted in marketing copy.
Design notes
Server-rendered by default. The storefront's job is showing products, and Liquid does that on the server for free. JavaScript exists only as small islands around genuinely interactive elements — the cart drawer, predictive search, collection filtering — each an independent custom element that can fail without taking the page down.
The Section Rendering API is the trick most themes miss. Instead of re-implementing product cards in client-side JavaScript (and maintaining two rendering paths forever), islands ask Shopify to re-render the section server-side and swap the HTML. One rendering path, no hydration cost, no drift between server and client markup.
Images are a system, not a habit. One snippet renders every image on the theme: it demands intrinsic dimensions (no layout shift), generates the srcset ladder, and decides lazy versus eager loading by position. Template authors can't opt out, which is the only way image discipline survives contact with deadlines.
What we'd adapt per client
The design layer is intentionally plain — each build brings the brand's typography, color, and art direction on top of the structural skeleton. The measurement protocol, image system, and island architecture transfer as-is; they're the point.
What the design guarantees
- Designed to hold fast Core Web Vitals on mid-range Android over throttled 4G — with a written measurement protocol run on every build, so speed is demonstrated per project, not asserted once
- The architecture ships a fraction of a marketplace theme's JavaScript, because features exist only when a build actually uses them
- This is the skeleton our client theme builds start from, and it carries the measurement discipline with it
Have a similar problem?
Describe the problem in plain language — broken, slow, manual, or missing. We'll tell you honestly whether and how we can help.
- 01We reply within one business day
- 02A short call to understand the problem
- 03A written scope and fixed quote — no obligation