Shopify Page Speed and Conversion: What to Fix First

Quick answer: Fix what shoppers feel, on the pages where they decide to buy, using data from real visitors (field data) rather than a lab score. Start with your mobile product pages in Shopify’s Web performance reports or Google Search Console, and compare them with Google’s “good” targets at the 75th percentile: LCP 2.5 seconds or less, INP 200 milliseconds or less and CLS 0.1 or less (as at 31 October 2026). Fix the failing metric on your busiest template first. If all three are already good, speed is probably not your biggest conversion leak.

Speed advice for Shopify stores usually arrives as a score and a scare. You run PageSpeed Insights, see a red number, and somebody tells you every second is costing you sales. Then an app vendor offers to fix it for a monthly fee.

This post is the hub for speed on this blog. It covers whether speed is a problem for your store at all, which pages and which measure to look at first, what tends to cause each problem on Shopify, and how to tell whether your fix changed anything. It sticks to diagnosis and thresholds. What your apps cost has its own post: the Shopify app audit.

You will not find an “every second costs you X%” rule here. The best-known speed study does not support one, and I explain why below.

Start here: is speed actually your problem?

There are two kinds of speed data, and mixing them up is the most common mistake.

• Field data is what real visitors’ browsers recorded while using your store. Google collects it in the Chrome User Experience Report (CrUX).
• Lab data is one simulated page load on one device and one network setting, for example the Lighthouse test behind the PageSpeed Insights score.

Google’s guidance is clear on which one decides priorities. Its web.dev article on lab and field differences says field data is what you should use to prioritise your efforts, and lab data is for debugging and for testing changes. Its Core Web Vitals guide describes the three measures as, first and foremost, field metrics.

So before you touch anything, look at field data in one of three places.

1. Shopify’s Web performance reports. Shopify’s help centre says the summary sits on the Themes page under Online Store in your admin, and the full reports are under Analytics, then Reports (you need the Reports staff permission). They show LCP, INP and CLS from real visitors, rated Good, Moderate or Poor. They also have Page Type reports, which show whether certain page templates are the problem, and Page URL reports for individual pages. Shopify says the data can be delayed by up to 36 hours, covers the last 90 days, and that stores in private mode (and new stores) might not have metrics. Shopify’s overview page says the summary score combines your home page, most visited product page and most visited collection page, and its two help pages describe the window differently (7 days on one, 30 on the other), so check the date range your admin shows.

2. The Core Web Vitals report in Google Search Console. It uses CrUX data, splits mobile and desktop, groups pages that have a similar experience, and gives each group the status of its worst metric. It looks at the last 28 days.

3. The top section of PageSpeed Insights. The real-user part is CrUX data for the previous 28 days. If your page does not have enough data, PageSpeed Insights falls back to data for your whole site, and if that is missing too, it shows none. Google says a page or site is only included in CrUX if it is publicly discoverable and has enough visitors to make the data statistically meaningful, so a small store can have gaps.

A page passes the Core Web Vitals assessment in PageSpeed Insights if the 75th percentile of all three metrics is Good (if there is not enough INP data, PageSpeed Insights judges the pass on LCP and CLS alone). The 75th percentile means three-quarters of visits are at or better than that value.

The decision rule. If your mobile product and collection pages are Good on all three, speed is not your first conversion lever, and the rest of this post is for later. Shopify’s own enterprise blog (27 April 2026) says nearly 80% of Shopify stores pass all the thresholds, citing Chrome UX data; that is Shopify’s figure, not an audited one, but it fits the point that passing is common. If one or more is not Good on a template that carries a lot of mobile traffic, keep reading. If you have no field data at all (a new store, private mode or low traffic can all cause that), use a lab test (below) to catch obvious problems and fix the basics Shopify lists. At low traffic you will also struggle to prove an effect on conversion rate.

What shoppers feel: the three measures in plain words

