Someone always says the theme is slow “because of Liquid.” Then we open DevTools and find a 900 KB app script, four hero videos, and a carousels-inside-carousels situation.
Shopify Liquid performance matters. It is also blamed for sins it did not commit. Here are myths I still hear on calls — and what I measure instead.
Myth 1: “Loops in Liquid are why LCP is bad”
Liquid runs on Shopify’s servers when the page is rendered. A messy loop can slow time-to-first-byte if you are doing absurd work — nested collection walks, repeated all_products lookups, giant cart attribute dumps. That is real.
But Largest Contentful Paint is usually dominated by what the browser downloads and paints: hero image weight, fonts, theme JS, app pixels. I have fixed “Liquid is heavy” tickets by compressing one banner and deferring three scripts while the Liquid stayed almost the same.
Rule of thumb: profile TTFB and Liquid-related server work separately from front-end LCP. Do not rewrite every for loop before you weigh the hero.
Myth 2: “More sections always mean a slower store”
Online Store 2.0 sections are not free — each has HTML, settings, and sometimes CSS/JS. Merchants who stack twenty above-the-fold sections will feel it.
The myth is that sections themselves are the enemy. A tight section architecture with lazy-loaded below-fold blocks beats a monolithic theme.liquid with everything eager. The win is priority: ship critical CSS and content first; delay the rest.
I audit which sections load JS on every template. A map widget on About is fine. The same widget on collection pages is a tax.
Myth 3: “Switching themes will fix Core Web Vitals”
A new theme can help if the old one is a decade of forks and app residue. It can also reset you to a pretty demo full of apps the sales site enabled for screenshots.
Before a theme swap, I ask for a speed budget: image weights per template, max third-party scripts, and which features must remain. Without that, you buy a redesign and inherit a new set of injectors.
Myth 4: “Metafields are slow; put it in tags”
Metafields and metaobjects are the right model for structured content. Abuse can hurt — fetching enormous JSON blobs you barely use — but tags-as-database is how catalogs become unmaintainable.
Prefer targeted metafield reads in the templates that need them. Do not serialize the entire product universe into theme.liquid “just in case.”
Myth 5: “Minifying Liquid comments will save us”
Deleting comments and whitespace is not a strategy. Shopify already optimizes delivery in ways chasing a few bytes of Liquid source will not match. Spend the hour on image CDNs, font subsets, and killing duplicate analytics tags.
What actually moves the needle on most stores
When I run a practical pass:
- Hero and collection imagery — right size, modern format, explicit dimensions, no accidental 4000px uploads.
- App scripts — remove dead apps; load remaining ones only where needed; prefer theme app extensions over legacy injectors when possible.
- Fonts — fewer families, fewer weights,
font-displaystrategy that does not blank the page. - Cart and prediction drawers — do not download the universe on first paint.
- Liquid sanity — avoid
all_products, deep nested loops on large collections, and repeated expensive lookups inside loops; paginate; cache fragments where the platform allows.
That list is boring. It is also where the wins live.
A call script I reuse
- “Show me Lighthouse or WebPageTest on mobile for PDP and collection — not only homepage.”
- “Which apps are allowed to load globally?”
- “What is the maximum hero weight we will accept?”
- “Are we debugging TTFB or browser paint?”
If the merchant only has a homepage score from a marketing PDF, we start over with real templates.
Myth 6: “Async Liquid-style thinking — just put it in JS”
Sometimes the response to Liquid fear is moving logic into storefront JavaScript. That can make TTFB look better while making interaction and main-thread time worse. Price sorting in JS on a huge collection, or fetching product JSON on every card for a tiny badge, is a classic own-goal.
Do server-friendly work when the data is known at render. Use JS for interaction. If you need freshness, prefer section rendering APIs and targeted fetches over boiling the ocean on DOMContentLoaded.
Theme app extensions versus old injectors
Modern app UX can be lighter, but only if you uninstall the legacy embed. Merchants accumulate both. My audit checklist includes: disable unused embeds, remove leftover script tags in theme.liquid, and confirm the app is not loading on password pages and checkout thank-you unless required.
Collection templates: death by a thousand cards
Homepages get the drama. Collection pages get the traffic. Each card with hover video, quick-add APIs, and app ratings widgets multiplies cost by page size. I set a per-card budget: image weight, whether quick-add is allowed above page two, and which badges are metafield-driven HTML versus third-party iframes.
Liquid that paginates cleanly still loses if each card is a mini-app.
Measuring without theatre
I care about field data (CrUX) when it exists, and lab tests on throttled mobile for debugging. One perfect Lighthouse 100 on desktop cable is not a store performance strategy. Pick PDP and collection on mobile; fix the top two offenders; re-measure. Repeat.
Talking to non-technical founders
I translate myths into money: “This app script is competing with your product image for attention on slow phones.” Liquid lectures do not land. Business framing does. Then we do the unglamorous work — compress, defer, delete — instead of rewriting the theme for sport.
App pixels and marketing exceptions
Marketing will ask for one more pixel “just for this campaign.” Campaigns become permanent. I maintain an allowlist with owners and review dates. Liquid cannot save you from a tag manager soup, but a written allowlist gives you a yes/no framework on calls.
When someone claims Liquid is the bottleneck, I ask them to disable marketing tags for a controlled test on staging or a percentage experiment. The before/after on mobile collection LCP is usually educational enough to restart the conversation on facts.
Prefetch, speculation, and “helpful” theme features
Some themes prefetch cart drawers, prediction results, or next collection pages aggressively. It feels snappy on a marketing Wi-Fi demo and expensive on mobile networks. I treat prefetch as a budget item: only for the most likely next navigation, never for every card in view.
If Liquid looks “heavy” in the view-source sense but the network panel shows speculative requests for products the shopper never opens, fix the speculation policy before rewriting section code. Performance myths love to hide next to well-intentioned UX flourishes.
Liquid is a rendering language, not the villain
Write Liquid cleanly. Respect section boundaries. Stop using tags as a CMS. Then put equal suspicion on JavaScript and media — because that is usually what shoppers feel.
I still take performance work on Shopify themes from Karachi: budgets, app audits, and Liquid cleanups without a theatrical theme rewrite. If your store feels heavy, we can separate myth from measurement before you buy another theme.