Shopify themes engineered down to the Liquid render cost.
Your Shopify theme was fast when the catalog was small. Now collection pages render through nested Liquid loops and search is an app fighting the theme. We start with render cost.
Render cost is a theme decision, not an app problem.
Commerce teams rarely call us about Liquid. They call because collection pages crawl, search returns products nobody asked for, and every app installed to fix that added another script tag. Underneath, it is usually one theme repeating the same expensive decision on every page it renders.
So the first thing we read is Liquid render cost: which loops run per product card, what gets looked up inside them, and which sections could do the work once instead of per item. Then the search layer. Then the metafield architecture holding the product data together.
That sequence comes from doing it on a live store. RF MAX runs SearchSpring's Snap SDK with result components we wrote in Preact, product display driven by metafields, multi-level navigation and a collection URL structure built to be indexed rather than tolerated. No badge sits behind that work — only the theme.
Collection pages take seconds to render and we've tried every app.
Apps are rarely the cause. We profile Liquid render cost per section and cut the per-item lookups, then look at what the app layer adds to a theme that renders once.
Search shows products nobody was looking for.
SearchSpring Snap SDK, configured properly and rendered through Preact result components, so facets, badges and stock state come from your data, not a default template.
Product data lives in the description field and nowhere else.
A metafield architecture instead: typed fields per product, referenced by the Liquid template, so one spec renders in search results, on the product page and in feeds.
We keep being told to migrate to Checkout Extensibility.
You do, and it is a planning job before it is a coding job. Every script, customization and app touching checkout gets mapped, then sequenced around your calendar.
Scope, spelled out.
Custom Liquid theme work
New sections and templates written in Liquid, or an existing theme reworked, with the render cost of each loop known before any of it ships.
Liquid render cost pass
Per-section profiling of what runs on every product card, then lookups hoisted, cached or deleted so a collection page renders once.
SearchSpring Snap SDK
Snap SDK integration with custom Preact result components, so faceting and predictive search use your theme's markup, not a vendor default.
Metafield architecture
Typed metafields designed around how the catalog is actually merchandised, then referenced from templates, search results and product feeds.
Navigation and URLs
Multi-level navigation and a collection URL structure crawlers can follow and merchandisers can extend without opening a support ticket.
Checkout Extensibility
Migration planning for Checkout Extensibility: every script and app touching checkout mapped, sequenced, and tested on a preview profile first.
Accessibility and Vitals
Keyboard paths, focus order, contrast and Core Web Vitals checked on the templates carrying revenue, not on the homepage alone.
What actually happens, week by week.
Profile
We read the theme and time the Liquid, section by section, before proposing a single change to it.
Search
Snap SDK configuration and result components designed against your real facets and stock rules.
Rebuild
Metafields defined, then templates rewritten to read them, on a duplicate theme nobody is shopping on.
Render
The render-cost pass: loops hoisted, lookups dropped, assets trimmed, measured on collection pages.
Checkout
Checkout Extensibility mapped and sequenced, then published in a window that you pick, not us.
The tools we actually use here.
Shopify holds several separate skills, and this list is the ones this page is about: the theme language, the search layer, the product data model, and the code that renders it.
Deliverables, outcomes and who this is for.
- Theme audit with Liquid timings
- Snap SDK config and Preact components
- Metafield schema and templates
- Navigation and collection URL map
- Checkout Extensibility migration plan
- Collection pages that render once
- Search results built from your data
- Product specs typed, not pasted
- Checkout migrated on your schedule
Commerce teams on Shopify with a real catalog, a search problem, and a theme that more than one developer has extended.
The store we can name, and what shipped on it.
RF MAX: a production theme audit
RF MAX (rfmax.com) is a live Shopify store, and the audit came first: architecture, CSS, accessibility and performance, reviewed on the theme they were selling through. Auditing before rebuilding is not caution. It is the only way to know which slow things are the theme's fault and which arrived with an app.
Search rendered in components we wrote
SearchSpring's Snap SDK on RF MAX, customized rather than dropped in — result components written in Preact, so cards, facets and predictive search render through the store's own markup, with product display driven by metafields instead of logic hard-coded into a template.
Navigation, URLs and the data underneath
Multi-level navigation for a deep catalog, plus a collection URL structure designed for indexing rather than inherited from a theme default. The metafield architecture beneath it means one product spec reads the same in search results, on the product page, and anywhere else it is asked for.
Checkout Extensibility, planned first
Migration planning on the same store: what touches checkout, what breaks when the old scripts go, and the order those changes have to happen in. The plan is the deliverable. Teams who skip it discover the undocumented script during the migration instead of before it.
Questions we get on the first call.
No. We hold no reseller status and no badge from anyone. That status matters for buying your plan and for referral commissions, and it has never once made a theme render faster. What matters here is whether somebody has shipped Snap SDK customization and metafield-driven templates on a live store. We have.
Fixed-scope, and quoted before it starts. The Shopify-specific part is Liquid timings per section, so you can see which loops cost you money on a collection page. Scope, format and pricing for audits in general live on the Code Audits page. Hiring us for the rebuild is always a separate decision.
Yes, and the two usually need separating first. Snap SDK renders its own result components, so the real question is which surfaces it owns and which stay on predictive search. We draw that line on paper, build the Preact components behind it, and keep the old path live until the new one passes.
No. The work happens on a duplicate theme and a checkout profile you preview, and publishing is one switch, at a moment you choose. What can hurt you is finding out mid-migration that a script nobody documented was doing something at checkout. The mapping stage exists to find it early.
Yours, wherever one exists. Theme work without version control is how stores end up with a theme called final-final, so if you have a repo and a CLI workflow, we use them. If you don't, we set one up during the first engagement and hand it over. It stays yours afterwards.
More in Web & CMS.
Find out what your theme actually costs.
Send the store URL and the collection page that annoys you most. We'll have read the theme and timed a template before we speak.