The three numbers
- LCP (Largest Contentful Paint). When the main thing on the page — usually a hero image or heading block — appears. Heavy images, slow hosting and render-blocking scripts are the usual culprits.
- INP (Interaction to Next Paint). How quickly the page reacts after a click or tap. Bloated JavaScript is the usual culprit.
- CLS (Cumulative Layout Shift). How much the page jumps as things load. Images without size, ads and late webfonts are the usual culprits.
Lab scores in Lighthouse are a hint. Field data — what real users on real phones saw — is what Google uses. Search Console’s Core Web Vitals report is the one that matters.
What is worth doing
Compress and size images. Do not ship three slider libraries for one banner. Reserve space for media so the page does not jump. Host close to users. Fix the worst URLs first; a site-wide rewrite for a 0.05 improvement on an already-green page is theatre.
What we change on an ASP.NET public site
Serve images at the size they display, preferably modern formats. Set width and height so the layout does not jump. Do not hide the H1 in a slider that loads last. Keep third-party scripts off the first paint — chat widgets and tag managers are frequent INP offenders. Cache static files; we already do that here with long cache headers on CSS, JS and images. Preconnect to the font host, or better, subset the fonts you actually use.
Then look at Search Console, not only Lighthouse on an office fibre connection. A page that is green on your laptop and red on a mid-range Android in Kerala is the page users have. Fix that URL before you redesign the homepage for a 2-point lab gain.
What is not worth a project
Rewriting a healthy site to chase a new Core Web Vitals threshold that moved last year. Blocking the launch of an internal tool because Lighthouse scored 78. Paying for a monthly “SEO package” that only reruns PageSpeed and sends a PDF. Vitals are a build concern on public pages. They are not a product strategy.
How to read Search Console without theatre
Open the Core Web Vitals report. Sort by the URLs that get impressions, not the ones that look important in a slide. A slow article that nobody searches is not this week’s job. A slow service page that already ranks on page two is. Mobile is the default view; desktop being green does not save you if Kerala phones are red.
Field data lags. You ship a fix on Monday; the report may take weeks to turn. Do not “optimise” again on Wednesday because the chart has not moved. Watch the URL Inspection / live test and real devices. Then wait for the field bucket to catch up.
Mobile, third parties, and the chat widget
The usual INP killer on a marketing site is not your Razor view. It is the chat bubble, the tag manager, the map embed that loads on every page, and a slider library for one banner. Load those after the main content, or drop them. A phone on mid-range Android in traffic does not care that the widget is “only 40kb gzipped”. It cares that the main thread is busy when the user taps Call.
CLS on article pages is often an embed or an image in the body without dimensions. Set width and height. Do not inject ads above a paragraph the reader already started. Those jumps are what the metric is for.
What “good enough” is on a business site
Public service pages that already get impressions should be in the “good” field bucket on mobile, or you should know why not — a third-party you refused to drop, a hero video, a host in another continent. Internal tools behind a login can be slower. Staff will complain in words, not in Search Console. Fix the slow query. Do not run Lighthouse as a gate on an ops screen.
A redesign that chases a 100 lab score while the H1 is still in a slider is the wrong order. Content and crawlable HTML first. Then images. Then third parties. Then the last five points. We would rather ship a green LCP on the money pages than a perfect homepage screenshot.
A short punch-list we actually run
Search Console: which URLs have impressions and a poor mobile LCP or INP. Those first. Images: real dimensions, modern formats, no hero that is a 4MB PNG. Scripts: chat and tags after first paint, or gone. Fonts: subset, or system fonts if the brand can live with it. Hosting: close to users, compression on, cache headers on static files — this site already ships those. Then wait for field data. Do not spend a month on a 2-point lab gain on a URL nobody searches.
If the site is a web application people work in, stop reading this page as a launch gate. Fix the slow query. The metric that matters is whether staff invent a spreadsheet beside it, not whether Lighthouse smiled.
Search Console field data is the argument that ends “but it is fast in the office”. Show the mobile URL that already has impressions. If it is poor, that is the sprint. If it is good, do not start a vitals project to fill a retainer. This site treats vitals as a build concern on public pages — cache headers, image sizes, third parties kept off the first paint — not as a monthly PDF. That is the useful version of the metric.
This work belongs on public websites. If you want it done as part of a build, it is in the web development service, not a separate package bolted on after launch.
ASP.NET pages that look fine and still fail INP
A Razor page that is “not much JavaScript” can still hitch if every layout loads a map, a chat, and a tag manager before the user taps Call. Move those behind the first paint or drop them on service URLs. A large table of portfolio items without width/height on images will shift the heading the crawler already saw. Fix the money URLs first — services, contact, the article that already has impressions — not the lab homepage.
We treat that list as part of the build, then we wait for Search Console. A second “vitals sprint” the next month, with no new field problem, is retainer theatre. Say no. If a new article template ships without image dimensions, fix the template — that is one change, not a vitals programme. The same is true of a new hero on the homepage: size it, or accept the CLS, before you book another Lighthouse pass. One template fix beats a month of PDFs that say the same three URLs are still poor.