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 package ships from the 1.15 packaging channel. 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. The IIS package ships from the 1.15 packaging channel. 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. Send the key to info@we-amp.com 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-vhost settings carry over byte-for-byte. A working IISpeed applicationHost.config snippet 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 package ships from the 1.15 packaging channel. 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, grab the IISpeed configuration block out of %SystemRoot%\System32\inetsrv\config\applicationHost.config, or your per-site web.config if you scoped IISpeed per-application. Copy the <ModPagespeed> section verbatim into a text file. You will paste it 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 modpagespeed.com/1.1/ and run it on the Windows Server box. The installer registers the native module, drops a default ModPagespeed block into applicationHost.config, and creates the program files under %ProgramFiles%\mod_pagespeed. A second iisreset picks up the new module.

5. Paste your configuration back

Open the new applicationHost.config, replace the default <ModPagespeed> block with the IISpeed configuration you saved in step 1, and reload IIS. The directives are identical, so nothing in the block needs editing. 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-Mod-Pagespeed response header carrying the 1.15 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 and 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.