Core Web Vitals conversations go off the rails when they become scoreboard chasing. Merchants buy a new theme because Lighthouse went orange. Two app installs later, the scoreboard is orange again and nobody knows which script did it.
I use a Shopify speed budget instead: weight limits per template, a cut list before any theme swap, and CWV as a diagnostic — not a religion. Theatre is optimizing a lab URL. Practice is keeping collection and product pages honest on mid-tier mobile.
If you want a directional link between delay and revenue, use the page speed revenue calculator. Then come back and cut weight.
What a speed budget is
A budget is a set of caps you agree to before work starts:
- Max kilobytes of JavaScript on homepage / collection / product / cart
- Max number of third-party scripts on those templates
- Image policy (sizes, formats, priority image rules)
- “No new app without a budget review” rule
When a request would break the budget, something else must leave — or the request waits. That single social rule prevents death by a thousand tags.
CWV without the theatre
Useful CWV habits:
- Measure field data (CrUX / Search Console) alongside lab runs
- Test on throttled mobile, not only cable + desktop
- Look at p75, not your best refresh
- Separate template types — a lightning blog post does not redeem a heavy PDP
Theatre habits to drop:
- Celebrating a 100 Lighthouse on a blank development theme
- Ignoring checkout and cart because “PDP is what Google sees”
- Buying an expensive theme as a substitute for uninstalling apps
- Chasing micro-optimizations while a 1.2 MB hero video autoplays
LCP, INP, and CLS still matter. They matter as symptoms. The disease is usually unbounded JavaScript, huge media, and layout that shoves content after load.
Weight limits per template (starting points)
Every store differs, but I need numbers on the whiteboard or nothing ships. Starting points I adjust per project:
| Template | JS budget (compressed, rough) | Third-party scripts | Notes |
|---|---|---|---|
| Homepage | tight — marketing loves to overload it | few | heroes and carousels are suspects |
| Collection | medium | few | filters + infinite scroll cost INP |
| Product | medium-high (necessary media) | carefully chosen | reviews/upsells creep |
| Cart | low | minimal | protect conversion |
| Blog | low | minimal | easy win, do not steal focus |
Treat these as negotiation anchors, not laws. The point is that “one more app” has to answer to a number.
What to cut before you buy a new theme
Theme swaps feel productive. Sometimes they are. Often they copy the same apps onto prettier Liquid.
Cut list before migration quotes:
- Unused apps — uninstall, do not just disable the embed
- Duplicate pixels — two analytics tools “just in case”
- Heavy review widgets on every page — load on PDP, not sitewide
- Autoplay video backgrounds — especially on mobile
- Font museums — three families × many weights
- Carousel stacks — multiple sliders above the fold
- Injected chat + popup + surveys all at once on first visit
After the diet, remeasure. If you still need structural work — sections architecture, Liquid that loops forever, bad image pipelines — then talk theme or custom. Budget that conversation with the Shopify build cost estimator so “new theme” is a scoped system, not a vibe.
Liquid and app reality
Liquid can be slow when it does silly amounts of work in templates, but many “Liquid is heavy” complaints are actually script soup. Profile before you rewrite.
Practical checks:
- Huge
forloops over collections in the critical path - Sections that pull metafields they do not render
- Apps that inject into
content_for_headerunconditionally - Tag managers that load everything on every page “for flexibility”
Flexibility without a budget is how CWV dies.
Image and LCP habits that pay rent
- One clear LCP candidate per template (usually the hero or main product image)
- Modern formats where Shopify’s pipeline allows; correct width
- Do not lazy-load the LCP image
- Reserve space to avoid CLS (dimensions, skeleton that matches)
- Compress before upload when merchants drag 6000px PNGs from a DSLR
I would rather fix three product image habits than rewrite a theme section for a 20ms fantasy.
INP: the vital people feel as “lag”
INP suffers when the main thread is busy — filters, variant pickers, mega-menus, third-party listeners.
Fixes that help:
- Debounce filter changes; do not re-render the world per keystroke
- Defer non-essential listeners until interaction
- Kill scrolljacking and heavy parallax on mobile
- Audit apps that bind click handlers sitewide
If collection filtering feels sticky on a mid-range Android, that is a revenue issue — not a lab curiosity.
A weekly speed hygiene loop
For live stores I like a boring loop:
- Field CWV glance + one lab pass on PDP and collection
- App/script inventory diff since last week
- One cut or one deferral
- Note in the changelog (date, what left, what entered)
This matches how I keep side products alive: small weekly reviews beat heroic rewrites. Speed works the same.
How this ties to ads and checkout
Slow pages waste ad spend the same way checkout friction does. Fix weight and trust before you scale media. A cleaner PDP that reaches checkout faster pairs with the checkout friction fixes — same philosophy, different layer.
How I run a speed kickoff from Karachi
Merchants are often in US or EU timezones. I do not wait for a shared whiteboard hour to start.
Async pack I request:
- Storefront URL + a staff account with limited scope if needed
- List of installed apps (export is fine)
- Top templates by revenue (usually home, collection, PDP, cart)
- Any previous “we hired a speed person” notes
I return a budget proposal and a cut list before I quote a redesign. That sequence prevents paying for a theme while the tag manager still loads five marketing pixels on cart.
If the merchant only wants a Lighthouse screenshot turned green by Friday, I explain what field data will still show. I would rather set that expectation early than “win” a lab score and lose trust later.
Budget exceptions (written, not vibes)
Sometimes you will break a budget on purpose — a required payments script, a regulated analytics tag, a reviews module that truly earns its keep on PDP.
Write the exception down: why it exists, which template, what you cut to compensate. Unwritten exceptions become permanent. Permanent exceptions become the new normal. The new normal becomes another theme purchase in twelve months.
Bottom line
Pick budgets per template. Cut apps and media before you buy a new theme. Use CWV as feedback, not theater. Write the “no new script without a cut” rule where the marketing team can see it.
I am Faraz Hussain, Karachi-based Shopify and AI consultant. If your storefront needs a performance pass or a scoped theme rebuild, we start with a budget and a cut list — then numbers from the page speed calculator — not with a redesign deck that ignores the script tag graveyard.