Shopify
Shopify speed optimization checklist (2026 edition)
A practical checklist for Shopify speed optimization in 2026. App stack, theme, images, fonts, third-party scripts, monitoring — what to do, in order, with the metrics that decide rankings.
Use this as a working checklist when shipping Shopify speed work. Items are ordered by impact. Tick each before moving on.
Measure first
- [ ] Pull the CrUX report for your domain (PSI or Shopify Web Performance)
- [ ] Record real-user LCP, INP, CLS at p75 by template (home, PLP, PDP, cart)
- [ ] Identify the worst-performing template
- [ ] Set per-template performance budgets (LCP < 2.0s, INP < 150ms, CLS < 0.05)
- [ ] Install Real User Monitoring (web-vitals.js, Speed Curve, or GA4 RUM)
App stack
- [ ] Audit every active app
- [ ] Remove apps not used in last 90 days
- [ ] Uninstall via official app uninstall flow (not just app removal)
- [ ] Check theme.liquid for orphan script tags from removed apps
- [ ] Consolidate redundant apps (reviews, forms, analytics)
- [ ] Replace app functions with theme code where possible
- [ ] Final app count: ideally < 12 active apps
Theme
- [ ] Audit theme for sitewide section JS/CSS loading
- [ ] Remove unused sections from active templates
- [ ] Migrate to Dawn-based theme or custom theme if paid theme is the bottleneck
- [ ] Custom Liquid for high-frequency components
- [ ] Section-level JS lazy-loaded where possible
Images
- [ ] All product images use
image_urlfilter (auto WebP) - [ ] Hero images have
widthandheightattributes - [ ] LCP image has
fetchpriority="high" - [ ] All below-fold images use
loading="lazy" - [ ]
srcsetandsizesset per template - [ ] No 4000px hero images served on mobile
Fonts
- [ ] Self-hosted via
asset_urlfilter - [ ] Subset to characters used
- [ ] Only weights actually used
- [ ]
font-display: swapset - [ ] LCP font preloaded
- [ ] WOFF2 format
JavaScript
- [ ] Defer non-critical JS
- [ ] Remove jQuery if possible
- [ ] Audit
script_tagAPI installs (apps that inject globally) - [ ] No render-blocking JS in
<head> - [ ] Section-level JS deferred to interaction
Third-party scripts
- [ ] Move analytics to GTM Server-Side
- [ ] Use Meta Conversion API instead of pixel-only
- [ ] Defer chat widgets to user interaction
- [ ] Audit every GTM tag for weight earned
- [ ] No render-blocking third-party CSS
Checkout
- [ ] Express checkout enabled (Shop Pay, Apple Pay, Google Pay)
- [ ] Checkout extensibility migrated (Plus stores)
- [ ] No legacy checkout.liquid customization that slows checkout
- [ ] Custom Pixels used over deprecated additionalScripts (Plus)
CDN & caching
- [ ] Shopify CDN handling images (default; verify)
- [ ] Theme assets served from Shopify CDN
- [ ] Browser caching headers correct
- [ ] No cache-busting query strings on static assets
Monitor & maintain
- [ ] Real-user CWV monitoring on for 30+ days
- [ ] Per-template performance budgets in your team's docs
- [ ] Quarterly speed audit on the calendar
- [ ] App installs reviewed for performance regression
- [ ] PageSpeed Insights checked monthly per template
Stuck?
If you've worked through the checklist and the numbers haven't moved meaningfully, the problem is usually structural — theme architecture, app debt, or third-party script chains. That's the work our Shopify speed optimization service does. Real-user CWV, fixed at the source, with 30 days of monitoring after launch.
If you're setting up a new store and want to avoid this debt entirely, our Shopify store setup services ship launch-ready performance from day one.
Short answer for busy teams
The useful answer is not "pick the popular option" or "follow the tool your agency prefers." For Shopify speed optimization checklist, the right decision is the one that supports which performance tasks must be complete before a Shopify theme is considered production-ready. That means looking at the business model, the content model, the people who will operate the site, the conversion path, and the technical constraints that will still exist six months after launch.
For Shopify teams responsible for keeping storefront performance healthy after launch, the practical test is simple: will this choice improve real-user LCP, INP, CLS, PDP speed, cart interaction latency, and app count, or will it only make the launch feel cleaner? Google-friendly content and AI-search-friendly content both reward the same thing here: clear answers backed by real operating judgment. A page should define the problem, explain the trade-offs, show the implementation path, and make the next decision easier for a human reader.
If you remember nothing else from this guide, remember this: do not optimize for a screenshot, a launch presentation, or a single score. Optimize for the way the website will be used every week by customers, editors, search engines, and the team responsible for keeping it accurate.
The decision framework we use in client work
When Haxtiv evaluates Shopify speed optimization checklist, we do not start with a preferred platform. We start with five questions. Each question exposes a different kind of risk, and together they usually make the right answer obvious.
1. What job must the website do for the business?
Some websites primarily create demand through education, search visibility, expert content, and trust. Others primarily convert demand that already exists through product discovery, pricing, availability, checkout, or booking. The wrong build happens when a team confuses those two jobs.
If the site has to educate buyers before they convert, the content model needs to be strong. If the site has to process product demand, the commerce or booking layer has to be stronger. If both jobs matter, the architecture needs to let each system do what it is best at instead of forcing one platform to pretend it is everything.
2. Who will operate the site after launch?
A website that only developers can improve will stall. A website that lets every editor change everything will drift. The best system gives the internal team enough control to publish quickly while protecting the design system, SEO structure, performance budget, and conversion path.
For Shopify speed optimization checklist, this is where many projects become expensive later. The launch looks fine, but the operating model is wrong. Editors avoid the CMS, developers become a bottleneck, and the marketing team creates workarounds. Within a year, the site no longer resembles the system that was approved.
3. What content needs to exist for search intent?
Search intent is not just a keyword. It is the shape of the answer a person expects. A comparison query needs trade-offs. A service query needs scope, proof, process, pricing signals, and next steps. A troubleshooting query needs symptoms, causes, order of operations, and verification.
For AI search and answer engines, the content also needs extractable structure. A strong page includes short answers, definitions, decision rules, lists, examples, FAQs, and clear internal links. That does not mean writing robotic blocks for machines. It means writing in a way that a human can scan and a machine can understand without guessing.
4. What has to be measured?
For this topic, the useful measurement set is real-user LCP, INP, CLS, PDP speed, cart interaction latency, and app count. Those metrics matter because they connect the technical decision to business outcomes. A site can look better and still perform worse. A faster page can still convert poorly. A migration can preserve traffic but break lead quality. Measurement prevents the team from declaring victory too early.
We prefer before-and-after snapshots by template, not sitewide averages. Sitewide averages hide the problem. A homepage, service page, product page, blog post, location page, and checkout flow all have different jobs. Each deserves its own baseline and its own target.
5. What happens when the site changes?
The best architecture is not the one that survives launch. It is the one that survives the next campaign, the next product line, the next service page, the next redesign request, and the next algorithmic shift. This is why we care so much about content models, reusable components, schema, internal links, and performance budgets.
A website should become easier to improve over time. If every improvement requires fragile manual work, the site is not a system; it is a collection of pages.
What a useful implementation plan looks like
A good implementation plan for Shopify speed optimization checklist has four layers: discovery, architecture, production, and stabilization. Skipping any layer usually creates rework.
Discovery
Discovery should produce decisions, not a mood board. The team should leave discovery knowing the audience, the priority journeys, the content types, the URL structure, the technical constraints, the measurement plan, and the first version of the internal-link graph.
For Shopify, Liquid, app embeds, theme assets, CDN images, checkout extensibility, and monitoring, discovery should include a crawl or platform audit when an existing site is involved. You want to know which pages currently earn impressions, which URLs have links, which templates are slow, which conversion paths work, and which parts of the CMS the team avoids.
Architecture
Architecture turns the strategy into a system. That includes page types, fields, components, navigation, taxonomy, schema, canonical logic, media policy, and editorial permissions. This is where many visually strong sites become weak: they design pages before they design the system those pages belong to.
A strong architecture also includes deletion rules. Not every old page deserves to survive. Some pages should be consolidated, redirected, rewritten, or left out of the new sitemap. The decision should be based on search demand, backlink value, conversion value, content quality, and overlap with stronger pages.
Production
Production should protect the decisions made earlier. Developers should not discover the content model halfway through the build. Designers should not invent one-off modules that the CMS cannot support. SEO should not arrive in the last week asking for headings, schema, links, and redirects.
For Shopify speed optimization checklist, production quality is visible in details: clean headings, descriptive anchor text, predictable templates, crawlable links, accessible components, image dimensions, structured data, canonical URLs, and copy that answers the query without pretending every visitor is ready to buy.
Stabilization
The first month after launch matters. Search engines recrawl. Users behave differently. Editors find rough edges. Performance data becomes real. Stabilization is where the team fixes what only live usage can reveal.
We watch index coverage, ranking movement, Core Web Vitals, conversion paths, form quality, 404 logs, internal-search terms, and editor feedback. The goal is not to panic over every movement. The goal is to notice the few issues that matter before they become expensive.
Common mistakes to avoid
The most common mistake is installing apps faster than the team removes unused scripts, sections, and legacy theme code. It feels efficient at the time because it simplifies the decision. In practice, it moves the complexity into launch week or, worse, into the months after launch when the site is already public.
Other mistakes show up often enough that they are worth naming:
- Choosing a platform before mapping the content model.
- Treating Core Web Vitals as a final QA task instead of a build constraint.
- Letting every service, product, or location page use the same copy pattern.
- Rewriting URLs without a redirect and internal-link plan.
- Publishing comparison content that refuses to make a recommendation.
- Adding FAQ schema to weak FAQs instead of improving the actual answers.
- Measuring only traffic instead of qualified traffic, leads, revenue, and task completion.
- Letting the footer carry the internal-link strategy instead of building contextual links into the content.
The fix is not more complexity. The fix is better sequencing. Decide the job of the site, then the content model, then the platform and templates, then the migration plan, then the measurement plan. That order saves more money than almost any optimization tactic.
How this should be written for Google and AI search
Good SEO in 2026 is less about making a page longer and more about making the page complete. Length helps only when it gives the reader more useful decision support. A 4,000-word article that repeats itself is worse than a 1,200-word article that solves the problem. But for complex commercial and technical topics, thin content usually fails because the real answer needs nuance.
For Shopify speed optimization checklist, a strong page should include:
- A direct answer near the top.
- A clear definition of the problem.
- The situations where each option is best.
- The situations where each option is risky.
- Specific implementation steps.
- A measurement plan.
- Mistakes to avoid.
- FAQs that answer real objections.
- Links to deeper service or resource pages.
This structure helps traditional search because it covers intent thoroughly. It helps AI systems because the page contains concise, quotable answers and clear relationships between entities, actions, risks, and outcomes. Most importantly, it helps humans because it respects their time.
Measurement plan after the decision
Do not wait until the project is finished to define success. For Shopify speed optimization checklist, we would track real-user LCP, INP, CLS, PDP speed, cart interaction latency, and app count. We would also separate leading indicators from lagging indicators.
Leading indicators appear quickly: crawl health, indexability, LCP, INP, CLS, form errors, editor publishing speed, and content completion. Lagging indicators take longer: rankings, organic revenue, lead quality, assisted conversions, retention, and total cost of ownership.
A simple dashboard is enough. Track the metrics by template and by journey. If the homepage improved but service pages declined, the average does not matter. If traffic increased but qualified leads fell, the project did not succeed. If performance improved in Lighthouse but real-user CrUX data stayed poor, the work is not finished.
Quality-control checklist before you publish or launch
Before publishing a page, launching a redesign, or committing to a platform decision, run a final quality-control pass. This is where good teams catch the issues that do not show up in a design review.
First, read the page as a buyer would. Does it answer the main question quickly? Does it explain who the advice is for? Does it say when the recommendation is not the right fit? Helpful content is not afraid to disqualify. If every option sounds equally good, the page is not helping.
Second, read the page as an editor would. Are the headings predictable? Are examples concrete? Are internal links placed where the reader naturally needs the next step? Are important claims supported by process, data, examples, or experience? This is the difference between expert content and decorative content.
Third, read the page as a crawler would. Is there one clear H1? Do H2s describe the actual sections? Are links crawlable? Is schema aligned with visible content? Is the canonical URL correct? Are images sized, described, and useful? Are FAQs genuinely visible on the page rather than added only for structured data?
Finally, read the page as an operator would. Can the team maintain this system next quarter? Can they add another service, product, location, or article without breaking design quality? Can they measure whether the work performed? If the answer is no, the issue is not content length; it is architecture.
Practical next step
If you are making this decision now, write down the constraint first. Is the constraint search visibility, speed, editor control, checkout conversion, compliance, migration risk, design quality, or maintenance cost? Once the constraint is named, the right path is easier to see.
For a second opinion, start with our Shopify speed optimization work. If the decision is connected to a broader website project, also read Shopify store setup. We can usually tell within one call whether the project needs a focused fix, a redesign, a rebuild, or a smaller scope than expected.
FAQs about Shopify speed optimization checklist
What is the short answer on Shopify speed optimization checklist?
The short answer is to make the decision around which performance tasks must be complete before a Shopify theme is considered production-ready. The right choice is the one that improves real-user LCP, INP, CLS, PDP speed, cart interaction latency, and app count, not the one that sounds best in a tool comparison.
Who should care most about Shopify speed optimization checklist?
Shopify teams responsible for keeping storefront performance healthy after launch should care because this decision affects search visibility, conversion quality, operating cost, and how easily the website can improve after launch.
What is the biggest mistake with Shopify speed optimization checklist?
The biggest mistake is installing apps faster than the team removes unused scripts, sections, and legacy theme code. Strong teams validate the decision against user intent, platform constraints, measurement, and the people who will maintain the site.
How should teams measure whether Shopify speed optimization checklist worked?
Measure real-user LCP, INP, CLS, PDP speed, cart interaction latency, and app count. Do not rely on launch-day opinions or lab-only scores; use real user behavior, search data, and conversion outcomes.
Final recommendation
Do the smallest serious version of the work. Not the cheapest version. Not the biggest version. The smallest serious version is the scope that solves the real constraint, protects the site from avoidable search and performance risk, and gives the team a system they can keep improving.
That is the standard we use for Shopify, Performance, Checklist, Core Web Vitals. If the work does not make the site clearer for users, easier for editors, healthier for search engines, and more measurable for the business, it is probably not the right work yet.
Inés Vargas
Shopify & commerce partner
Shopify and commerce partner at Haxtiv. 9 years shipping Shopify Plus, B2B catalogs, and headless storefronts. Writes about app stack discipline, conversion craft, and the parts of Shopify work merchants under-invest in.
More about the studio →