Tuesday, March 4, 2014

Accelerating visitnapavalley.com: 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 visitnapavalley.com was accelerated by IISpeed at http://googledevelopers.blogspot.com/2014/03/iispeed-accelerates-visitnapavalleycom.html

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 https://code.google.com/p/modpagespeed/issues/detail?id=867 and https://github.com/pagespeed/ngx_pagespeed/issues/596
  • 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 iispeed.com. After setting up the DNS for cdn.iispeed.com, 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 cdn.iispeed.com www.iispeed.com
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. iispeed.com 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.

Update 

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, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/
    
    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.

Monday, December 9, 2013

IISpeed playground - Effortless experimentation with PageSpeed optimization on your website


IISpeed - Automatic web performance optimization for Microsoft IIS, powered by Google PageSpeed Optimization

We are pleased to announce that our new IISpeed Playground service has gone beta and public.
The IISpeed Playground allows experimenting with PageSpeed optimization from Google in an easy manner. You can get a feel for what it does without installing any software or deep-down technical knowledge.

Any website can be submitted, and will automatically be re-hosted on one of our machines. After submission, you will receive an email which contains a url where the PageSpeed filters can be configured.
The results can be seen at a seperate website. Your original website will be left untouched, so there is no risk in trying.

Comparisons can either be done manually by inspecting the optimized html sources and assets, or automatically with webpagetest.org.

Sounds good? You can try it here.

The service was built on top of ats_speed, our port of ngx_pagespeed to Apache Traffic Server.
At this point there are a few limitations on the service. For example, external content from websites shown via the service will not be optimized at this moment. We will continue to work on improving the service.

Google PageSpeed Optimization and Apache Traffic Server: ats_speed open source release




We are pleased to announce our open source release of ats_speed. Ats_speed is a plugin for Apache Traffic Server that mostly ports ngx_pagespeed to Apache Traffic Server.

The combination of automatic web performance optimization plus Traffic Server's speedy http cache makes for a very fast web acceleration solution in one easy-to-use package. When configured as a reverse proxy, the port is able to optimize html either from the internal http cache or from the origin webservers as it streams in.

Ats_speed is implemented as an async plugin, and currently building against the trunk of Google's PageSpeed SDK. It is currently in beta, and running production on IISpeed's demonstration service.

We would specifically like to thank Jeff Kaufman, because a lot of his work on ngx_pagespeed was used as 'inspiration' for atsspeed.