Most agencies apply surface-level fixes — compress images, install a caching app, call it done. We dig into the theme code, audit every script and rebuild the critical path so Core Web Vitals reflect what users actually feel.
Speed isn’t a vanity metric — Google ranks on it, conversions scale with it, and a one-second delay can cost a £1M store £70k a year. We treat it as a load-bearing feature.
Every blocking script delays first paint. Most Shopify themes ship with 6–12 such scripts — including ones that have nothing to do with above-the-fold content. We audit, defer or replace them.
Render-blocking resources: 11→ 4.2s of blocked main threadxLCP: 4.8s · target: ≤2.5s
Hero images served at 4× the rendered size. PDP gallery images without explicit dimensions causing CLS. We move to responsive WebP/AVIF, set dimensions, and stop layout shift cold.
x<img src="hero.jpg">// 2400×3000 served, 600×750 rendered→<img src="..."→ width="600" height="750"→ srcset="..." loading="eager">
Every app injects scripts. We audit each app for its real performance cost (not its marketing copy), defer or async non-critical ones, and replace bad actors with custom Liquid alternatives where it pays back.
reviews-app: +320 ms TBTsocial-proof: +180 ms TBTcurrency-converter: +95 ms TBTxTotal: 14 apps · +1.4s blocking
Even after the theme is clean, font loading strategy, CDN cache headers and TTFB still dictate the floor. We tune all three so the optimisation work holds across geographies and devices.
→@font-face {→ font-family: "Display";→ font-display: swap;→ src: url(...) format("woff2");→}
Speed work pairs naturally with /technical-seo and /shopify-development. We’ll tell you which scope fits before quoting.
Most clients start with a one-time pass and move to ongoing monitoring once they see results — and once Core Web Vitals are wired into deploy gates so regressions get caught.
Book a speed assessment"Optimised" is relative. Many developers don't have deep performance expertise. There's usually more that can be done.
Not if done properly. We test thoroughly before deploying. Optimization sometimes reveals existing problems that were hidden.
Initial fixes are permanent, but adding new apps or content can introduce problems. That's why ongoing monitoring matters.
Not necessarily. Apps can often be configured differently, loaded only where needed, or replaced with lighter custom solutions.
operator@hollowpoint:~$cat next-step.txt
We'll run an initial assessment, tell you honestly what we find, and give you a clear plan for improvement. No hard sell.