Service
Performance checks
Performance checks measure how quickly your main templates load and respond, compare them with Google's Core Web Vitals thresholds, and point to the specific images, scripts and settings that slow them down. We report what we measured and how, so the numbers can be repeated.
A slow page is a defect a visitor feels before they read a word. Our performance checks are part of QA, so the aim is practical: find out whether the main templates meet a sensible standard before launch, and if they do not, name the causes clearly enough that a developer can act.
What we measure
We measure against Google's Core Web Vitals, which web.dev describes as three metrics with published thresholds:
| Metric | What it describes | Good threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading: when the main content appears | Within 2.5 seconds of the page starting to load |
| Interaction to Next Paint (INP) | Responsiveness: how quickly the page reacts to input | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | Visual stability: how much content jumps around | 0.1 or less |
web.dev recommends judging these at the 75th percentile of page loads, split between mobile and desktop. That matters for how we report. A single test run on a fast connection says little about the 75th percentile of real visitors, so we separate two kinds of evidence:
- Lab measurements. Repeatable tests we run ourselves, on throttled mobile and desktop profiles, on each main template. These are good for finding causes and comparing before and after a fix.
- Field data. Measurements from real visitors, where your site has enough traffic for public field data to exist or where you already collect it. A new site may have none at launch, and the report says so rather than inventing a figure.
What we look at beyond the scores
- Page weight. Total download size per template, and which files account for most of it.
- Images. Oversized images, missing modern formats, images that load before they are needed, and the hero image that decides LCP.
- Fonts. How many font files load, whether they block text from appearing, and whether text shifts when the font arrives.
- JavaScript and third-party scripts. Chat widgets, tag managers, embedded video and analytics that block the main thread or push layout around. We list each one with its cost so you can decide whether it earns its place.
- Caching and compression. Whether static files are cached sensibly and text files are compressed.
- Server response time. How long the server takes to send the first byte, which no front-end fix can make up for.
- Layout shift sources. Banners, embeds and images without dimensions that move content as they load.
How a session runs
We agree the templates to test, such as the home page, a content page, a listing page and the pages in your main conversion flow. Each template is tested several times on each profile, and we report the median rather than the best run. Findings are tied to evidence: the waterfall, the element responsible for LCP, the script holding the main thread. After fixes, we rerun the same tests on the same profiles so the comparison is fair.
Reading a performance finding
Each finding in our report follows the same pattern, so a developer can act on it without a meeting:
Illustrative performance finding
Template: product listing page, mobile profile.
Observation: Largest Contentful Paint at the median of five runs is above the 2.5 second threshold. The LCP element is the first product image.
Cause: the image is 2,400 pixels wide and loads with low priority after two render-blocking scripts.
Suggested direction: serve a smaller image at the displayed size, give it a high fetch priority, and defer the two scripts. Retest on the same profile.
The example above is invented to show the format. The suggested direction is a pointer, not a prescription; your developer decides how to implement it.
What you receive
- A results table per template, stating the test profile, the tool used and the number of runs.
- A ranked list of causes, each linked to the file or setting responsible.
- A note on field data: what exists, what it shows, or that it does not exist yet.
- Before and after figures once fixes are in.
Third-party scripts in detail
Third-party scripts deserve particular attention because their cost is easy to overlook and they can be added long after a site is built. For each one on the main templates, we record what it is, which pages load it, how much it downloads, whether it blocks rendering or the main thread, and whether it sets cookies. That list gives you a basis for a decision: some scripts earn their place, some can load later, and some can go. Removing a script is a business decision as much as a technical one, so the report presents the cost and leaves the choice with you.
What this service does not cover
We do not rewrite code, change hosting, or tune servers. Load testing, where large numbers of simulated visitors test capacity, is outside scope. Performance figures change with networks, devices and content, so we report the conditions of every measurement and avoid promising a particular score after launch.
When to book performance checks
- Before launch, once real images and third-party scripts are in place, because placeholder content can make a page look faster than it will be.
- After adding tracking, chat or video embeds.
- When field data in Search Console or your analytics moves from good to needs improvement and the cause is unclear.
Questions about performance checks
Why do our scores differ each time we test?
Lab tests vary with network conditions, server load and background work on the test machine. That is why we take several runs and report the median with the test conditions.
Our score is green in one tool and amber in another. Which is right?
Tools measure different things under different conditions. Lab tools simulate one device and connection; field data reflects real visitors. We explain which figure answers which question.
Will passing Core Web Vitals help our rankings?
We report against the thresholds because they describe how real visitors experience a page. We do not predict ranking effects, which depend on many signals we cannot see.
Sources
Sources were read on 4 November 2026.
Want your main templates measured before launch?
Name the templates and any third-party scripts. A free, no-obligation email reply says whether performance checks are worth doing now.
- Written scope
- Fixed quote before any deposit
- Plain-language findings