Shopify technical audit for code, apps and performance

Reading the theme like its next maintainer

Automated scores tell you that something is slow. They rarely tell you why, or what it will cost to fix. So we download a copy of your theme and read it the way a developer inheriting it would. Which sections are really used? Is product logic repeated in five places, so a change to one breaks the others? Is content baked into templates where your team cannot edit it? Are there customizations that will stop you applying the theme vendor’s next update?

Shopify Theme Check catches syntax and common performance mistakes, and we run it on every audit. The judgment calls are human ones: how hard each template is to change safely, where the fragile parts sit, and which problems are worth fixing now versus living with until a larger rebuild.

Putting a cost on every app

Apps are where most stores lose speed without noticing. Each one can add scripts, styles and network requests, sometimes on every page even when its feature appears on one. Apps that were uninstalled can leave snippets and script tags behind that keep loading for years.

We list every app, what it adds and where, and measure its effect by comparing pages on a duplicate theme with and without it. That turns a vague feeling that apps slow things down into a specific list: this reviews widget costs this much on product pages, these two apps do the same job, this script belongs to a tool you stopped paying for. Each app gets a keep, configure, replace or remove recommendation.

Following an order from click to warehouse

Many of the costliest problems sit between systems rather than in the theme. We follow a test order from the first page view through cart, checkout and confirmation, then into your ERP, warehouse, email platform and analytics. Along the way we check that each event fires once, that stock updates in the right direction and that webhooks failing at night do not go unnoticed until morning.

We also look at the versions of Shopify’s APIs your custom apps and integrations call. Shopify releases API versions on a regular schedule and retires old ones, so an integration nobody has touched in a while can be closer to breaking than anyone realizes.

Fix, refactor or rebuild

One of the most useful outcomes is an honest answer to a hard question: is this theme worth keeping? Many stores only need targeted fixes, such as removing unused apps, deferring heavy scripts and cleaning up a handful of templates. Others have code so tangled that every change takes longer than it should, and patching it costs more over a year than starting again.

We give you our view and the reasons behind it. If targeted fixes are enough, the roadmap shows the order to tackle them. If a refactor or a rebuild on a modern Online Store 2.0 theme makes more sense, we explain what you would gain, what carries over, such as products, metafields and content, and what would need to be rebuilt.

• Targeted fixes when the foundation is sound
• A refactor plan when key templates need rework
• A rebuild case when maintenance cost outweighs the theme

Diagnosing Core Web Vitals, not just scoring them

A single lab test is a snapshot from one simulated device. Google’s Core Web Vitals assessment is based on field data from real Chrome users, so a store can pass a lab test and still fail where it counts. Where your store has enough traffic to appear in the Chrome UX Report, we start from that field data, then use lab tools to explain it.

Each metric points to a different kind of cause. Slow largest contentful paint usually comes from the hero image, render-blocking files or fonts. Poor interaction to next paint usually comes from heavy JavaScript, often from apps, running when a shopper taps a variant or opens a menu. Layout shift often comes from app widgets, banners or images without fixed sizes that appear after the page has drawn. We name the element and the file behind each problem, so the fix is specific.

Judging theme code quality

Healthy theme code has a few recognizable traits. Logic lives in reusable snippets rather than being copied between templates. Content and settings are editable in the theme editor or held in metafields and metaobjects, not typed into Liquid. Sections load only the assets they need. Custom work is kept apart from vendor code, so the theme can still be updated.

We look for the opposite: product logic repeated in several places, large inline scripts, assets loaded on every page for one section, and edits scattered through vendor files. Each pattern is listed with the files involved, so a developer can see exactly where the fragile parts sit.

Measuring app bloat and script cost

Theme app extensions and app embeds are the current way for apps to add features to a theme, and they can be switched off in the theme editor. Older apps may still inject code directly into theme files or add script tags. We note which method each app uses, because it changes how safely it can be removed and how much it costs on pages where it does nothing.

Reviewing checkout and Shopify Functions

Shopify has moved checkout customization to checkout extensibility, with checkout UI extensions for the interface and Shopify Functions for logic such as discounts, payment and delivery options. For Plus stores we check whether any legacy checkout.liquid edits or Shopify Scripts are still in use, what they do and how each one maps to the current tools.

Where Functions or checkout extensions are already in place, we review how they behave with your discount stack, markets and payment methods, and whether more than one app is trying to control the same part of checkout. On any plan, we check the thank you and order status pages, where tracking and post-purchase apps often overlap.

Mapping integrations and data flow

For each connected system we record which way data moves, what triggers it, which system is the source of truth for stock, prices and customers, and what happens when a sync fails. Many problems come from two systems both believing they own the same field, so we look for that conflict specifically.

Checking security hygiene

Shopify secures the platform, but access to your store is yours to manage. We review staff and collaborator accounts against current team members, check whether two-step authentication is required for staff, and compare the permissions of each account and app with what it needs. Custom apps and their API access scopes get the same review, along with any tokens shared with outside services.

We also look at third-party scripts on the storefront and pixels set up through customer events, because each one can see what shoppers do. Anything without a clear owner or purpose is flagged for removal.

• Accounts for people who have left
• Apps and tokens with broader access than they need
• Scripts nobody can identify