Core Web Vitals are three measures of what a visitor experiences. Interaction to Next Paint (INP) replaced First Input Delay in March 2024, so older guides that mention FID are out of date. These are Google’s thresholds as at 31 October 2026, measured at the 75th percentile and segmented by mobile and desktop.

Two details save confusion. Shopify’s reports show LCP and INP in milliseconds, so 2.5 seconds appears as 2,500. And INP counts clicks, taps and key presses, not scrolling or hovering. Google’s CLS definition counts a layout shift when a visible element changes position between rendered frames, and shifts that happen within 500 milliseconds of a tap or click are flagged so they can be left out.

What the Deloitte and Google study says, and what it does not

Many speed articles quote the same piece of research. It is called Milliseconds Make Millions. Google commissioned it, Deloitte Ireland prepared the report, and the agency Fifty-Five collected the data. Deloitte lists it as published on 24 March 2020. I read the full report, and here is what it covers.

• The data: mobile sites for 37 brands in retail, travel, luxury and lead generation, mostly in Europe and the US, over four weeks from 28 October to 24 November 2019, about 30 million sessions in all. The retail group was 15 brands and 20.5 million sessions.
• The change: a 0.1 second improvement in each of four speed measures (max server latency, first meaningful paint, estimated input latency and observed load). The web.dev summary of the study says every page in the user journey had to improve on all four for the effects to show.
• The retail result: user transactions rose 8.4% and average order value rose 9.2%, with 0.1 seconds of improvement across those four measures (Deloitte and Google, retail, mobile, late 2019).

The part most articles skip is where in the journey it showed up.

The report says retail visitors were most sensitive to speed before checkout, and that in retail it is often more important to focus on product page load times than on the homepage. Its reasoning is that people who land straight on a product page may have come from an ad click while comparing sites, so it is easy for them to leave for a competitor. That is useful for deciding where to start.

Now the limits, which matter more than the headline.

• It is correlation, not a controlled test. The report says site speed changes happened naturally and were not created by anyone. Deloitte also says it did not audit or validate the data, and that the results are based solely on the 37 brands and may not reflect other sites.
• It is mobile only, from 2019. The authors say desktop results contained a lot of contradicting parameters.
• It was measured in Lighthouse, a lab tool. The report says so in its limitations.
• It left out results that did not show an effect. The disclaimer says that where speed had minimal or zero effect, those observations were not included.
• It is not universal. In the lead generation group, conversion rates on mobile and desktop decreased when speed improved.
• It is not a forecast for your store. The retail figure is a modelled relationship across brands, based on a change in four measures on every page of the journey. One image fix on one page is not that.

Use the study for direction (speed matters most where people decide to buy, and product pages are a good place to start), not for arithmetic. If anyone promises a conversion uplift from speed work, ask for the source, the category, the date and the method. This study has all four, and it still does not make that promise.

The triage: where to start, in order

Step 1: List your templates and rank them

Write down the page types your visitors land on: home page, collection pages, product pages, blog posts, and any landing pages your ads or emails use. In GA4 or Shopify, find how many mobile sessions land on each. Rank them by traffic and by how close they are to a purchase. Following the Deloitte retail pattern, product and collection pages come before the home page.

If you buy traffic from Meta or Google, check where those clicks land. A product page that loads late wastes part of the click you paid for. (Prism3 does not run ads or email, so this is a note about your numbers, not a pitch.)

Step 2: Read the field data for each template and device

Use the Page Type reports in Shopify, the URL groups in Search Console, or PageSpeed Insights for a single URL. Look at mobile first. If mobile and desktop differ a lot, our guide to mobile conversion on Shopify covers the gap.

Step 3: Pick the failing measure

Take the template with the most mobile traffic and find the measure that is Poor, then the one that Needs improvement. Work on one measure per template at a time. Search Console gives a group the status of its worst metric, so a group can look red because of one measure while the other two are fine.

