Shopify Speed & Performance Optimization
≤2.5s
LCP target
≤200ms
INP target
$150/hr
Our rate, published
On Shopify you do not control hosting, the CDN, or checkout. That narrows the work to a specific set of levers — theme code, app payload, images, fonts and third-party tags — and it makes the job more tractable than it is on most platforms. This page sets out exactly which levers exist and which ones move the numbers Google actually measures.
What to expect
≤2.5s
LCP target — Largest Contentful Paint
≤200ms
INP target — Interaction to Next Paint
≤0.1
CLS target — Cumulative Layout Shift
p75 field
Measured at — real users, 28-day window
$150/hr
Our rate — published, not on request
The current Core Web Vitals thresholds
Google's thresholds are LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1, each measured at the 75th percentile of real Chrome user data. Claims circulating in 2026 that Google lowered the LCP threshold to 2.0 seconds do not trace to any Google source — the documented figure is still 2.5 seconds.
Two pieces of misinformation are being repeated widely enough to be worth naming. The first is that a March 2026 update tightened LCP to 2.0 seconds; Google's own documentation still says 2.5. The second is that INP was promoted to an equally weighted signal in 2026; INP has carried equal weight since it replaced First Input Delay in March 2024. If a guide still lists FID at all, it is at least two years out of date.
| Metric | Good | Needs work | Poor |
|---|---|---|---|
| LCP — loading | ≤ 2.5s | 2.5s – 4s | > 4s |
| INP — responsiveness | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS — visual stability | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
A page passes a metric only when at least 75% of real page views hit the good threshold. Google reads this from the Chrome User Experience Report at URL level, falling back to URL group or origin level where there is not enough data.
Why your Shopify speed score isn't the number that counts
Shopify's online store speed score and a Lighthouse run are both lab tests on simulated hardware. Core Web Vitals are field data from real Chrome users at the 75th percentile over a rolling 28-day window. A store can score well in Lighthouse and still fail Core Web Vitals, because a quarter of real visitors are on mid-range phones and imperfect connections.
This is the single most common source of confusion we encounter. A merchant sees a respectable speed score in the Shopify admin, cannot understand why Search Console reports failures, and concludes the reports are wrong. They are measuring different things.
Both tools have their place. Lab tests are how you diagnose and iterate, because they are repeatable and immediate. Field data is how you are graded. We optimise against the lab and verify against the field, and we do not report a fix as complete until field data moves.
Which means fixes take weeks to confirm
CrUX runs on a 28-day rolling window. Deploy a genuine improvement today and the field data will not fully reflect it for about a month. Any agency reporting a Core Web Vitals win the week after a deploy is showing you lab numbers and calling them results.
What you control on Shopify, and what you don't
Performance advice written for WordPress or custom builds is largely irrelevant here, because half of it addresses infrastructure Shopify owns. Knowing the boundary saves money.
| Layer | Who controls it | Worth spending on? |
|---|---|---|
| Hosting, CDN, server response | Shopify | No — not yours to change |
| Checkout performance | Shopify | No — and it is already fast |
| Theme code and render path | You | Yes — the core of the work |
| App payload and script tags | You | Yes — usually the biggest single lever |
| Third-party tags and pixels | You | Yes — commonly the worst offender |
| Images and video | You | Yes — highest impact on LCP |
| Fonts | You | Yes — cheap and quick |
| Liquid loops and section structure | You | Yes — matters on collection pages |
| Number of products rendered per page | You | Yes — a merchandising decision with a performance cost |
The practical consequence is that a Shopify performance engagement is narrower and more predictable than the equivalent on a self-hosted platform. There is no hosting migration to argue about and no server tuning to bill for. There is theme code, there is payload, and there is discipline.
The app audit usually beats the code work
On most slow Shopify stores the largest single performance gain comes from removing apps, not from optimising code. Each installed app can inject its own JavaScript, CSS and storefront assets, and that payload executes on every page load whether the feature is used or not. Auditing the app stack is the first thing we do and frequently the cheapest fix available.
A typical mid-market store carries apps nobody has evaluated in two years: a review widget, a popup tool, an upsell app, a loyalty script, two analytics tags doing the same job, and a chat widget loading a framework of its own. Individually each is defensible. Collectively they are the reason INP fails.
What the audit produces
- Every app listed with its actual storefront payload measured, not its marketing claim
- Apps loading on pages where their feature does not appear — a common and easily fixed waste
- Duplicate functionality across apps, especially analytics and reviews
- Leftover script tags from apps uninstalled months ago that never cleaned up after themselves
- Candidates for consolidation into a single custom app or theme code
- A ranked list: what to remove, what to defer, what to replace, what to keep
Where several apps can collapse into one purpose-built app, that is often both faster and cheaper to run — see Shopify app development for how we scope that.
Which metric fails on which Shopify page
Failures are predictable by template. Knowing the pattern tells you where to look before you measure.
| Template | Usual failure | Why |
|---|---|---|
| Homepage | LCP | Oversized hero image or video, often uncompressed and eagerly loaded above the fold |
| Collection pages | CLS and LCP | Dynamic product grids, lazy-loaded cards without reserved space, filter UI arriving late |
| Product pages | CLS and INP | Image galleries shifting on load, variant pickers and upsell widgets running heavy JavaScript |
| Filtered collection views | INP | Filter interactions blocking the main thread while the grid re-renders |
| Blog and content pages | LCP | Large inline images without dimensions or modern formats |
| Cart | INP | Cart drawers, upsell logic and quantity updates all firing on the same interaction |
INP is the metric most sites fail — reported at roughly 43% of sites missing the 200 millisecond threshold — and it is the hardest to fix, because it requires changing how JavaScript is structured rather than compressing an asset. Long tasks have to be broken up, non-critical work deferred, and the main thread given room to respond.
What we do
Field-data audit first
We start with Search Console and CrUX rather than a Lighthouse screenshot, so the work targets what real users experience. Lighthouse comes second, as a diagnostic.
App and third-party payload audit
Measured, ranked and costed. Usually the largest single win and always the cheapest.
Image and media discipline
Correct dimensions requested at the point of render, modern formats, explicit width and height on every image, eager loading only above the fold and lazy loading everywhere else.
JavaScript restructuring for INP
Long tasks broken up, non-critical work deferred, event handlers made cheap, IntersectionObserver used instead of scroll listeners. This is where the difficult gains are.
Layout stability
Explicit dimensions on images, video, iframes and embeds. Reserved space for anything that arrives after first paint. Font loading that does not reflow the page.
Theme code review
Render-blocking resources, Liquid loops doing more work than they need to, section structure, and how much is rendered before anything is visible.
Font strategy
Fewer families and weights, subset where sensible, loaded so text is never invisible while waiting.
Verification against field data
We re-check CrUX after the 28-day window has caught up and report what actually moved, not what we hoped would.
We hold the same standards on our own builds: logical CSS properties, no magic numbers, modern JavaScript with proper cleanup, explicit image dimensions, reduced-motion support, and accessibility verified with axe-core. Performance is a build standard for us, not a service we sell back to fix work we shipped.
What performance work will and won't do
Written plainly, because this is an area where agencies routinely oversell.
It will not, on its own, transform your rankings
Core Web Vitals function as a tie-breaker and a filter alongside other page experience signals, not as a primary ranking factor. Passing them removes a handicap. It does not substitute for relevance, content or links.
It will usually help conversion, and that is the better argument
A store that responds instantly to a filter tap or a variant selection loses fewer people mid-session. The commercial case for speed is conversion, not ranking — which is why this work belongs next to CRO rather than next to SEO.
Diminishing returns arrive quickly
Getting from poor to good is high-value. Getting from good to excellent rarely pays for itself. We will tell you when you have reached the point of stopping.
Some of it is a merchandising trade-off, not an engineering problem
Sixty products per collection page, four upsell widgets on the product page and an autoplaying hero video all cost performance. Those are business decisions, and we will show you the cost rather than quietly deleting them.
Because the real return is conversion rather than rank, this work pairs directly with conversion optimisation. Our CRO audit checklist is free and runnable without us.
What it costs
Performance work runs at $150 per hour. A focused audit with a ranked, costed findings list fits a 10-hour block at $1,500. Implementation typically runs as a monthly retainer from 20 hours at $3,000, because Core Web Vitals field data takes about 28 days to confirm a fix and the work benefits from iteration rather than a single push.
| Engagement | From | What you get |
|---|---|---|
| Performance audit | 10 hours / $1,500 | Field-data analysis, app payload audit, ranked and costed findings |
| Audit plus implementation | 20 hours / $3,000 per month | The above, then the fixes, verified against field data |
| Build-in performance | Part of any project | Included in our build standard, not billed as a rescue |
Start with the audit. If the findings are things your own team can implement, implement them — several of the highest-impact fixes are configuration rather than engineering, and we would rather you spent the money on the ones that are not. Our full Shopify Plus cost guide covers rates and engagement types across all our services.
Why us for this
Solo Media Group is a Platinum-tier Shopify development services partner — the top of Shopify's Service Track — rated 5.0 from 37 reviews on the Shopify Partner Directory, with 75+ replatforms and new builds delivered since March 2018.
Performance and accessibility verification are part of our standard build process rather than an upsell. Every UI change we ship is checked against WCAG 2.2 AA with axe-core, and every theme we deliver is measured with Lighthouse before handoff.
One client review speaks to the underlying discipline more usefully than a score would:
Who we're not the right fit for
- Anyone chasing a Lighthouse score of 100. It is a lab number on simulated hardware. Chasing it produces work that does not move field data and costs you real money.
- Stores whose problem is not actually speed. If conversion is flat and the site is fast, performance work will not fix it. We will say so and point you at the CRO audit instead.
- Brands unwilling to remove any apps. If every app is non-negotiable, the biggest lever is off the table and the remaining gains may not justify the fee.
- Anyone who needs results reported next week. Field data moves on a 28-day window. We will not show you lab numbers and call them results.
Shopify performance FAQs
What are the current Core Web Vitals thresholds?
LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1, each at the 75th percentile of real Chrome user data. Claims that Google lowered LCP to 2.0 seconds in 2026 do not trace to any Google source — the documented threshold is still 2.5 seconds.
Did INP replace FID?
Yes, in March 2024. INP measures the full lifecycle of an interaction rather than only the initial input delay, and it has carried the same weight as LCP and CLS since that change. Any guide still listing First Input Delay is out of date.
Why does my Shopify speed score look fine while Search Console reports failures?
They measure different things. Shopify's speed score and Lighthouse are lab tests on simulated hardware. Core Web Vitals are field data from real Chrome users at the 75th percentile. A store can pass the lab test and fail the field data because a quarter of real visitors are on slower devices and connections.
Why is my Shopify store slow?
On most stores the answer is app and third-party script payload, followed by oversized images. Each app can inject JavaScript and CSS that executes on every page load whether the feature is used or not. Theme code matters, but it is rarely the largest single factor.
Can I change Shopify's hosting or CDN to go faster?
No. Hosting, CDN and server response are Shopify's, and so is checkout. That narrows the work to theme code, payload, images, fonts and third-party tags — which makes a Shopify performance engagement more predictable than the equivalent on a self-hosted platform.
Which Core Web Vital is hardest to fix?
INP. Reported figures put roughly 43% of sites above the 200 millisecond threshold. Unlike LCP and CLS, which have well-established fixes, INP requires restructuring JavaScript — breaking up long tasks, deferring non-critical work and keeping the main thread responsive.
How long before a fix shows in Search Console?
About four weeks. CrUX reports on a rolling 28-day window, so field data lags real improvement. Anyone reporting a Core Web Vitals win days after a deploy is showing you lab results.
Will passing Core Web Vitals improve my rankings?
It removes a handicap rather than delivering a boost. Core Web Vitals act as a tie-breaker and filter alongside other page experience signals, not as a primary ranking factor. The stronger commercial case for speed is conversion.
Do I need to go headless for performance?
Rarely, and not as a first step. Headless can help at the margins, but it adds significant cost and complexity. Most Shopify stores have far more to gain from an app audit and image discipline than from a re-architecture.
Will removing apps break my store?
Not if it is done properly. We audit what each app actually does on the storefront, identify duplicates and unused features, and stage removals so they can be reversed. Leftover script tags from previously uninstalled apps are also worth clearing — they are common.
How much does Shopify speed optimization cost?
Our rate is $150 per hour. A focused audit with a ranked findings list fits a 10-hour block at $1,500. Implementation typically runs as a monthly retainer from 20 hours at $3,000, since verifying fixes against field data takes about a month.
Can our own team do this?
Some of it, yes — several of the highest-impact fixes are configuration rather than engineering, and we will hand you those in the audit rather than billing for them. The parts that usually need help are INP work and theme render-path changes.
