Friday, February 6, 2015

Pagespeed for IIS: IISpeed 2.0 beta 1

The IISpeed 2.0 beta 1 is out for everyone to try, we would like you to try it.
Get it at This beta will expire April 1st 2015
IISpeed 2.0 is based on mod_pagespeed stable and has no limitations. You can now test all features, including IPRO.
There will be more news and releases the coming weeks. Be sure to follow us on twitterGoogle+, or linkedin to get the latest news
Changelist IISpeed 2.0 beta 1
  • A huge amount of features and improvements by upgrading to the new PageSpeed Optimization libraries. IISpeed went from 1.7 (beta) to (stable).
  • Fixes windows 10 IE/edge issue.
  • Configuration parser fixes and improvements.
  • Fixes warnings about invalid or non existing FileCachePath’s on some systems.
  • License file parsing improvements.
  • Fixes failed to stat ‘sites[xx]’ error messages (otherwise harmless).
  • Disabled some shared memory features.
  • Forbids enabling convert meta tags (as IISpeed doesn’t support it).
Important changes in 2.0
  • The admin urls and interface have changed, you can configure the admin interface by
    IISpeed StatisticsPath /iispeed_statistics
    IISpeed GlobalStatisticsPath /iispeed_global_statistics
    IISpeed MessagesPath /iispeed_message
    IISpeed ConsolePath /iispeed_console
    IISpeed AdminPath /iispeed_admin
    IISpeed GlobalAdminPath /iispeed_global_admin

    We will probably make one configuration option to set the root of the admin pages in the next version.
  • IPRO is now on-by-default, it is recommended that you disable IPRO at first and test your site with IPRO
    IISpeed InPlaceResourceOptimization off
  • There is a new rewrite level: OptimizeForBandwidth
    IISpeed RewriteLevel OptimizeForBandwidth
  • The shared memory cache is disabled in 2.0, which means:
    • There are no global statistics, only statistics per application pool
    • The internal messages page will show per application pool output instead of aggregating all output from all application pools.
      Performance for application pools served by multiple worker processes could be impacted by this, we would love to hear some feedback on this.
    • Stability when reloading configuration and recycling processes is improved.
    • Depending on your settings memory usage might increase if you run many websites on a single machine.
    • Memcached will still work.

Roadmap untill the final 2.0 release

  • Beta 2
    • A new installer based on WIX.
    • Better performing filecache.
  • Release 2.0
  • Release 2.x
    • IIS manager integration
    • Feature versions (IISpeed light versions which only do IPRO or CDN rewriting with a simple configuration)
If you have any questions or remarks, please mail them to

Wednesday, September 24, 2014

Optimizing for Bandwidth on Apache and Nginx (and soon IIS)

A post on Google's webmaster central blog by +Jeff Kaufman which explains a great new mode in PageSpeed optimization: OptimizeForBandwidth. As the blog post states, we are currently working on porting this new feature to IISpeed (and ats_pagespeed). 
Everyone wants to use less bandwidth: hosts want lower bills, mobile users want to stay under their limits, and no one wants to wait for unnecessary bytes. The web is full of opportunities to save bandwidth: pages served without gzip, stylesheets and JavaScript served unminified, and unoptimized images, just to name a few.

Full post:

Caching in IISpeed & mod_pagespeed

A cool in-depth blog post by +Joshua Marantz about how Google's PageSpeed SDK uses caching internally for optimization:

Tuesday, March 4, 2014

Accelerating A/B test results

Recently, We-Amp collaborated with Google and SunStar Media to conduct a test to measure the real-world effects of PageSpeed optimization with IISpeed on conversion rates and overall site speed. We used IISpeed to optimize the Visit Napa Valley site.

Read how much was accelerated by IISpeed at

Tuesday, February 18, 2014

Announcing IISpeed 1.1.6

New feature - In Place Resource Optimization:
A brand new optimization mode called In Place Resource Optimization (IPRO) is now ready to use. IPRO enables optimization of resources when they are served from their original URL’s, which makes optimizing assets loaded via AJAX possible. It is also a first step for a new mode called OptimizeForBandwidth, which targets hosting providers and enables a scenario where optimization can be on by default, without having to worry about breaking sites.

Currently IPRO is only available for registered customers.

Fixes and improvements:

  • IISpeed will now attempt to hook up as the very first to catch the incoming URL, before any other module or filter is able to modify it. This fixes issues when IISpeed is combined with (for example) IIS Url Rewrite.
  • Don’t respond with an http error status code to invalid requests on IISpeed’s beacon url. Most notably, this fixes an error message that might be displayed in Google’s Webmaster Tools regarding the “/x_iispeed_beacon” url. The beacon is used by some of IISpeed’s filters to determine which assets are needed for rendering above the fold, amongst other things.
  • Fix an issue where sometimes url() statements in optimized css would be left blank. Also see and
  • Reduce the verbosity of the X-PageSpeed & X-IISpeed headers we send out. Don’t send out patch level  / svn revision, just use the major version instead.

