Performance audit

There are two tiers. The first is a small fixed-price engagement that requires little more from you than a URL.

The entry audit

Send us your store’s address. We measure it from the outside: Lighthouse runs, Core Web Vitals from field data where available, and a written list of the three fixes we’d make first. We explain the findings on a 30–60 minute call. If the numbers are fine, we’ll tell you that too.

The deep dive

A scoped, one-week engagement that ends with a written report and a fix plan rather than a generic Lighthouse PDF.

• Real-user metrics. Core Web Vitals from production traffic instead of a synthetic test in a single Chrome instance, pulled from Cloudflare Web Analytics, Vercel Speed Insights, or a one-off CrUX query.
• Server-side trace: TTFB breakdown by route, database query timings, third-party call profile, cache hit rate. In our experience the slow page is rarely the one you suspect.
• Bundle and asset audit covering images, fonts, JS, and CSS: what’s shipping, what’s blocking, and what should be lazy-loaded, preloaded, or removed.
• Prioritized fix plan. Every issue is tagged with an effort estimate, expected impact (in milliseconds, and in conversion where the data supports an estimate), and risk, then sorted by ROI so you can stop at row 5 if the budget runs out.

Download a sample report (PDF). The client in it is fictional; the structure and the level of detail are exactly what you get.

Example findings

Real findings from stores we’ve worked on over the years, names removed:

• Every product page spent ~300 ms, sometimes whole seconds, inside a synchronous server-side call to a marketing API, on every single view. A transaction trace found it; moving the call to a queue removed it, with before/after numbers to prove it.
• A cache hit rate stuck at 20–30% because a stock-status extension purged the entire Varnish cache after every order. The vendor denied it, so a clean-install reproduction with varnishlog captures settled the question.
• Checkout failed sitewide at order #65,536: a vendor table used a SMALLINT primary key, which had reached its maximum value.
• A catalog query 110 times slower than it should be, with three stacked causes: the platform requesting 10,000 IDs from the search engine by design, a database version regression amplifying it, and a vendor module breaking the API schema on top.
• A nightly import that grew from 6 to 48 minutes. The root cause was a cleanup cron that had failed silently, leaving an 8 GB staging table inside a 13 GB database.
• A customer’s order list brought from 3.5 s to 800 ms once the query stopped hydrating the full order detail for every row it listed.

Slow stores are rarely slow for the reason everyone suspects, which is the point of measuring first.

When this fits

• TTI is above 2.5 s and the conversion rate suggests a problem
• You’re considering a replatform and want to know whether performance is the actual problem
• A new feature dropped your scores and nobody knows which one
• You need a technical second opinion before signing a bigger contract

What it costs

The entry audit is a small fixed price, agreed upfront. The deep dive is also fixed-price and depends on the size of the stack. Most engagements run 5–10 business days and end with a fix plan you can execute with any team, including your own.