Step 4: Find the cause for that measure

This is where lab tools earn their keep. Field data tells you which template and which measure; a lab test on that exact page tells you why. The next three sections cover each measure.

Step 5: Change one thing, log the date, then wait for the data

If you change five things on the same day, you will not know which one helped or which one broke something. Keep a log: date, template, what changed, which measure it should move. Field data lags: Search Console and PageSpeed Insights use a 28-day window, Shopify’s reports can be up to 36 hours behind, and Search Console’s fix validation runs a 28-day monitoring session. Read the result a month later, not the next morning.

A worked example (illustrative numbers)

These numbers are made up to show the method, not taken from a real store. Say mobile field data at the 75th percentile looks like this.

The product page comes first because it has the biggest share of mobile traffic and sits next to the buy button, where the Deloitte retail data showed the strongest effect. The home page comes last despite a failing score, because it is further from the purchase and carries less traffic. A single score for the whole site would have hidden all of this.

Fixing LCP on a product page

LCP is the time until the largest visible element has finished rendering. Google lists images, video poster images, elements with a CSS background image and large blocks of text as candidates. On a product page the largest element is often the main product image, but check rather than assume. PageSpeed Insights, Chrome DevTools or WebPageTest can tell you which element it is.

Once you know the element, Google’s optimisation guide splits LCP into four parts. The guideline shares of the total are roughly:

• Time to first byte (TTFB): about 40% of the total.
• Resource load delay (the gap before the browser starts fetching the image): under 10%.
• Resource load duration (downloading the image): about 40%.
• Element render delay (image downloaded, not yet shown): under 10%.

Google calls these guidelines and says the parts only mean something relative to each other. The useful move is to measure your four parts and see which one is out of proportion, then fix in the order Google suggests: load delay, then render delay, then load duration, then TTFB.

Here is how that translates to a Shopify theme, using Shopify’s developer documentation on theme performance.

• A big load delay means the browser found the image late. Common causes: the image is lazy-loaded (Shopify says to apply loading="lazy" only to images outside the initial viewport, never to the LCP image), it is a CSS background image (Shopify says to use a real img element so the browser can find it early), or it is injected by JavaScript (Shopify says to render essential content in Liquid and HTML). Shopify also says to set fetchpriority="high" on the LCP image.
• A big render delay means the image arrived but is not shown. Shopify warns that fade-in and reveal animations can delay LCP even after the image has downloaded, and that a large dialog or pop-up can itself become the LCP element. Render-blocking scripts and styles can also hold things up.
• A big load duration means the file is too heavy for a phone. Shopify recommends srcset and sizes with its image_tag filter so each device gets an appropriately sized file, and its help centre says to size images to their display dimensions.
• A big TTFB means the server response is slow. Fix this last. On Shopify the page is built by your theme’s Liquid code, and Shopify points developers to its Theme Inspector for Chrome to find slow Liquid.

For the hero-image version of this fix, see the Shopify LCP hero image fix.

Fixing layout shift (CLS)

A shift is the thing a shopper notices when the button they were about to tap moves. Google’s guide to optimising CLS lists the same handful of causes, and Shopify’s documentation maps them onto themes and apps.

• Images without dimensions. Google says to always include width and height attributes on images and video, or reserve the space with CSS aspect-ratio. Shopify says image_tag adds the dimensions automatically.
• App content that loads late. Reviews widgets, bundle builders, badges and banners that appear after the page has laid out will push things around. Shopify says to reserve space for app-injected content with App Blocks and a min-height. Google adds that late-loading content near the top of the page causes larger shifts than content further down.
• Web fonts swapping in. Shopify says web fonts cause layout shift when they swap in, and suggests self-hosting fonts on the Shopify CDN and using fallback-font size adjustments (size-adjust and metric overrides) so the swap barely moves anything.
• Animations that move layout. Google says animating properties like top and left causes shifts, and that composited transform animations do not count towards CLS.

