Site speed and Core Web Vitals for Shopify
Speed conversations produce more anxiety per unit of ranking impact than any other SEO topic - so let's size it honestly first. Core Web Vitals are a real ranking signal, but a modest one: good data beats fast pages in every audit we've done. The stronger case for speed is conversion - slow pages measurably lose buyers, especially on mobile. Optimize for customers; the ranking nudge comes along.
What the three numbers mean
LCP (Largest Contentful Paint): how fast the main content - on a product page, the hero image - appears. Target under 2.5s. CLS (Cumulative Layout Shift): how much the page jumps around while loading (the button that moves as you tap it). Target under 0.1. INP (Interaction to Next Paint): how fast the page responds to taps and clicks. Target under 200ms. Two data sources: PageSpeed Insights for lab diagnostics per URL, and GSC's Core Web Vitals report for field data - real users, at scale, grouped by template. Field data is the truth; lab data is the debugger.
What actually moves the numbers on Shopify
Shopify's infrastructure (hosting, CDN) is fast and not your problem. Your problem is what's layered on top, in reliable order of guilt:
Apps. The dominant factor. Every app injecting storefront scripts adds weight, and stores accumulate apps like sediment - including scripts from apps uninstalled years ago (removal doesn't always clean theme code). The single highest-ROI speed action for most stores: audit installed apps, remove the unused, and have a developer sweep the theme for orphaned script tags. This overlaps with the GTM governance from Phase 3 - same principle, same cleanup.
Images. Shopify serves modern formats and sizes automatically if the theme requests them properly. What you control: don't upload 8MB files, and ensure the theme lazy-loads below-the-fold images but never the LCP hero (lazy-loading the hero is the classic self-inflicted LCP wound).
Theme weight. Feature-maximal themes carry the cost of every feature always. This matters at redesign time - a fast theme is bought, not retrofitted - and explains why "the site got slower every year" without anyone changing anything: sediment.
The division of labor
Yours: the app audit, image discipline, watching the GSC report quarterly, and resisting the next "just one script" pixel. A developer's: render-blocking resources, code-level LCP work, INP debugging. The manager's real job is governance - speed is lost in small, reasonable-sounding increments, and someone has to be the person who asks what each new script costs.