Core Web Vitals on Umbraco: How This Site Scores Green

The scores

Most Umbraco sites don't fail Core Web Vitals because Umbraco is slow. They fail because nobody made performance a decision during setup - it became cleanup work three months after launch, squeezed in between client requests.

KindbergCo.com runs on the KindbergCo Umbraco Platform with minimal deviation from the base build. So instead of talking about performance in the abstract, here is what PageSpeed Insights actually reports for it, tested Aug 24, 2026 (Lighthouse lab data).

Desktop

• Performance: 100

• Accessibility: 100

• Best Practices: 100

• SEO: 100

• Agentic Browsing: 2/2

• First Contentful Paint: 0.4s

• Largest Contentful Paint: 0.7s

• Total Blocking Time: 10ms

• Cumulative Layout Shift: 0.004

• Speed Index: 0.5s

Mobile

• Performance: 91

• Accessibility: 100

• Best Practices: 100

• SEO: 100

• Agentic Browsing: 2/2

• First Contentful Paint: 1.7s

• Largest Contentful Paint: 3.3s

• Total Blocking Time: 0ms

• Cumulative Layout Shift: 0.004

• Speed Index: 2.8s

Desktop is clean across the board. Mobile is strong but not perfect - more on that below, because pretending otherwise would defeat the point of a post about honest measurement.

One more thing worth stating plainly: this is lab data, not field data. PageSpeed Insights currently shows no Chrome UX Report data for this site - the real-user dataset Google actually uses for the Core Web Vitals ranking signal. That is normal for a lower-traffic site; CrUX needs a meaningful volume of real Chrome visits before it reports anything. Lab scores from Lighthouse are the right tool for engineering decisions during development. They are not the same claim as "this site passes Google's Core Web Vitals assessment," which requires field data.

What "green" actually means here

The three metrics Google treats as Core Web Vitals are LCP (loading), INP (interactivity - Total Blocking Time is the closest lab proxy), and CLS (visual stability). On mobile, two of the three are effectively perfect: CLS is 0.004, and TBT at 0ms is well inside the "good" band. The one still sitting in the yellow is LCP, at 3.3 seconds against Google's 2.5-second threshold for "good."

That is the honest scorecard: layout stability and interactivity are solved. Loading speed on mobile networks is good, not yet green. Both facts matter more than a single headline number.

What's actually producing these numbers

None of this is accidental, and none of it is magic. It is a specific set of implementation decisions built into the platform before a single page of client content exists.

• Caching and static asset headers. Distributed caching patterns and static file cache headers mean repeat requests are not re-computing or re-fetching what has not changed. This is most of why Speed Index on desktop is 0.5 seconds.

• Minified CSS and JavaScript. Using Tailwind, we can reuse the css across many components, which saves a lot of CSS code, hence loading speed.

• Responsive image handling. Images are served sized to their context instead of a single oversized master file scaled down in the browser. This is also the most likely lever left to pull for mobile LCP.

• Semantic markup and structured headings. These feed the 100 Accessibility and 100 Best Practices scores, and are part of why this is not a case of gaming a Lighthouse number.

• SEO groundwork. Canonical URLs, sitemap generation, robots.txt handling, and metadata fields are the platform default - a short SEO tuning pass on this page took it from 92 to 100.

• Dynamic script loading per block. There is an option to dynamically load scripts. A block that needs a slider (SplideJS) or interactive behavior (AlpineJS) loads its own scripts. A page without that block does not pay for it. If you have a page where certain blocks require heavy libraries, the specific pages may load these, and not cause delay on every page.

Accessibility and Best Practices land at 100 on both mobile and desktop. Those are not network-dependent the way loading speed is - they are a function of markup and code, so they do not degrade on a slower connection the way LCP does.

PageSpeed Insights also now scores a fifth category: Agentic Browsing, Google's measure of how well a page works for AI agents rather than human visitors. KindbergCo.com scores 2/2 on both desktop and mobile - and it costs nothing extra, because the checks behind it (a properly formed accessibility tree, layout stability) are the same semantic markup and CLS discipline already covered above. This is not a separate initiative. It is the same decisions paying out twice.

Where it is still not green: mobile LCP

3.3 seconds against a 2.5-second target is a real gap. Largest Contentful Paint is almost always the render time of the single largest visible element - typically a hero image or a large text block above the fold - under simulated mid-tier mobile network and CPU conditions. Desktop LCP on the same page is 0.7 seconds, which tells you this is not a server response-time problem; it is a bandwidth and image-payload problem specific to constrained connections. For this platform, it's  also the fact that we are loading two different fonts, which adds to this delay.

The platform gives the tools to close that gap - responsive image handling, dynamic loading, caching - but the platform cannot decide how large a hero image an editor uploads, or which page gets the scrutiny. That is the honest boundary between what a foundation solves by default and what still depends on the specific build.

Why this matters if you are evaluating the platform

Every one of the numbers above is a byproduct of decisions made once, at the platform level, instead of re-litigated on every project: how CSS and JS are bundled, how images are served, how caching headers are set, how markup is structured. That is the actual value - not a single flattering Lighthouse score, but hundreds of hours of those decisions already made, tested, and running in production on kindbergco.com itself.

Starting a new Umbraco build from a blank installation means making all of those calls again, under a deadline. Starting from the KindbergCo platform means performance is a starting condition, not a fire drill. If you want to know how your own Umbraco site actually measures, get in touch using the form below.