What’s in our theme core, and how to check it.

Code, not a page builder

Every theme starts from our core: Liquid, CSS and JavaScript built up over eight years of building themes for the Shopify Theme Store, cut down to what a store needs. There’s no page builder and no template underneath. Your sections are theme sections, edited in Shopify’s own theme editor.

How to check: view the page source. You won’t find a page builder’s scripts or markup, and every section on the page appears in the theme editor.

Liquid that does the least work

Liquid runs on Shopify’s servers before the first byte reaches a shopper, on every page view that isn’t cached. Ours follows Shopify’s performance guidance to the letter:

• No loop over one list inside a loop over another (products times variants grows with your catalog).
• One pass over each list, with anything that doesn’t change inside a loop worked out before it.
• Only what’s drawn is fetched: a page’s product count comes from Shopify’s totals, never by loading the collection.
• Snippets go at most two levels deep, and the ones drawn for every product (the product card, its options) are written in at build time, so a grid renders no snippet per item.

How to check: the Shopify Theme Inspector for Chrome shows the server time of every file on a page. Time to first byte is in a PageSpeed Insights report.

Scripts load when they’re needed

• One small script bundle loads with the page, for what’s on the first screen.
• Every other part (a slideshow, the cart drawer, a quiz) has its own script, loaded the first time that part is on the page.
• What starts off screen isn’t in the page: the cart drawer and the search results load when someone reaches for them, and a pop-up waits, inert, until it’s shown.
• Updating part of a page (a variant picked, a product added, the next page of a collection) fetches only that section from Shopify, never the whole page, and the code that does it loads the first time it’s needed.
• A script watching for something to scroll into view stops watching once it has, and slides off screen are inert, so nothing works in the background on what nobody can see.
• Scripts never write styles. They set a state the CSS already knows (open, current, loading), so the browser does the least work to redraw.
• A slideshow pauses on hover only for a mouse. On a phone a tap would otherwise stop it for good.

How to check: in Chrome’s DevTools, the Network tab shows a page without a slideshow loading no slideshow script, and picking a variant fetching one section. The Coverage tab shows how little of each script goes unused.

Smooth on slow phones

Three in four shoppers arrive on a phone (Nosto, 2025), and the typical one is a $250 Android more than three times slower than a current iPhone (Alex Russell, 2026). A tenth of a second faster on mobile converted 8.4% more retail shoppers in Google and Deloitte’s study (web.dev). So we test on slow phones, not ours:

• We measure animations frame by frame, on a phone slowed down, and fix any frame that drops.
• Reveals, hovers and presses move only what the graphics chip can draw on its own (position, scale, fade), never what makes the browser lay the page out again.
• What’s on screen when the page loads doesn’t animate in, so nothing in the first view waits on a script.
• One watcher for the whole page decides what to reveal as it scrolls in, not one per element.
• A phone with little memory, or with data saver on, gets the lighter motion: no stagger, no parallax.
• Things that open and shut (a FAQ row, a filter) ease open in CSS, with no height measured by a script.
• Anyone whose device asks for less motion gets a short fade and nothing moving.

How to check: in Chrome’s DevTools, open Performance, slow the CPU down six times, and record a scroll down a page. The frames stay green, and the reveals show no layout work.

Images and drawing

• Every image comes in several widths with the sizes it’s shown at, so a phone downloads a phone-sized image.
• The first image on the page loads first, at high priority. The next section’s loads straight after. Everything else waits until it’s near the screen.
• Sections far down a page aren’t laid out or painted until they come near the screen.

How to check: a Lighthouse report flags a lazy-loaded largest image and images bigger than they’re shown. View source shows each image’s widths and sizes.

It works before the scripts do

Product options and “load more” are plain links first: picking a size goes to that variant’s page, and the script only makes it smoother.

How to check: turn JavaScript off in your browser and pick a product option.

Shopify’s own standards

• Shopify’s standard storefront events and cart actions, so apps and analytics hook in without extra code, and an app can open or update our cart in place.
• Built to the standards Shopify’s theme review asks of every theme in its store, and checked with Shopify’s Theme Check.

Accessible

• Every color pair in your brand measured against WCAG 2.2 AA contrast (4.5:1 for text, 3:1 for controls).
• One visible focus ring on everything, and a skip link first on every page.
• Dialogs that close on Escape and give focus back where it was.
• Tap targets of at least 48px on phones.
• For anyone who asks their device for less motion, nothing moves on its own.

How to check: move through a page with the Tab key alone, and run Lighthouse’s accessibility audit or axe.

Ready for AI tools

The theme comes with the two files Shopify reads at a theme’s root, AGENTS.md and DESIGN.md. Shopify’s own AI assistant, Sidekick, reads both before it changes your theme, and so do Codex, Cursor, Copilot, Claude Code and most coding agents. Shopify keeps them with the theme, so they travel with every pull, push and GitHub sync. AGENTS.md says how the theme is built:

• Whose files are whose: which files are yours (templates/*.json, the section groups, config/settings_data.json, your own stylesheet) and which are our core’s, so a core update merges without a conflict.
• The commands: shopify theme dev for a live preview, and shopify theme check (or the Shopify Dev MCP’s validate_theme) before anything is pushed, to an unpublished theme first.
• The rules an edit keeps: a look is a setting, never a value written into the markup; every section renders through one shell snippet; a script loads only when the page uses it; the built stylesheet is never edited, and your own styles go in a file of your own; and the contrast, focus, tap-target and motion rules above.
• The trap: pull before changing anything. A push overwrites the JSON templates and settings_data.json, which undoes whatever was changed in the theme editor since the last pull.

DESIGN.md says how your store looks and why: your brand’s feel, the direction you picked, your colors and fonts by role, your logo and voice rules and what the brand never does, then every look setting with its value. A tool changes the setting, not a hex value in the CSS. The theme editor’s values win: before each push we rewrite the settings part from them, and keep the rest as you, your team or Sidekick left it.

How to check: both are at the top of the theme’s code, in its repository and in Shopify’s code editor.

What we can’t promise

• Apps load their own code, and some of it is slow. We go through yours before the build and tell you what each one costs.
• Video, large media and third-party scripts weigh what they weigh, on any theme.
• Real-visitor numbers depend on your visitors’ phones and connections, and take about four weeks to catch up after launch.
• An AI tool’s change can still be wrong. The files start it from the theme’s rules and Theme Check catches a broken one, but someone should look at the change before it goes live.
• We don’t promise search rankings or a conversion rate. We measure your store before and after launch, and show you both.

Related: New Shopify theme, Shopify speed.