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. 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
Section titled “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 a headless browser with a desktop viewport, a standard 4× CPU slowdown 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, through the Chrome UX Report: the 28-day 75th-percentile LCP, CLS, INP and TTFB for the origin, and for one representative page per template where data is available. Field data describes real-user experience; lab data helps diagnose controlled conditions. A disagreement warrants investigation of scope, device, location and timing.
How it is reported
Section titled “How it is reported”The Performance view of a site’s Templates tab shows the origin figures, then one row per template with each figure coloured by the relevant metric’s published band (good, needs improvement, poor). Opening a row shows the causes: the LCP element, the shift source, third-party hosts, the largest resources.
Findings go through the same review as every other finding and become Foundations plays, or evidence on a Fix a page play when the slow template serves one of your topics. 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
Section titled “What performance does and does not affect”Two things are easy to overstate, and the knowledge base keeps them in proportion:
- Ranking. Google recommends good Core Web Vitals alongside other aspects of page experience. A good score does not guarantee a high ranking. TTFB is a diagnostic metric, not a Core Web Vital.
- AI retrieval. Response failures, latency and missing initial HTML can affect what a fetcher receives. Different retrieval paths have different capabilities; Core Web Vitals describe user experience and do not establish citation outcomes. The run keeps readability and observed citations separate.
Where performance matters most is the audience that already arrived: engagement and conversion.
Investigate a lab-field gap
Section titled “Investigate a lab-field gap”Read Lab vs field Core Web Vitals for a diagnostic sequence and the limits of comparing a controlled test with real-user data.