Core Web Vitals after every app you installed

Core Web Vitals are usually discussed as a single score, and apps are usually discussed as a single category of problem. Both simplifications destroy the information you need.

The targets are specific: Largest Contentful Paint should occur within 2.5 seconds, Interaction to Next Paint should be 200 milliseconds or less, and Cumulative Layout Shift should be 0.1 or less — measured at the 75th percentile of page loads and segmented by device type. Three different numbers, describing three different experiences, damaged by three different app behaviours.

LCP is a bandwidth and discovery problem. The largest element in the viewport is usually a hero or product image, and it is late either because the browser found out about it late or because something else was using the connection. An app does not have to be on the critical path to hurt LCP; it only has to be competing for the same first second.

INP is a main-thread problem. It measures the delay between a user interacting and the next frame being painted. Any script doing work when the user taps — an analytics handler, a personalisation check, an overlay listener — adds to it. This is the metric app-heavy stores fail most often, and it is also the newest: INP became a stable Core Web Vital in 2024, replacing First Input Delay. Stores that had comfortable FID scores for years were not fast; they were being measured on something easier.

CLS is an injection problem. Content that arrives after paint and pushes existing content down. Almost every app that adds a visible element to a page you did not reserve space for contributes to it.

Once you have separated them, the question stops being "which app should we remove" and becomes "which metric is failing, and which app behaviour matches that failure". That question has an answer.

You cannot reason about the cost without knowing the mechanism, and on a modern Shopify theme the mechanism is the theme app extension.

Two block types matter here. App blocks are placed by a merchant inside a section, so they render where the merchant put them. App embed blocks are different: Shopify documents that they render immediately before the closing </head> and </body> tags, with the compliance_head target rendering first for cookie consent purposes.

Read that position carefully, because it is the whole story for head-injected apps. Anything an app embed block puts before </head> is in front of every byte of your page content, on every page of the store. Shopify’s platform work — streaming HTML responses so the browser parses while the server renders, Early Hints to start critical downloads sooner — is specifically designed to get the page started early, and a synchronous third-party script in the head undoes a measurable part of that benefit.

The compliance_head detail is worth sitting with. Your cookie consent app renders before everything else, by design. On many stores it is therefore the first script to execute, the thing a user must interact with before doing anything else, and frequently the largest element in the viewport while it is open. That makes it simultaneously an LCP candidate, an INP path and a CLS source. It is a legal requirement and a performance decision, and most stores have only evaluated it as the former.

One more piece of platform detail that cuts the other way: Shopify runs web pixels in a sandbox — a strict sandbox for app pixels and a lax one for custom pixels — where access to cookies, localStorage and sessionStorage goes through a browser API that executes asynchronously in the top frame rather than synchronously in your document. Tracking code delivered as a pixel is genuinely not the main-thread problem that a tag pasted into theme.liquid was. If you are still carrying analytics as a theme snippet, moving it is one of the few changes that reduces cost without reducing capability.

LCP problems on app-heavy stores are usually not caused by the app rendering anything. They are caused by four or five requests starting before the hero image does.

Shopify’s own theme guidance is direct about the two ends of this. Critical resources should load above {{ content_for_header }} so the browser can fetch them while Liquid renders the sections; non-critical ones take defer or async. Images in the initial viewport should never carry loading="lazy", and the LCP candidate should be marked fetchpriority="high". And preload should be reserved for the one or two resources the browser genuinely discovers late — used liberally it competes with the browser’s own prioritisation and makes things worse.

Against that baseline, the app fix is usually deferral rather than removal. A reviews widget below the fold has no business loading before the hero image. A personalisation script that decides what a returning visitor sees has to run early by definition, and that one is a real trade you should price rather than optimise away.

The single most common finding is also the most embarrassing to report: Shopify’s guidance to remove A/B test anti-flicker snippets when no tests are running exists because stores routinely leave them in place for months after the last experiment ended. An anti-flicker snippet deliberately hides the page until the testing script responds. If no test is running, you are paying the full cost of that hiding for no result at all.

INP is where app accumulation shows up most honestly, because it measures the thing users actually complain about — the tap that does nothing for a moment.

The pattern to look for is not one heavy script but several small ones attached to the same events. Four apps each adding a modest listener to every click is not four times a small cost; it is a main thread that has to finish four pieces of work before the next frame can paint, on a mid-range phone that is already the slowest device in your audience.

Three questions separate the fixable from the structural. Does the script need to run before the interaction, or is it reacting to it — a recommendation engine computing on page load versus one computing when a drawer opens. Does it need to run at all on this template, or is it an app embed running site-wide to serve one page type. And is the work it does proportional to the value it returns, which is a commercial question wearing a technical costume.

The practical lever most stores have not pulled is scope. An app embed block is site-wide by construction; a lot of the functionality merchants buy is needed on one template. Getting an app to load only where it earns its place typically requires either an app that supports it or a developer, which is exactly why it does not happen by default.

Installing an app to fix performance. The contradiction is on the label. There are narrow exceptions — an image optimisation service that replaces work you are doing badly — but the measurable win available to most stores is deletion.

Optimising for the Lighthouse number. Shopify requires an average Lighthouse score of 60 across home, product and collection pages for Theme Store acceptance, which tells you what kind of instrument it is: a floor for distribution, not a measure of how your customers experience the store. Core Web Vitals field data at the 75th percentile is the number worth managing.

Removing an app that demonstrably earns money because it is heavy. This is the honest limit of performance work. If a reviews widget adds 300 ms of INP and a measurable amount of revenue, the answer is to make it cheaper — defer it, scope it to the templates that need it, reserve its space so it does not shift the layout — not to delete it and call the resulting score an improvement.

The uncomfortable summary is that most app-related performance debt was not decided. It accumulated one install at a time, each of which was individually reasonable, and several of which activated an embed block on every page of the store without anyone experiencing that as a decision. An annual audit of what is actually attached to your theme costs a day and is the highest-return performance work most stores are not doing.

• Shopify speed optimisation
• Theme app extensions: apps that do not touch your code
• Upsell and cross-sell without slowing the page