To find the offender, open the page in Chrome DevTools, record a load in the Performance panel and look at the Layout shifts track. Hovering over a shift highlights the element that moved, and clicking it shows the details, including possible causes.

Fixing slow taps (INP)

INP is the measure most Shopify owners have not heard of, and it needs a real tap, so it is hard to find in a lab. Google’s guide says an interaction has three parts: input delay (the page is busy when you tap), processing time (your code runs) and presentation delay (the screen updates). Shopify’s documentation says JavaScript runs on the main thread, competing with rendering and input handling, and calls too much or badly timed JavaScript one of the primary causes of poor INP.

On a store, the taps that matter are the variant picker, add to cart, the cart drawer, filters and sorting, the menu, and anything in a quick-view pop-up. Try them on a real phone, and try them while the page is still loading, because input delay is the time a tap waits for a busy main thread. Google’s INP guide says to start with field data to find the slow interaction type and use the lab to reproduce it.

What to look for, drawing on Shopify and Google’s guidance:

• Scripts you added. Shopify says to audit all scripts, including apps and tracking pixels, and to remove any that is not earning its performance cost. It also says uninstalling an app does not automatically remove its code from your theme, so leftovers are common.
• Heavy event handlers. Google’s advice is to break up long work and yield to the main thread so the screen can update first.
• Big page structure. Google lists large DOMs and lots of HTML built in JavaScript as causes. Shopify says many sections on a page can lower performance, and suggests building hidden components such as drawers and filter panels only when first opened.
• Anti-flicker snippets. Shopify says to remove A/B test anti-flicker snippets when no tests are running.

One caution of mine, not a Shopify rule: do not rip out tracking scripts in a rush. If you remove a pixel, check what it was feeding. Our guide to GA4 versus Shopify Analytics explains why your numbers need to agree before you start cutting.

Deciding which app or script is worth its cost is a separate exercise, and the answer is in the Shopify app audit.

What lab scores are good for

A PageSpeed Insights Performance score of 90 or above is rated good by Google’s tool. That is a lab number from one simulated load. It is useful for finding the cause once field data has shown you the template and measure, for comparing two versions of the same page under identical conditions (the Deloitte study measured speed this way, using Lighthouse), and for spotting problems before release.

It is poor at telling you what your visitors experienced, because they differ in devices, networks, cache state and what they tap. Google says lab tests cannot accurately predict when users will choose to interact, so INP in particular is hard to judge from a lab test alone.

Shopify’s documentation also tells developers to avoid “fake performance apps” that game Lighthouse, for example by injecting transparent elements or serving different pages to crawlers. A higher score from a trick does nothing for the visitor on a phone. And a perfect score is not the goal: Shopify’s overview says to focus on your specific business needs rather than the highest possible score.

How to tell whether speed work changed conversion

Field data tells you whether the page got faster for visitors. It does not tell you whether more of them bought. For that you need a before and after check on conversion, and some care.

1. Pick the right comparison. Compare mobile conversion rate, for sessions that landed on the template you changed, for a period before and after. Use equal lengths of time, ideally whole weeks. A 28-day window on each side lines up with the 28-day field data window.
2. Keep the rest still. The Deloitte study’s own audit checked brands for promotions, redesigns and A/B tests during its data window, because they would muddy the result. Do the same: avoid sale periods, price changes, new themes and new campaigns in either window. If you cannot, say so when you read the result.
3. Read small changes with suspicion. If your store has few orders a week, normal ups and downs can be bigger than any speed effect. Our guide to Shopify conversion rate explains how to set a baseline, and it is worth having before you start.
4. Check the tracking first. If GA4 and Shopify disagree on orders, your before and after is built on sand.
5. Don’t claim the whole result. If conversion rose after a speed fix, speed may be part of it, but you will rarely be able to say how much.

When speed is not the problem

