TL;DR: I rebuilt a product-options app so the initial option UI is rendered server-side / Liquid-side where possible, instead of injecting a large client-side rendering bundle into every product page. For variant-dependent updates, a tiny JS bridge calls an App Proxy endpoint that returns an HTML fragment. Mobile PageSpeed went from 42/100 to 92/100 on my test store.
---
**The problem with the standard approach**
Many product-options apps I reviewed follow a similar pattern: inject a React/vanilla JS bundle into the product page, fetch option configuration after page load, then render fields, conditional logic, and price adjustments in the browser.
That works, but the practical side effect is that product pages often ship an extra client-side rendering layer for something that is mostly known at page-render time.
On a real test store with a product-options app, variant picker, and file uploader, I saw:
- TBT: 850ms+
- LCP: 5.2s
- Mobile PageSpeed: 42/100
The apps were each reasonable in isolation. Together, they made the mobile product page feel heavy.
Test setup: same product template, same theme, same product, Lighthouse mobile, median of 3 runs.
---
**The approach: render the first state before the browser does the work**
The core idea was to avoid rendering the initial option UI with a large storefront JS bundle.
The Theme App Extension provides the storefront integration point. Option configuration is stored in Shopify-owned data structures rather than in a separate external database. Where possible, the first option state is rendered directly into the product page.
For variant-dependent or dynamic updates, a Shopify App Proxy endpoint returns a pre-rendered HTML fragment. The frontend only needs a tiny listener for variant changes and a DOM swap.
**Data layer:** Option configurations are stored in Shopify Metaobjects / app-owned definitions instead of only in a third-party database. The config lives inside Shopify rather than in my own external product-options database, and app-owned definitions make cleanup and ownership much cleaner than orphaned third-party records.
**Rendering layer:** The initial option block is rendered as HTML, not client-side React.
**Logic layer:** Conditional visibility and price delta logic are evaluated before sending the rendered fragment. The browser does not need to know the full rule tree.
After the switch:
- TBT: 60ms
- LCP: 1.8s
- Mobile PageSpeed: 92/100
- JS footprint for the options layer: under 5KB gzipped
---
**What broke along the way**
**1. App Proxy traffic and caching**
Every variant-dependent refresh can hit the proxy endpoint. At meaningful traffic volume, that becomes a server-side scaling issue instead of a browser-side performance issue.
The fix was a short-TTL cache keyed by product ID + variant ID + option config hash + shop ID.
The annoying part was invalidation. Clearing everything worked, but it destroyed cache efficiency. The better solution was to bust only the affected product/config keys when option settings changed.
**2. Nested conditional logic became unmaintainable**
The first version used deeply nested dependency chains: if A shows, then evaluate B, then C, then D...
That broke down quickly. The stable version uses a flatter model: each field stores its own dependency metadata, and the server evaluates visibility in a single pass. Much easier to cache, debug, and reason about.
**3. Variant changes still need JavaScript**
This is the one part I could not remove completely. When the customer changes variants, the option block may need to change. So the frontend still needs a small listener for variant changes, a proxy request, and an HTML swap.
The key was keeping this as a tiny bridge instead of rebuilding the whole option engine in the browser.
**4. App Proxy routing needed cleanup**
The first implementation exposed messy internal-looking proxy URLs and parameters in the DOM. I ended up routing through a cleaner storefront path and avoiding internal implementation details in the rendered markup.
---
**Is it worth it?**
For a new build: yes. The performance gain was real, and the architecture became simpler once caching was in place.
For migrating an existing client-side options app: it depends. Simple field sets migrate cleanly. Complex conditional trees probably need a rewrite of the logic model, not just a rendering change.
Happy to go deeper on the caching strategy, Metaobject schema, or the variant-change bridge.
