Stop losing sales to a slow storefront

No, and you should be sceptical of anyone who promises it. A perfect score on a lab test is achievable by stripping functionality your business needs, and it does not correlate reliably with revenue. We target Core Web Vitals thresholds on field data from real customers, because that is what Google uses for ranking and what actually reflects the experience. Expect a materially better score as a side effect, not as the goal.

We will not invent a number for you. Published research consistently links faster load to higher conversion, but the size depends on where you start, your traffic mix, and your category. If you are at four seconds on mobile, there is real money in this. If you are already at two, the remaining gain is smaller and better spent elsewhere. The audit tells you which situation you are in before you commit to the fix.

Not necessarily. Many apps can be loaded conditionally so their scripts run only on the templates that need them, which captures most of the gain without losing functionality. Removal is the recommendation when an app is genuinely unused, when it duplicates something another app already does, or when it injects heavy scripts into every page for a feature that appears on one. You make the call; we provide the cost of keeping each one.

Because field data is a rolling window of real visits and it needs traffic to become meaningful. Reporting the day after deployment would mean quoting lab numbers again, which is the problem we are trying to avoid. The 28-day window lets us show you the same measurement your ranking is based on, and it catches regressions that only appear under real traffic patterns.

Theme updates are fine because the work lives in your theme and is documented. App installs are the real risk, and that is why the report includes an evaluation checklist. Most performance regressions we see six months later trace to a single app added without anyone checking what it loads. If you want that watched continuously rather than checked once, it belongs in a managed services retainer.

Yes, but it is a different engagement and priced accordingly. Native Shopify themes have known patterns and predictable bottlenecks, so the work is efficient. A custom front end means reading unfamiliar code, understanding its build and rendering strategy, and often finding that the bottleneck is architectural rather than a tuning problem. We start with a paid audit in those cases so nobody is guessing at scope.