CDN + Google Page Speed Optimization = Awesomeness

Last week, we starting using a CDN on After setting up the DNS for, it took us about 10 seconds to add the required line to IISpeed's configuration file, to enable rewriting of all css, js, and images and route them via the CDN:
IISpeed MapRewriteDomain
That was all - it just works - great!

Our CDN uses a pull model, which means that the CDN will forward all requests that it does not have in cache to our webserver. Common problems when using a CDN are twofold:

  • First, the CDN will only cache assets that broadcast that they are cacheable in the first place.
  • Second, when the CDN has cached something, a manual purge has to be done to be able to propagate updates to the website. These purges are often limited to a fixed amount per period, and no guarantees are given to the speed at which they are processed.

This is where Page Speed comes to the rescue. The cache extending filter will embed a fingerprint of the content into the url, and serve the asset with a one year expiry.
So now, the CDN will keep the asset in cache for a year. If Page Speed detects a content changed, a completely new url will be generated - which makes content updates immediately visible to all end-users. It's like having your cake and eating it too.

If all goes well, using a CDN should speed up content delivery for vistors on our website. is hosted in The Netherlands, and we expect that using the CDN should be especially noticeable for people that are far away. The CDN should cache contents at its remote edges, which should be closer to our visitor. Browsers should also be able to connect faster to the CDN's servers, as the required roundtrips should take less time due to the geographic advantage.
The CDN should be able to proactively keep network connections open to our webserver, which eliminates time - no roundtrips are required to perform the initial connection setup.

Regarding our CDN: We need to sort one thing out: it seems that our current provider does not support any form of http compression, which is disappointing. We are running an A/B test to measure up - it would be nice to know if the CDN makes up for the lack of compression due to its geographical advantages. The results will be published in a few weeks on this blog as well, after which we might switch the CDN to one that does support gzip compression.


We have disabled the CDN for now - the page load times nearly doubled (see the image below). We are discussing this with our provider, and hopefully the CDN service can be improved. 

Update 2

Following a discussion on the problem seems to lie in IIS's default settings. With some tweaking, we got this to work - thanks @AkamaiRob!

Update 3

Things are looking a lot better. Our GA measurements show that more then 1 second is shaved of the averaged total page load times!

Friday, February 14, 2014

In-Place Resource Optimization: virtually risk free web optimization

As of version 1.1.6, we have a new optimization option in IISpeed call In-Place-Resource-Optimization (IPRO). With IPRO, assets that are loaded directly, for example by javascript code, still get optimized.

In-Place Resource Optimization works by serving optimized resources from the original URL, as opposed to the normal mode of operation, where resources are served from rewritten and optimized PageSpeed URL. This URL rewriting does generate a lot more optimization opportunities as it places the asset in context of the user-agent and surrounding page, but comes with  a cost of a slight chance of breaking scripts on a small set of websites, and is only possible after inspecting how they are references via the HTML. IPRO is still able to do some per-user-agent optimizations, by indicating variability of resources at the HTTP level. So, for example, it is still possible to convert from gif, jpeg or png to WebP format for images. Or serve lower-res images to mobile user agents.

This new mode can be combined to augment IISpeed's classic optimization mode, but also is a first step toward a full new optimization mode, that targets bandwidth reduction at a minimal chance of breaking websites. This provides a great "optimization is on by default" option for hosting providers where the product can be installed and enabled on all websites without having to worry about site breakage. We will also be looking into an option that will disable html parsing completely in this mode, to minimise the associated computing cost.

Technically, the way IPRO works is that IISpeed performs an asynchronous cache lookup for each request on a webserver, to see if the asset was seen earlier. If it turns out it was not seen earlier, the resource will be recorded and send into Google's PageSpeed optimization libraries for optimization. That will result in either an entry with the optimized asset in the cache, or an entry indicating that optimization was declined (for example, when the response was a zip file). The next time the same url is requested, the initial cache lookup will result in either an optimized asset which will be served immediately, or a fast decline from cache, in which case IIS will resume its normal flow and serve the original asset.

IPRO is enabled by adding a single line to the IISpeed configuration:
IISpeed InPlaceResourceOptimization on

The IISpeed release 1.1.6, which offers IPRO, is due next tuesday, february 25th.
Official documentation for In-Place-Resource-Optimization can be found here