A performance audit report, run on our own site

A website performance audit measures how fast your key pages load and respond, finds what slows them down, and orders the fixes by what they’ll buy you. It covers Core Web Vitals in the lab and the field, the JavaScript, images and fonts each page ships, caching, and the rendering strategy.

convoke.software is fast in the lab. On Lighthouse’s default settings every page scores 100 for performance on mobile and desktop, and every one of the 160 runs scored 100 for accessibility, best practices and SEO. Under a stricter test that actually slows the connection, mobile LCP is 2.07 to 2.16 seconds, inside Google’s 2.5 second “good” line but with little to spare, and most of that time is spent waiting for a stylesheet.

The costs are in what each page downloads after it paints. The Google Analytics script is preloaded as if the page needed it to render, and on a slow phone it adds 66 to 90 ms to LCP and 1.9 to 3.5 seconds to Time to Interactive. The animated hero downloads about 240 KB of 3D graphics code on every page with the hero band (all but contact and privacy), more than the rest of the site’s JavaScript put together. Neither shows in a score of 100.

We couldn’t get field data from real visitors for this audit; the field data section says why and what would provide it.

Pages. The home page, the white label service page, the blog post with the most search impressions (Claude Design Skills) and the performance audit page. Between them they cover the site’s templates: home, service, article and audit.

Devices. Mobile is Lighthouse’s default: an emulated Moto G Power, 412 pixels wide, on a 150 ms round trip and 1.6 Mbps connection, with the CPU slowed four times. Simulated runs model that profile directly; applied runs use Lighthouse’s browser-level version of it, a 562.5 ms request latency and 1.47 Mbps download. Desktop is Lighthouse’s desktop preset: 40 ms and 10 Mbps under simulation, no CPU slowdown, and no network throttling in applied runs.

Two ways of throttling. Lighthouse’s default, the one PageSpeed Insights uses, loads the page at full speed and then simulates how long it would have taken on the slow connection. Applied throttling actually slows the connection and the CPU in the browser while the page loads. We ran both: simulated, because it’s the number most people will compare against, and applied, because it’s closer to a real slow phone and because the simulation got the analytics comparison wrong (below).

Analytics. Every run blocked Google Analytics’ collection requests, so no test visit reached the site’s analytics. We checked the network log of every run: no collection request got a response. To measure what the analytics script itself costs, each page ran twice: once with googletagmanager.com blocked too, so no analytics at all, and once with gtag.js allowed to load. The difference between the two is the cost of the script.

Why the analytics cost uses applied throttling. Under simulation, the pages without analytics came out 0.62 to 0.77 seconds slower to first paint than the pages with it, which can’t be right. The most likely reason is that Lighthouse’s simulator still counts the blocked gtag.js preload as a request to a new host, with its connection set-up, while in the real run it failed at once. Applied throttling has no such step, so its difference is the one we report.

Limits. This machine is fast: Lighthouse rated its CPU at about 3,700 to 3,900, well above the range its documentation gives for a high-end desktop. Slowed four times it is still quicker than a mid-range phone, so CPU-bound numbers (TBT, long tasks, TTI) are on the kind side. Applied throttling also shares the connection evenly between requests, without the priorities a real HTTP/2 connection would use, so it probably overstates how long the stylesheet waits in finding 3. Lab tests can’t measure INP, which needs real interactions; TBT is its lab stand-in.

Also checked with curl at the same time: response headers, compression, redirects, robots.txt, sitemap.xml, llms.txt, the structured data on each page, and the JavaScript chunks the live pages load, matched to a next build of the code in production.

Field data was not available to this audit. Lab tests are one browser on one connection; field data is what real visitors experienced. It’s the version Google uses, and the only way to measure INP.

It would come from two places. The Chrome UX Report (CrUX) publishes the 75th percentile of LCP, INP and CLS from real Chrome users over the last 28 days, for the whole site and for busy pages, once a site has enough traffic; it’s read through the CrUX API, which needs a key we didn’t have, or BigQuery. Search Console’s Core Web Vitals report shows the same data grouped by similar pages, to anyone with access to the property.

We didn’t use PageSpeed Insights to fill the gap: its lab run would have loaded the site with analytics running. We also didn’t check whether CrUX holds data for convoke.software, so we make no claim either way. In a client audit, field data is the first thing we ask for, and the report says plainly when a site is too quiet to have any.

• Accessibility, best practices and SEO: 100 on all 160 runs.
• Layout shift: CLS 0.005 or less on every run, against Google’s “good” line of 0.1.
• Main thread: TBT 44 ms at most, in any run.
• Server and caching. Pages come from Vercel’s edge cache over HTTP/2, compressed with Brotli when the browser asks for it (the home page is 18,800 bytes with Brotli, 24,071 with gzip). Static files are cached for a year and marked immutable. HTML is revalidated on every request, so a deploy shows straight away.
• One host. http:// and www. both redirect to https://convoke.software in one permanent hop, and canonicals match.
• Fonts. Both text fonts use font-display: swap with size-matched fallbacks, so text paints before they arrive and doesn’t move when they do. Their Latin subsets are preloaded.
• Images. Served as WebP through Next.js’s image component, with a set of sizes to choose from. The blog post’s first screenshot is preloaded at high priority; the rest load lazily.
• Structured data. The JSON-LD on all four pages parses and has the properties Google requires: Organization and WebSite everywhere, BreadcrumbList on inner pages, BlogPosting with author and dates, Service and FAQPage where they belong. Google only shows FAQ rich results for authoritative government and health sites, so the FAQ markup won’t earn one, but it isn’t an error.
• Legacy JavaScript. Lighthouse flags 12 KiB of polyfills. They are Next.js 14’s own polyfill module, 1,380 bytes before compression, so Lighthouse’s estimate overstates it. Not worth a change on its own.
• Crawl files. robots.txt, sitemap.xml and llms.txt are all served.