---
title: "Performance audit"
description: "A small fixed-price entry audit: Lighthouse, Core Web Vitals, and your three highest-impact fixes. The one-week deep dive with real-user metrics is the follow-up."
language: "en"
canonical: "https://zapolu.com/services/performance-audit/"
---

# 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](/contact/). 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](/downloads/zapolu-sample-audit-report.pdf)**
(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.