Migrating from IISpeed: what stays, what changes

IISpeed is now maintained as mod_pagespeed for IIS, the native IIS module that mod_pagespeed 2.1 ships. The IIS installer is version 1.15.0 of mod_pagespeed 2.1's IIS package. Customer-facing, the change is smaller than it sounds: same optimization library underneath, same configuration directives, free license transfer. This page is the practical walkthrough for moving an existing IISpeed install across.

What actually changed

IISpeed shipped as a standalone Windows installer with its own version cadence. mod_pagespeed 2.1 ships a native IIS module. The IIS binary is maintained from IISpeed's IIS integration: the same configuration directives, filters, and cache format. See the IISpeed successor page on modpagespeed.com for the longer write-up.

What stays the same

• Your license. Existing IISpeed license keys transfer to mod_pagespeed 2.1 at no cost. Transfer your license with the order number or the email address the license was bought under, and we confirm the transfer — handled manually, usually within a business day or two. The line is open source now, so no token is needed to keep running.
• The configuration directives. The filter names, rewrite levels, and per-site settings carry over byte-for-byte. A working IISpeed pagespeed.config drops straight into the mod_pagespeed for IIS install. We have not renamed any public-facing directive.
• The filter set. The same filters do the same work: recompress_images, convert_jpeg_to_webp, resize_images, prioritize_critical_css, lazyload_images, insert_image_dimensions, defer_javascript, combine_javascript, extend_cache, and the rest of the published filter list.
• The admin console URL. Runtime stats live at /pagespeed_global_admin in mod_pagespeed for IIS, the same path the recent IISpeed builds used.

What changes

• The installer name. The MSI is pagespeed-iis-1.15.0-win-x64.msi rather than the old IISpeed-x.y.z.msi. It registers under a different ProductCode, which is why the migration involves an uninstall step (below).
• The documentation URL. All iispeed.com/documentation/* URLs 301 to the corresponding page on modpagespeed.com/docs/. Bookmarks keep working; the canonical location moved.
• The release cadence. IISpeed's standalone installer cadence is gone. The IIS module gets its own QA cycle in the release pipeline.

The migration, in order

1. Note your current configuration

Before you uninstall anything, save your IISpeed configuration files. Configuration lives in plain-text pagespeed.config files: a machine-global file under %ProgramData%\We-Amp\PageSpeed\pagespeed.config (older IISpeed installs used the IISWebSpeed directory and the iiswebspeed.config name there), plus a per-site pagespeed.config in each site's root folder; the module only optimizes a site that has one. Copy them verbatim into a safe place. You will merge them back after installing mod_pagespeed for IIS.

2. Optionally drain the cache

IISpeed and the IIS module use the same on-disk cache format, so the default path is to leave the cache directory in place; the module reads it as-is. Drain only if you are also changing rewrite levels in the same change window and want to verify the new behaviour from scratch: stop IIS, delete the contents of the cache directory (default C:\ProgramData\IISpeed\cache), and restart.

3. Uninstall IISpeed

Control Panel → Programs and Features → uninstall IISpeed. The uninstaller removes the native module registration from IIS and deletes the program files; it leaves the cache directory and configuration files in place. An iisreset at the end guarantees no worker process is still holding the old module.

4. Install mod_pagespeed for IIS

Download the IIS MSI from the modpagespeed.com download page — pagespeed-iis-1.15.0-win-x64.msi — and run it on the Windows Server box. The installer registers the native module, seeds a default pagespeed.config, and creates the program files. A second iisreset picks up the new module.

5. Merge your configuration back

Open the new pagespeed.config and merge in the IISpeed configuration you saved in step 1. The directives are identical, so the lines carry over without editing. Where a per-site pagespeed.config exists next to a site's content, its settings apply on top of the machine-global file for that site; restore those too. If you ran IISpeed with a custom cache path, keep the path; the module reads the existing cache directory without rewriting it.

6. Confirm the install

Browse to https://your-site/pagespeed_global_admin on the server itself (the admin console is bound to localhost by default; open it from a browser running on the Windows box, or relax the bind in the module configuration if you need it remotely). The admin console reports the active filter set so you can confirm everything wired up — no license token is involved any more.

7. Verify the response stream

From a separate machine, request a page that has an image-heavy above-the-fold section:

curl -sI -H "Accept: image/webp,image/avif,*/*" https://your-site/hero.jpg

A successful install returns a Content-Type of image/webp (or image/avif if the module produced an AVIF variant) and an X-Page-Speed response header carrying the module's version string. If you still see image/jpeg, the module loaded but the rewrite did not run; see troubleshooting below.

Troubleshooting the common stumbles

The module loaded but pages are not optimized

Three usual suspects: rewrite level set to PassThrough (default during install; flip it to CoreFilters or your prior IISpeed level); a Disallow directive that excludes the site root; or the IIS application pool running under an identity that cannot write to the cache directory. The admin console's Statistics tab tells you which one: low or zero image_rewrites and image_webp_rewrites means the rewrite never ran; non-zero resource_url_domain_rejections points at a Disallow or domain-allowlist mismatch.

"Module DLL could not be registered"

Almost always an IISpeed remnant: the old native module is still registered in applicationHost.config even though the program files are gone. Search for name="IISpeedModule" in the config, remove the line, run iisreset, and re-run the 1.15 MSI.

Cache directory permission errors after install

If you moved the cache to a non-default path, the new installer does not know about it. Grant the account IIS uses write access to the directory, or move the cache back under C:\ProgramData\mod_pagespeed\cache.

Rollback path

If something goes sideways, the previous IISpeed MSI installer is the rollback. Uninstall mod_pagespeed for IIS, reinstall the IISpeed MSI you held onto, and paste your configuration back. The license transfer is non-destructive on our end: your IISpeed license key remains valid for the IISpeed binary, so reverting does not require a second support ticket. Once you are stable on mod_pagespeed for IIS, you can discard the old installer.

When ASP.NET Core is part of the picture

If you are also moving an ASP.NET Core application off IIS toward Kestrel-only deployment, the IIS module is the wrong layer to carry forward. The WeAmp.PageSpeed.AspNetCore NuGet package wraps the same optimization library as middleware that runs inside the ASP.NET Core pipeline: no IIS, no separate module. Our ASP.NET Core on IIS post covers the architectural shape; the migration itself is a different path than the one on this page.

Where to get help

License transfers go through the transfer form; migration questions go to info@we-amp.com. We read every mail; we do not run an outbound sales team and we do not gate anything on a sales call. If you want to measure the IIS module against your own pages before committing, install and run it — the line is open source under Apache-2.0, free in development and in production. What We-Amp sells is support — and hardened builds.