A slow server is rarely why an ASP.NET Core site fails Core Web Vitals. In almost every audit we run, the server responds in under 200 ms and the page still takes four seconds to become useful — because of what happens in the browser afterwards.
Here is what each metric actually measures, and where the time really goes.
LCP — Largest Contentful Paint
LCP is the moment the biggest visible element — usually a hero image or headline block — finishes rendering. Google wants this at 2.5 seconds or less for 75% of real visits.
The time breaks down into four parts, and they are worth separating because the fix is different for each:
| Phase | Typical culprit | Fix |
|---|---|---|
| Time to first byte | Slow query, cold start, no caching | Index the query, cache the result |
| Resource load delay | Hero image discovered late | preload the hero, avoid CSS background images for LCP |
| Resource load time | 2 MB uncompressed JPEG | WebP/AVIF, correct dimensions, CDN |
| Render delay | Blocking CSS and fonts | Inline critical CSS, font-display: swap |
The hero image mistake
The single most common LCP failure we see: the hero image is set as a CSS background-image. The browser cannot discover it until the stylesheet has downloaded and parsed, which pushes the LCP candidate a full second later than an <img> tag would. Use a real <img> with loading="eager" and fetchpriority="high" for the first slide, and lazy-load everything below the fold.
INP — Interaction to Next Paint
INP replaced First Input Delay. It measures the worst-case lag between a user interacting and the screen updating, across the whole visit. Target: 200 ms or less.
This is a JavaScript problem, effectively always. The usual causes:
- A carousel, chat widget and analytics tag all initialising on
DOMContentLoaded, blocking the main thread while the user is already tapping. - Event handlers doing layout-thrashing work — reading
offsetHeightin a loop that also writes styles. - Third-party tag managers loading scripts you have forgotten are there.
Defer everything that is not needed for the first paint. A chat widget that loads three seconds after interactive costs you nothing in conversions and can save you 300 ms of INP.
CLS — Cumulative Layout Shift
CLS scores how much visible content jumps while the page loads. Target: 0.1 or less. It is the easiest of the three to fix and the most commonly ignored.
- Set
widthandheightattributes on every image and iframe, even when CSS resizes them — the attributes give the browser an aspect ratio to reserve space with. - Reserve space for banners, cookie bars and ad slots with a fixed
min-height. - Preload web fonts, or accept a fallback with a similar metric so text does not reflow when the real font arrives.
- Never insert content above existing content after load.
Where ASP.NET Core specifically helps
The server-side wins are real, even if they are not usually the bottleneck:
- Response compression — Brotli on HTML, CSS, JS and JSON typically cuts transfer size by 70–80% versus uncompressed.
- Output and data caching — a page that does not hit SQL Server on every request has a far more predictable TTFB.
- Versioned static assets — a fingerprint in the URL lets you serve a one-year
Cache-Controlsafely, so repeat visits download almost nothing. - HTML minification in production only — smaller documents, while development keeps readable markup.
We walk through the exact configuration for all four in Brotli, HTML minification and cache headers. On the data side, query cost matters more than most people expect — which is part of why we use Dapper rather than Entity Framework on high-throughput projects.
How to measure it honestly
Lighthouse in Chrome DevTools is a lab test on your machine and your connection. It is useful for debugging and useless as a verdict. What Google actually uses is field data from the Chrome User Experience Report — real visits, real devices. Check both:
- PageSpeed Insights — shows field data at the top, lab data below. Trust the top half.
- Search Console → Core Web Vitals report — groups URLs by issue, which tells you what to fix first.
- Throttle to Slow 4G in DevTools before you declare anything fixed.
Core Web Vitals sit inside a larger technical picture — crawlability, canonicals, structured data and internal linking all still matter. Our technical SEO checklist covers the rest of it.
If your site is failing these metrics and you would rather hand it to someone, performance work is part of our .NET Core development and website design engagements, and of ongoing SEO optimization. Get in touch with your URL and we will send back the field data and the three fixes we would make first.