PageSpeed optimization, native in your .NET pipeline
The ModPageSpeed engine — proven across nginx, Apache, and Envoy since 2012 — now runs as ASP.NET Core middleware. Same C/C++ optimization libraries, delivered as a NuGet package. No CDN. No proxy. No external service.
14 years in production
The engine traces back to Google's mod_pagespeed. Over a decade of continuous production use across millions of sites.
6 server platforms, 1 engine
Apache, nginx, IIS, Envoy, Apache Traffic Server, and now ASP.NET Core. The same native engine, proven across every major architecture.
Zero external services
Runs entirely in-process. Your HTML, images, and CSS never leave your infrastructure. No CDN dependency, no vendor lock-in.
The optimization engine .NET never had
CDN-based optimization tools sit between your server and your visitors. They cache aggressively, add latency hops, and require you to hand your traffic to a third party. Build-time tools catch some of it, but they can't rewrite HTML at request time or generate responsive image variants on demand.
ModPageSpeed does both. It rewrites HTML, optimizes images into WebP and AVIF, extracts critical CSS, minifies scripts, injects lazy loading, and generates responsive srcsets — all at request time, inside your pipeline. The same engine has been doing this on web servers since 2012. Now it runs as ASP.NET Core middleware.
Capabilities
What ModPageSpeed does in your pipeline
On-the-fly HTML rewriting
Responses are rewritten in real time as they flow through the pipeline. Images get lazy-loading attributes, CSS is inlined or deferred, JavaScript is deferred — without changing your source code or build process.
Visitor-aware optimization
Every request is classified into a capability mask: image format support, viewport size, device density, Save-Data preference, and encoding support. Each visitor gets a response optimized for their specific browser and connection — not a one-size-fits-all version.
Learned quality prediction
Per-format ML models (LightGBM, compiled to C) predict the optimal encoder quality for each image based on 17 content features. Targets a perceptual quality score (SSIMULACRA2) instead of a fixed quality number — 12-18% smaller files at equivalent visual quality. ~5µs inference, zero runtime dependencies.
Automatic image format negotiation
Serves WebP or AVIF to browsers that support them, JPEG to those that don't — decided per-request from Accept headers. Combined with viewport-aware sizing, each visitor gets the smallest possible payload.
Critical CSS extraction
The engine parses your HTML, identifies above-the-fold CSS, inlines it, and defers the rest. Eliminates render-blocking CSS — the single biggest contributor to poor Largest Contentful Paint scores. No build step, no manual auditing.
Memory-mapped cache serving
Optimized responses are memory-mapped from the native Cyclone cache and served with minimal managed allocations. No GC pressure on the hot path. Under load, cache hits are fast and predictable.
WeAmp.PageSpeed.AspNetCore
Console
See every cached variant
The ModPageSpeed console shows exactly what's cached for each URL: format, viewport, density, Save-Data, encoding, content type, size, and quality score. Every variant is visible and inspectable.
Integration
One line in Program.cs
using WeAmp.PageSpeed.AspNetCore;
var builder = WebApplication.CreateBuilder(args);
// Reads PageSpeed config from appsettings.json
builder.Services.AddPageSpeed(builder.Configuration);
var app = builder.Build();
app.UsePageSpeed();
app.MapStaticAssets();
app.MapRazorPages();
app.Run();Standard ASP.NET Core middleware. IServiceCollection registration, IApplicationBuilder pipeline, appsettings.json with hot reload via IOptionsMonitor. No custom abstractions, no external processes.
Architecture
Native performance inside a managed pipeline
The PageSpeed middleware intercepts responses in your ASP.NET Core pipeline. When a request hits an HTML page, the engine parses the response body and applies optimization filters: inlining critical CSS, rewriting image URLs to optimized variants, minifying scripts, and injecting lazy-load attributes. On a cache hit, the optimized response is served directly from a memory-mapped file with minimal managed allocations.
Under the hood, the optimization engine is the same C/C++ code that
powers ModPageSpeed on nginx, Apache, and Envoy — over a decade of
production hardening. The .NET layer communicates with it through
source-generated [LibraryImport]
P/Invoke bindings, fully NativeAOT compatible. No managed
reimplementation. The HTML rewriter, image optimizer, critical CSS
extractor, and minifier all run as native code.
Integration follows standard ASP.NET Core conventions:
AddPageSpeed()
registers services via dependency injection, configuration binds to
appsettings.json with hot reload through IOptionsMonitor, and the health
check endpoint plugs into ASP.NET Core's health check system. The same
configuration works on Kestrel, behind IIS, on Azure App Service, or in
a container.
Built by the maintainer of Google's mod_pagespeed
We-Amp has been shipping PageSpeed optimization since 2012 — first on IIS through IISpeed, then across nginx, Apache, Envoy, and Apache Traffic Server through ModPageSpeed 2.0. The ASP.NET Core middleware brings the same native engine into the .NET pipeline, without the web server dependency.
IISpeed heritage
PageSpeed on IIS since 2012.
6 platforms, 1 engine
Apache, nginx, IIS, Envoy, ATS, ASP.NET Core.
ML-tuned compression
Trained models predict optimal quality per image.
Roadmap
What's next
The same native middleware architecture extends beyond PageSpeed. These packages share the same P/Invoke foundation, configuration model, and pipeline integration.
Ship with native performance
WeAmp.PageSpeed.AspNetCore is available for early access.
Questions? info@we-amp.com