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

Friday, January 24, 2014

Announcing IISpeed 1.1.5

Announcing IISpeed 1.1.5

This release contains 2 fixes:

  • Reverts turning on lossy optimizations on PNG images. This improves image quality and prevents artifacts for installations running with our defaults.
  • Integrates serving optimized resources with IIS's native caching facilities, improving throughput up to 10 times. As resources usually represent the majority of a webpage, this is a big improvement in performance serverside. Just for reference, here's a quick benchmark on a virtual machine running  2/4 cores on my laptop:
    PS C:\git\iis_filter> ab -n 100000 -c 10 -k http://iispeed.localhost/960x600xiis-85.png.pagespeed.ic.rMYunSsdGR.webp
    This is ApacheBench, Version 2.3 <$Revision: 1373084 $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd,
    Licensed to The Apache Software Foundation,
    Benchmarking iispeed.localhost (be patient)
    Completed 10000 requests
    Completed 20000 requests
    Completed 30000 requests
    Completed 40000 requests
    Completed 50000 requests
    Completed 60000 requests
    Completed 70000 requests
    Completed 80000 requests
    Completed 90000 requests
    Completed 100000 requests
    Finished 100000 requests
    Server Software:        Microsoft-IIS/7.5
    Server Hostname:        iispeed.localhost
    Server Port:            80
    Document Path:          /960x600xiis-85.png.pagespeed.ic.rMYunSsdGR.webp
    Document Length:        56498 bytes
    Concurrency Level:      10
    Time taken for tests:   8.274 seconds
    Complete requests:      100000
    Failed requests:        0
    Write errors:           0
    Keep-Alive requests:    100000
    Total transferred:      5687800000 bytes
    HTML transferred:       5649800000 bytes
    Requests per second:    12086.31 [#/sec] (mean)
    Time per request:       0.827 [ms] (mean)
    Time per request:       0.083 [ms] (mean, across all concurrent requests)
    Transfer rate:          671332.89 [Kbytes/sec] received
    Connection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:        0    0   0.0      0       1
    Processing:     0    1   0.7      1      21
    Waiting:        0    0   0.5      0      13
    Total:          0    1   0.7      1      21
    Percentage of the requests served within a certain time (ms)
      50%      1
      66%      1
      75%      1
      80%      1
      90%      2
      95%      2
      98%      2
      99%      3
     100%     21 (longest request)
    PS C:\git\iis_filter>
That's right, over 600MB/second with an awesome latency distribution. This is a test on just one resource, but we have seen comparable results in tests distributed over more resources.
Another upside is that caching by IIS also reduces CPU load, the test we ran did not overtax the CPUs.

IISpeed 1.1.5 is available right now.