ASP.NET Core performance, optimized at the server layer

The category .NET never had

Response compression shrinks text bytes on the wire. A CDN moves bytes closer to the user. Both are real wins, and both leave the page contents unchanged: the JPEG is still a JPEG, the stylesheet still blocks first paint, the unsized image still shifts the layout. A server-side optimizer works one layer down. It rewrites the response itself — it transcodes the image to a smaller format, extracts the above-the-fold CSS and defers the rest, and adds a content hash so a repeat visit skips the network. That category has existed for nginx and Apache since 2010. On .NET it has been a blind spot.

ModPageSpeed 2.0 went GA on 2026-05-17, and its ASP.NET Core middleware shipped the same day. It runs the same optimization worker the 2.0 nginx module uses, wrapped as an in-process middleware so it lives inside your .NET app instead of in front of it.

Two ways to run it on the Microsoft stack

AVIF transcoding and variant-aware caching are ModPageSpeed 2.0 features. The native IIS module on the 1.15 line does WebP, not AVIF. How the C# image pipeline works →

Wiring it into Program.cs

Add the package, then register the middleware early in the pipeline so it wraps the responses your endpoints produce.

dotnet add package WeAmp.PageSpeed.AspNetCore

// Program.cs
using WeAmp.PageSpeed.AspNetCore;

var builder = WebApplication.CreateBuilder(args);

// Binds the "PageSpeed" section from IConfiguration (appsettings.json,
// env vars, user secrets).
builder.Services.AddPageSpeed();

var app = builder.Build();

// Optimize responses before they leave Kestrel. Put it early in the
// pipeline, before anything that writes the response body.
app.UsePageSpeed();

app.MapStaticAssets();
app.MapRazorPages();

app.Run();

That is the whole integration for the common case. Optimization runs out of band: a worker process starts automatically alongside your app, reads originals from a shared cache, generates up to 37 variants per image (format, viewport, pixel density, and Save-Data), and writes them back. The middleware serves the matching variant per request. The trade-off is that the first request for a URL returns the original while the worker builds the variants in the background; subsequent requests serve the optimized version from cache. Worker flags and per-transform switches live in the configuration reference.

What server-side optimization fixes — and what it does not

A server-layer optimizer attacks the load-time costs that sit below your application code: byte weight, render-blocking resources, image delivery, and caching. It does not touch your JavaScript runtime behavior. The table maps the common PageSpeed Insights findings to what the middleware actually does, scoped honestly.

ASP.NET Core performance: common questions

How do I improve PageSpeed on ASP.NET Core?

Optimize the response after Kestrel renders it, the same way nginx and Apache shops have for years. Add the WeAmp.PageSpeed.AspNetCore middleware with one dotnet add package; it transcodes images to WebP and AVIF, resizes them to their rendered size, inlines critical CSS, minifies CSS and JavaScript, and cache-extends static assets. Response compression and a CDN move bytes faster but do not change what those bytes are; this middleware changes the bytes.

Is there an ASP.NET Core image optimization middleware?

Yes. WeAmp.PageSpeed.AspNetCore is an in-process ASP.NET Core middleware for ModPageSpeed 2.0, published and indexed on nuget.org. It transcodes JPEG, PNG, and GIF to WebP and AVIF, resizes images to their rendered display size, and serves the right variant per request from a shared cache. The native worker is bundled per runtime identifier (linux-x64, linux-arm64, osx-arm64, win-x64), so a single dotnet add package installs everything — no separate native module to compile or register.

What is the IIS PageSpeed module?

mod_pagespeed 1.15 ships as a native IIS module on Windows, installed from a signed MSI. It loads into the IIS pipeline in-process and applies the classic filter set — WebP image transcoding, critical-CSS inlining, CSS and JavaScript minification, and content-hashed cache extension — using the same configuration the Apache and nginx modules use. It continues the engine that powered IISpeed: the IISpeed codebase was adopted into the 1.15 IIS port and put through a numbered set of security-hardening fixes as a merge gate before release.

I have an IISpeed license. What do I move to?

IISpeed is deprecated, and its license transfers free to mod_pagespeed 1.15 or ModPageSpeed 2.0. If you want to stay on classic IIS, install the signed IIS MSI for 1.15. If you are on ASP.NET Core, the WeAmp.PageSpeed.AspNetCore NuGet middleware is the documented path. The 1.15 IIS port adopted the IISpeed codebase wholesale, so the optimization behavior is the one you already ran.

Will a server-side optimizer fix my INP or layout shift?

Not directly. INP is dominated by your own JavaScript main-thread work — event handlers, Blazor interactivity, hydration — which a server-layer optimizer does not rewrite. Layout shift (CLS) from injected content or late-loading fonts is also application-level. What the middleware fixes reliably is byte weight, render-blocking CSS, image delivery, and caching: the load-time costs that sit below your application code. It will not make a slow click handler fast.

Does it work outside IIS, on Linux or in containers?

Yes. WeAmp.PageSpeed.AspNetCore runs wherever ASP.NET Core runs: the native worker is bundled for linux-x64, linux-arm64, osx-arm64, win-x64, so the same middleware works on Linux containers, Windows, and macOS development machines. It does not require IIS. The signed IIS MSI is a separate option for teams running classic IIS who want a native module rather than middleware.