Performance by template

Vercatus already loads every sampled page in a real browser to see what a rendering crawler sees. The same load measures the page as a visitor experiences it, so performance is part of the run rather than a separate tool — and it is reported the way the site is built: per template, because a slow article template is one ticket, not a thousand slow URLs.

What is measured

In the lab, for every rendered page: time to first byte, First and Largest Contentful Paint (and the element that was largest), Cumulative Layout Shift (and the element responsible for the largest shift), total blocking time (the lab stand-in for INP), bytes transferred by type, render-blocking stylesheets and scripts, text resources served without compression, third-party hosts, images without reserved space or served larger than displayed, and the largest resources.

The lab is Chromium with a desktop viewport, a 4× CPU slowdown (Lighthouse’s default) and an unthrottled network; media requests are not made. Lab numbers are for comparing templates and runs with each other, not for quoting as what a user sees.

From real users, when the instance has a Chrome UX Report key: the 28-day 75th-percentile LCP, CLS, INP and TTFB for the origin, and for one representative page per template. This is the data Google’s page-experience signal reads, so when lab and field disagree the field number wins — and the run says so in a finding.

How it is reported

The Performance tab on a run shows the origin figures, then one row per template with each figure coloured by Google’s Core Web Vitals band (good, needs improvement, poor). Opening a row shows the causes: the LCP element, the shift source, third-party hosts, the largest resources.

Findings land in the same inbox as everything else and go through the same review. A performance finding names the template, the band, what the measurements point to as the cause — a slow first byte, render-blocking bytes, a lazy-loaded hero image, content painted by JavaScript — and the number that should move. Severity follows the knowledge base: real-user failure on the origin is high; lab-only failure on a template is medium; hygiene items are low.

What performance does and does not affect

Two things are easy to overstate, and the knowledge base keeps them in proportion:

• Ranking. Page experience is a ranking signal in Google Search, but a weak one — a tie-breaker between otherwise similar pages, not a lever that lifts a poorly-answering page. Performance findings sit below access and content findings for that reason.
• AI crawlers. GPTBot, ClaudeBot, PerplexityBot and OAI-SearchBot fetch HTML and do not execute JavaScript. Layout shift, blocking time and render-blocking resources are irrelevant to what they read; time to first byte, response size and how much content is in the initial HTML are what cross over. A site can be slow for people and perfectly readable by AI assistants, or fast for people and empty for them. The run keeps the two separate.

Where performance matters most is the audience that already arrived: engagement and conversion. That is how the board brief frames it.