Compression is one of the cheapest performance wins on an IIS-hosted site, and it is also one of the most commonly left on the default. Windows Server ships IIS with static and dynamic compression modules that support gzip out of the box, while Brotli only arrives through cross-platform .NET hosting or third-party modules. Choosing between gzip and Brotli, and between static and dynamic compression, changes payload size by 15\u201325% on typical text assets and CPU load by a similar magnitude in the other direction. This article covers how to enable both, when each makes sense, and how to verify the win.<\/p>\n
The two modules are not interchangeable and they do not share a cache.<\/p>\n
%SystemDrive%\\inetpub\\temp\\IIS Temporary Compressed Files<\/code>. Cheap at request time because the work is already done. Ideal for CSS, JS, HTML, and JSON that does not change per request.<\/li>\n- Dynamic compression:<\/strong> Compresses each response in memory as it is generated. Hits the CPU on every request but works for anything \u2014 including API responses that never exist as a file. More expensive, so keep it scoped to the MIME types that benefit.<\/li>\n<\/ul>\n
The classic mistake is enabling dynamic compression for image\/*<\/code> and video\/*<\/code>. Already-compressed formats get bigger after gzip and you pay CPU for the privilege. Restrict dynamic compression to text and JSON.<\/p>\nEnabling gzip Compression<\/h2>\n
Install the modules and configure them from an elevated PowerShell session:<\/p>\n
Install-WindowsFeature -Name Web-Dyn-Compression, Web-Stat-Compression\n\nImport-Module WebAdministration\n# Dynamic: only text-like types\nSet-WebConfigurationProperty -PSPath 'IIS:\\' `\n -Filter \"system.webServer\/httpCompression\" `\n -Name \"dynamicTypes\" -Value @{mimeType='application\/json'}\nAdd-WebConfigurationProperty -PSPath 'IIS:\\' `\n -Filter \"system.webServer\/httpCompression\/dynamicTypes\" `\n -Name \".\" -Value @{mimeType='text\/html'}<\/code><\/pre>\nAlso set dynamicCompressionLevel<\/code> (1\u20139, default 0 which means no dynamic compression unless a level is set) and the static compression equivalents. Level 4\u20135 is the usual balance point; above 7 the CPU cost stops paying for the marginal size reduction.<\/p>\nWhere Brotli Comes From<\/h2>\n
IIS itself does not ship a Brotli compression module. You get Brotli in one of three ways:<\/p>\n
\n- .NET hosting with response compression middleware:<\/strong> ASP.NET Core’s
ResponseCompression<\/code> middleware supports Brotli natively. Add BrotliCompressionProvider<\/code> and it negotiates Brotli for clients that advertise br<\/code>, falling back to gzip.<\/li>\n- A reverse proxy:<\/strong> Nginx in front of IIS compresses with Brotli via
ngx_brotli<\/code>, offloading the work from IIS entirely.<\/li>\n- Third-party IIS modules:<\/strong> Community Brotli providers exist but add a maintenance dependency; evaluate before adopting.<\/li>\n<\/ul>\n
\/\/ ASP.NET Core Program.cs\nbuilder.Services.AddResponseCompression(o =>\n{\n o.EnableForHttps = true;\n o.Providers.Add<BrotliCompressionProvider>();\n o.Providers.Add<GzipCompressionProvider>();\n o.MimeTypes = ResponseCompressionDefaults.MimeTypes.Concat(\n new[] { \"application\/json\", \"image\/svg+xml\" });\n});<\/code><\/pre>\nBrotli typically beats gzip by 15\u201320% on HTML and JSON at equivalent CPU. For a text-heavy site that adds up to real bandwidth savings. The configuration choices here sit alongside the broader IIS tuning covered on windows-vps.org<\/a> if you want to see how compression fits the rest of a hosting stack.<\/p>\nChoosing the Right Setting<\/h2>\n
A pragmatic policy that covers most sites:<\/p>\n
\n- Static gzip: on for
text\/*<\/code>, application\/javascript<\/code>, application\/json<\/code>, image\/svg+xml<\/code>.<\/li>\n- Dynamic gzip: on only for JSON and generated HTML; leave off for images and fonts.<\/li>\n
- Brotli: prefer it for dynamic responses when you control the app framework or run a proxy; let gzip remain the fallback.<\/li>\n
- Never compress already-compressed binaries \u2014 check that
Content-Encoding<\/code> is not applied to PNG, JPEG, WebP, MP4, or WOFF2.<\/li>\n<\/ul>\nVerifying the Win and Watching CPU<\/h2>\n
Do not assume compression is working \u2014 check it. From a client, request an asset and inspect the headers:<\/p>\n
curl -sI -H \"Accept-Encoding: gzip, br\" https:\/\/example.com\/ | findstr \/i \"content-encoding content-length\"<\/code><\/pre>\nYou want to see Content-Encoding: br<\/code> or gzip<\/code> and a reduced Content-Length<\/code>. Then watch the server side: add the % Processor Time<\/code> and Requests\/sec<\/code> counters in Performance Monitor and compare before and after under load. On a memory-constrained Windows VPS, dynamic compression is a trade of RAM and CPU for bandwidth \u2014 if the box is already CPU-bound at peak, enabling it will hurt more than it helps. For most read-heavy sites, static compression alone delivers the bulk of the benefit at almost no runtime cost, and it is the safest place to start before reaching for Brotli.<\/p>\nCompression Safety Nets and Common Pitfalls<\/h2>\n
A few failure modes catch teams out after they enable compression. Double compression is the first: if a CDN or reverse proxy already compresses a response and IIS compresses it again, the payload grows and clients may reject it. Pick one layer to own the job \u2014 usually the edge \u2014 and disable compression upstream where it overlaps. The second is stale static caches: when you update a CSS or JS file, IIS may keep serving the old compressed copy from its temporary folder until the source timestamp changes, so bump the file mtime during deploys. The third is TLS interaction \u2014 do not enable compression on responses containing secrets, because the old BREACH-style attacks exploit the size difference that compression introduces. Finally, watch the temporary compressed-files folder on a small VPS; it can grow quietly and consume system-drive space, so point it at a data volume or cap its size. Locking down the surrounding IIS surface, including the request-filtering and header settings that travel with these tuning changes, is covered in the server hardening notes on windows-vps.org<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"