Shopify Speed Audit: Full-Stack Performance Review

The problem with Shopify speed as most teams measure it

Shopify speed gets measured by a single Lighthouse score pulled from an incognito window on a good connection, and that number becomes the entire conversation. It is the wrong conversation. Real users do not browse in incognito on a wired connection. They browse on a mid-tier Android phone on a flaky LTE connection in a Starbucks, and their experience is what Google uses to rank the site and what the business uses to convert.

The second failure is treating speed as a single number. A storefront has five page types that matter, home, collection, product, cart, and checkout, and each has its own performance profile. A site can have a great product page LCP and a terrible collection page LCP, and the collection page is usually where paid traffic lands. A single score hides all of that.

The third is attribution. When a site is slow, the instinct is to blame the theme. Usually the theme is only part of the story. A typical slow Shopify store has three to six apps injecting scripts, a dozen pixels firing on every page, hero images that were never compressed, fonts loaded with the wrong strategy, and a few legacy liquid sections that block rendering. Without a full-stack audit, fixes get applied to the wrong layer.

How Pixeltree runs a speed audit

We run a five-step methodology that combines lab data, field data, and code review. Every finding is prioritized by expected impact on conversion rate, not by how easy the fix is.

• Step one, baseline and scope. We pull Lighthouse and PageSpeed Insights data per page type, Chrome UX Report data for field performance, and your analytics data to weight page types by traffic and revenue.
• Step two, third-party overhead mapping. We map every third-party script on every page type, categorize by category, marketing, analytics, UX, legal, and measure the render-blocking, main-thread, and network cost of each.
• Step three, theme code review. We read the theme code for each page type with a focus on render-blocking CSS and JS, unused code, image handling, font loading, and Liquid inefficiencies.
• Step four, image and asset pipeline review. We audit how images are served, whether they use the right format, whether the CDN is being used correctly, and whether responsive image markup is in place.
• Step five, prioritized fix list. We produce a prioritized list of fixes with estimated effort, expected impact on LCP, INP, and CLS, and expected impact on conversion rate based on your current baseline.

The deliverable is a document your dev team can execute against or that we can implement as follow-on work.

What you get

The speed audit produces a complete picture of your performance posture and a fix list you can execute.

• Lab and field data per page type, with weighted averages across your traffic
• A third-party script map with cost per script and recommended action
• A theme code review with specific file and line references
• An image and asset audit with format, size, and delivery recommendations
• A prioritized fix list with effort, impact, and owner per item
• A Core Web Vitals forecast if the top ten fixes are implemented
• A one-page executive summary for stakeholders

If the audit is followed by implementation, we roll the fix list directly into a Core Web Vitals optimization engagement.

Timeline

The audit runs two to three weeks from kickoff to final deliverable.

• Week one, data collection, baseline measurement, and third-party mapping
• Week two, theme code review and image pipeline audit
• Week three, prioritization, writeup, and review session

Brands with clean theme access and active CrUX data can compress this to ten business days.

Mini case anatomy

A composite from a US home goods brand doing about fifteen million in annual revenue on Shopify. The brand had an average Lighthouse mobile score of 34 on the product page and 41 on the collection page. LCP on mobile was running at 4.8 seconds on product and 5.2 seconds on collection. INP was above 500 milliseconds site-wide. Conversion rate on mobile was forty-five percent of desktop, which is low for the category.

We ran the five-step methodology. The third-party script map identified fourteen scripts on every page, seven of which were either unused, duplicate, or replaceable with a lighter alternative. The theme code review found that the hero section on the home page was loading a 2.8 megabyte unoptimized video on mobile and that the collection page was blocking render on a legacy infinite scroll script.

The image audit found that product images were served at a single resolution with no responsive markup, and that hero images were JPEGs averaging 800 kilobytes when WebP equivalents would have been under 150.

The prioritized fix list had twenty-three items. The top ten were projected to move LCP from 4.8 seconds to under 2.5 seconds on product and from 5.2 to under 2.8 on collection, and to bring INP below 200 milliseconds site-wide. The forecast on conversion rate based on category benchmarks was a twelve to eighteen percent mobile uplift.

The brand implemented the top ten over six weeks. Mobile LCP on product came in at 2.3 seconds. Collection page LCP came in at 2.6 seconds. INP dropped to 180 milliseconds. Mobile conversion rate lifted by fifteen percent in the following ninety days, and the Lighthouse mobile score moved from 34 to 82 on product.

The lesson was that the problems were distributed across five different layers of the stack, and no single fix would have moved the number meaningfully. The audit let the team sequence the work so each fix compounded.

FAQs

See also the Shopify speed optimization playbook blog, the Core Web Vitals optimization leaf, the app audit leaf, and the performance optimization hub.