If your field data is Good on your busiest templates, stop. Your conversion problem is somewhere else, and more speed work will not find it. Look instead at the product page CRO checklist (what a shopper needs before adding to cart), the collection page CRO checklist (how they find the product), the mobile conversion gap if desktop converts and mobile does not, or a full CRO audit, which looks at the whole path.

Rank any fix you find on one scale, so speed work competes fairly with everything else. In a CRO audit we score fixes with PIE (potential, importance and ease), so a slow image and a missing delivery message are judged the same way.

A note on SEO, because the two topics get tangled. Google says Core Web Vitals are used by its ranking systems and recommends good scores, but also says there is no single page experience signal, that search will show relevant content even when the page experience is sub-par, and that good scores do not guarantee a top ranking. Fix speed for shoppers first. For the wider picture, see the Shopify SEO guide.

Key takeaways

• Decide with field data (real visitors), not a PageSpeed lab score. Look in Shopify’s Web performance reports, Search Console or the top of PageSpeed Insights.
• Google’s good targets, at the 75th percentile and as at 31 October 2026: LCP 2.5 seconds or less, INP 200 milliseconds or less, CLS 0.1 or less. INP replaced FID in March 2024.
• Rank your templates by mobile traffic and distance from the buy button. Product pages come before the home page.
• The Deloitte and Google study (15 retail brands, mobile, late 2019) found an 8.4% rise in transactions with a 0.1 second improvement in four speed measures, but it is a correlation, not a promise or a forecast for your store.
• Fix one failing measure on one template at a time. Look first at how the LCP image loads, at missing dimensions and late-loading app content for CLS, and at JavaScript and scripts for INP.
• Field data lags by up to a month. Check conversion before and after with the rest of the store held still.
• If your busiest templates are already Good, speed is not your first conversion fix.

FAQs

What is a good page speed for a Shopify store?

Google’s “good” targets, at the 75th percentile of real visits and as at 31 October 2026, are LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less. Shopify’s Web performance reports use the same thresholds, rating results Good, Moderate or Poor. These are Google’s targets, not a guarantee of any result.

Does page speed affect Shopify conversion rate?

There is evidence that it can. The Google and Deloitte study Milliseconds Make Millions (mobile data from late 2019) found that retail conversions rose 8.4% with a 0.1 second improvement across four speed measures. It was observational, covered 37 brands, left out results with no effect and found the opposite for lead generation sites, so treat it as a reason to check your own numbers, not a forecast.

Which Core Web Vital should I fix first?

The one that is failing, on the template with the most mobile traffic. If several fail, I would start with LCP on product pages, because the shopper meets it first and the Deloitte retail data showed the strongest effect at the product page step. That is a judgement call, not a rule.

Do I need a PageSpeed Insights score of 90?

No. A score of 90 or above is Google’s “good” band for the lab Performance score, but the Core Web Vitals assessment uses real-visitor data at the 75th percentile. Google’s page experience documentation also says that trying to get a perfect score just for SEO reasons may not be the best use of your time.

Should I install a speed app?

Be careful. Shopify’s developer documentation warns against “fake performance apps” that game Lighthouse tests, such as injecting transparent elements or serving different pages to crawlers. Start by removing apps and scripts you do not need, and fixing images and layout. Remember that uninstalling an app does not always remove its code from your theme.

How long until Search Console shows my fix?

Search Console’s Core Web Vitals data uses the last 28 days, and its fix validation runs a 28-day monitoring session. Allow about a month, and do not read a single morning’s data as the result.

Is speed the leak, or is it something else?

The quickest way to find out is a free 30-minute diagnostic. We do not sell speed engineering; we show you whether speed is where your store loses buyers. Book a free 30-minute diagnostic or tell us about your store: we share your Shopify store on screen and name two or three conversion leaks live, and tell you whether they are worth fixing. No pitch. You can also read how our Shopify CRO service works first.