IIS Core Web Vitals in 2026: a practical workflow

Most Core Web Vitals advice assumes a Linux box, a modern build pipeline, and a static-site generator. None of that is true on a typical IIS site. Classic ASP.NET, WebForms, and SharePoint applications render HTML on the fly, source images from a CMS, and ship CSS that nobody on the team has touched in years. This page is the playbook We-Amp uses when we sit down with an IIS shop and ask: what would actually move LCP, CLS, and INP here, and in what order.

1. Measure first, with two clocks

You need both a synthetic clock and a field clock. The synthetic clock — Lighthouse, PageSpeed Insights, WebPageTest — gives you a repeatable score against a known network and CPU profile. The field clock — the Chrome User Experience Report (CrUX), or your own web-vitals beacon — gives you the percentile distribution of what real users on real Windows-hosted endpoints actually see.

On IIS sites the two clocks usually disagree more than they should. The synthetic score for a logged-out cached page can look fine while p75 LCP from CrUX sits around four seconds. The gap is almost always one of three things: image weight, render-blocking CSS, or a slow first byte on the first authenticated request. Identify which of the three is dominant before touching anything.

2. The four optimizations that actually move IIS metrics

Once you know which clock is lying and why, the work itself is unglamorous:

2.1 Image optimization (LCP)

On classic ASP.NET sites, the LCP element is almost always a hero image served from the CMS at full source resolution as a JPEG. mod_pagespeed 1.1 does four things to that image without anyone changing the application: recompresses the JPEG to a sane quality target, generates WebP and AVIF variants and serves them via the Accept header, resizes the image to the dimensions it's actually rendered at, and caches every variant server-side. The net effect on a typical SharePoint or DotNetNuke front page is a hero image that goes from ~600 kB down to under 80 kB on modern browsers. That alone moves LCP into the green band on most pages.

2.2 Critical CSS (LCP, render-blocking)

The second-most-common LCP regression on IIS sites is a single large stylesheet that blocks first paint while the browser fetches it. The worker extracts the CSS rules that apply to the above-the-fold portion of the page, inlines them in the document head, and defers the rest of the stylesheet. First paint stops waiting on a round trip. On latency-bound clients — mobile, slow Windows-shared-hosting tail — the improvement is measurable in seconds, not milliseconds.

2.3 Lazy loading and JavaScript deferral (CLS, INP)

Cumulative Layout Shift on classic ASP.NET sites usually comes from late-loading images and ad slots pushing content down after first paint. Adding loading="lazy" to off-screen images, deferring non-critical JavaScript to after the load event, and reserving space for ad placeholders fixes most of it. The worker does all three at response time so the application code stays unchanged.

2.4 Content negotiation and the optimized cache (TTFB, repeat-view LCP)

Generating a WebP variant of a hero image once per request is wasteful. The worker keeps a server-side cache of optimized variants keyed off the source asset and the Accept header. Repeat requests for the same URL on the same browser combination hit cache; downstream CDNs see ordinary cacheable HTTP responses. This matters more on IIS than on nginx because Windows file I/O is meaningfully more expensive per operation than Linux page-cache reads — the optimized-variant cache is the difference between "fast" and "fast under load."

3. The migration question: stay on classic IIS, or move to ASP.NET Core

The IIS-shop conversation usually splits at this point. Teams running WebForms or SharePoint stay on classic IIS because a rewrite isn't feasible. Teams modernizing to .NET 8 or .NET 9 are already on ASP.NET Core with Kestrel and don't need the IIS module at all. We support both paths with the same PageSpeed Automatic optimization library:

• Stay on classic IIS: install mod_pagespeed 1.1 for IIS. It's a native HTTP module that ships as an MSI, plugs into the IIS request pipeline, and rewrites responses transparently to the application. It's the direct successor to IISpeed and the same configuration directives apply.
• Migrate to ASP.NET Core: add the WeAmp.PageSpeed.AspNetCore NuGet package. One app.UsePageSpeed() call in Program.cs wires the worker into the IApplicationBuilder pipeline. The middleware wraps the same PageSpeed Automatic library, repackaged for the ASP.NET Core idiom — no separate web server, no IIS dependency, equally happy behind Kestrel, in containers, or with IIS in front of it as a reverse proxy.

4. What this page does not claim

Some honest caveats, because the Core Web Vitals discourse has enough magical thinking already:

• The worker will not save a site that is fundamentally over-rendered. If your home page ships 4 MB of JavaScript before any content, the worker will defer it and lazy-load images, but you still have 4 MB of JavaScript. The application-side work is yours.
• mod_pagespeed is not a CDN. It optimizes responses; a CDN brings them closer. The two compose — most of our customers run both — but neither is a substitute for the other.
• We do not promise specific score deltas. Real sites vary too much. The documentation covers each filter, and the trial license lets you measure your own before/after.

5. Where to start

If you already have an IISpeed license, the free transfer to mod_pagespeed 1.1 takes a single email. If you're new to PageSpeed optimization on IIS, the trial is the fastest way to measure mod_pagespeed 1.1 against your own pages. If you're on ASP.NET Core, the WeAmp.PageSpeed.AspNetCore NuGet package is the right entry point — Preview today, with the same PageSpeed Automatic library underneath.

Questions, edge cases, or a site you'd like us to look at? Email info@we-amp.com. We read everything; we don't run an outbound sales team.