Fixing Core Web Vitals in Shopify

What you can and cannot change on Shopify

Shopify's CDN already serves images in modern formats such as WebP or AVIF to browsers that support them, and can resize them on request. That removes one common job. It does not stop a theme asking for an image that is far too wide, lazy-loading the hero, or loading ten app scripts before the page can respond.

The storefront pages that matter most are usually the home page, collection pages, product pages and the cart. Each is a separate template, so a fix to the product template improves every product page at once.

Finding where your store is slow

1. Field data first. Run one example of each key template through the Core Web Vitals checker and record mobile LCP, INP and CLS. Open the Core Web Vitals report in Search Console to see which URL groups fail. Shopify also shows a web performance report in the admin, based on real visits to your store, which is useful for spotting when a change made things worse.
2. Script inventory. Open a product page in Chrome, go to DevTools, Network, filter by JS and reload. Sort by domain. Anything not from your own store domain or cdn.shopify.com is usually an app or a tag. Note the size and the number of requests for each.
3. Main-thread cost. Record a page load in the Performance panel with CPU throttling on, then use the Bottom-Up tab grouped by domain to see which app scripts use the most processing time.
4. Interactions. Record yourself choosing a variant, adding to the cart and opening the cart drawer. Long tasks during those clicks explain a poor INP.

Apps: the usual main cause

Most Shopify apps that change the storefront add JavaScript and often CSS to every page, even pages where the app does nothing. Reviews, upsells, pop-ups, chat, loyalty schemes, currency switchers, wish lists and "speed booster" apps all compete for the same main thread.

App embeds

Apps built for Online Store 2.0 themes add their code through app embeds and app blocks. In the theme editor, open App embeds and switch off any embed you are not actively using. An embed that is switched off stops loading, even while the app stays installed.

Leftover code from removed apps

Older apps, and apps installed on older themes, often edited theme files directly or added scripts through the older script tag mechanism. Uninstalling the app does not always remove that code. Search the theme code for the app's name or domain in layout/theme.liquid, in the snippets folder and in section files. Remove references to apps you no longer have, after checking with the developer or testing on a duplicate theme.

Deciding what stays

• Remove apps that nobody can explain the purpose of, or that duplicate a feature your theme already has, such as a mega menu or product tabs.
• For each app you keep, check its settings for an option to load only on the templates where it is used.
• Prefer apps that render with app blocks in sections over apps that inject widgets with JavaScript after the page loads, because block-based output is part of the page and is less likely to cause layout shift.
• Be careful with speed optimisation apps. Some help, but some add their own scripts or lazy-load every image, including the hero, which harms LCP.

Hero images and fonts in Liquid

Many themes lazy-load every image, including the first one on the page. The fix is to load the first section's image eagerly with high priority, and lazy-load the rest. Liquid's section.index tells you where a section appears in the template, and the image_tag filter accepts HTML attributes as parameters.

{%- if section.index == 1 -%}
  {{ section.settings.image
    | image_url: width: 1800
    | image_tag:
      widths: '600, 900, 1200, 1800',
      sizes: '100vw',
      loading: 'eager',
      fetchpriority: 'high',
      alt: section.settings.image.alt }}
{%- else -%}
  {{ section.settings.image
    | image_url: width: 1800
    | image_tag:
      widths: '600, 900, 1200, 1800',
      sizes: '100vw',
      loading: 'lazy',
      alt: section.settings.image.alt }}
{%- endif -%}

image_tag writes the srcset and the width and height attributes for you, so small screens get small files and space is reserved for the image. Adjust sizes to match how wide the image really is at each screen size; 100vw is only right for full-width banners.

On product pages the LCP element is usually the first product image. Apply the same eager, high-priority treatment to the first media item in the product gallery and lazy-load the thumbnails and later images.

Fonts

{{ settings.type_header_font | font_url | preload_tag: as: 'font' }}
{% style %}
  {{ settings.type_header_font | font_face: font_display: 'swap' }}
  {{ settings.type_body_font | font_face: font_display: 'swap' }}
{% endstyle %}

Preload only the heading font used in the first screen, and keep font_display: 'swap' so text is visible straight away. The setting names above follow Shopify's free themes; yours may differ.

Tracking, pixels and consent

Analytics, advertising and marketing pixels are often pasted into theme.liquid over the years, sometimes several copies of the same one. Shopify's customer events feature lets you add custom pixels that run in a sandbox separate from the theme's page, and many marketing apps now connect through it. Moving tracking there, and removing the hard-coded copies from the theme, reduces the scripts competing with the storefront.

• Search theme.liquid for gtag, fbq, ttq and other pixel names, and list every copy.
• Check which of those are already sent through a sales channel app or customer events, and remove the duplicates from the theme.
• Use Shopify's consent settings so marketing and analytics pixels that need consent under UK GDPR and PECR do not run until the visitor has agreed. This is not legal advice, but it also means those scripts do not load for visitors who decline.

INP on Shopify: carts, variants and filters

Poor INP on Shopify usually comes from three interactions:

• Choosing a variant. Themes and apps may update the price, image, stock message, URL and several widgets in one long task. Update the visible price and button first, then defer the rest.
• Adding to the cart. Opening a cart drawer, refreshing the cart count and running upsell and analytics code all in one click creates a long task. Show the drawer opening immediately and let app code run after the next paint.
• Collection filters. Filters that rebuild the whole product grid on every tick of a checkbox are costly. Debounce the request so it waits until the visitor pauses, and use the Section Rendering API to fetch only the updated grid.

// Give the visitor feedback now, run the heavy work after the next frame
addButton.addEventListener('click', () => {
  addButton.setAttribute('aria-busy', 'true');
  cartDrawer.classList.add('is-open');
  requestAnimationFrame(() => setTimeout(() => addToCart(form), 0));
});

The general techniques for splitting up this kind of work are in the INP guide.

The fix, step by step

Keeping the store fast

• Test before installing. Before switching a new app on for the live theme, add its embeds or blocks to a duplicate theme where the app allows it, and measure the product page before and after.
• Review apps quarterly. Apps accumulate. Remove anything unused and check that uninstalled apps have not left code behind.
• Protect the first section. If editors can reorder sections, make sure whichever section renders first uses eager loading, which the section.index approach does automatically.
• Watch the admin report. Look at the web performance report after theme updates, new apps and seasonal campaigns, which often add banners and pop-ups.

For platform-specific detail on individual metrics, see layout shift in Shopify, Shopify image optimisation and JavaScript issues in Shopify.