Performance and Core Web Vitals audit

The performance and Core Web Vitals audit is a fixed-price, five-day investigation of one web application that finds out exactly why it is slow and what to fix first. It covers server response times, database queries, caching, infrastructure and the three Core Web Vitals, and ends with a written report and a walkthrough with your team. It is for SaaS and e-commerce teams with real traffic and a problem they can feel but can't yet locate.

Two kinds of data. Field data is what real visitors experienced, from the Chrome User Experience Report, Search Console or your own analytics. Lab data is what I can reproduce on demand with Lighthouse, WebPageTest and a profiler. Field data says where the problem is; lab data says why.

On the front end I measure Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift on mobile and desktop, against the thresholds in the next section. On the back end I follow the slowest requests through the CDN, the application and the database, read the slow-query log and the EXPLAIN plans, and check what is cached and what isn't.

A good page has a Largest Contentful Paint within 2.5 seconds, an Interaction to Next Paint of 200 milliseconds or less and a Cumulative Layout Shift of 0.1 or less, each at the 75th percentile of real page loads. Google assesses field data from real visitors, so a page is good only when all three are met.

Lab scores, such as a single Lighthouse run, help find causes but are not what Google assesses. The audit therefore starts from field data and uses lab tests to explain it.

Last verified 2 November 2026 against Web Vitals on web.dev.

Each problem is measured, explained and paired with a fix, and the fixes are ranked by expected impact, effort and risk. The first fixes are often small: an index, a query that loads related rows once instead of once per row, an image served at the size it's shown, a script deferred. The report also says plainly what isn't worth doing, so you don't spend money on changes that won't move the numbers.

It is not a fix-it service with a report attached. The audit ends with the report; most teams then ask me to implement the top fixes as a fixed-scope follow-up or on a retainer. It is also not useful before you have real traffic: without real users there is nothing real to measure, and a build-time budget in CI is the better investment. If the slowness is in the database, database design and query optimization goes deeper, and for the wider picture of speed work, see website speed optimization.