Wednesday, April 22, 2015

PageSpeed HTTP/2 and Server Push

With SPDY and the forthcoming HTTP/2 protocol, servers are able to push responses upon the client without waiting for an actual request. Would it be hard to pull the assets determined via beaconing as critical for rendering a page above-the-fold from PageSpeed, and use that information to push to those down the wire?
It seems like PageSpeed and the new protocols could create a lot of synergy, but wiring them up to work together could be a challenge.

PageSpeed minification service. Simple and fast.

Simple and free PageSpeed minification

 Today we launched a simple service for minifying css, javascript and image files using PageSpeed optimization by Google. If you are looking for an easy way to get your web assets optimized for the web according to the latest PageSpeed compliance rules, this service provides an easy way to do so.

CSS and JavaScript will be minified. PageSpeed's image optimization is pretty advanced, and a topic on its own. One of the nicer features of PageSpeed image optimization is that it is able to automatically classify wether a lossless image is a proper candidate for lossy compression.

The webpage of the service will allow you to drop or select multiple files for uploading, and subsequently will display a list of savings, next to offering a link to download the resulting zip file with optimized assets.

More options will be added to service in the coming weeks, like specifying image recompression quality and some more advanced options.

The service is in beta testing, check it out at

Sunday, April 19, 2015

Resource signing with PageSpeed

As of PageSpeed (IISpeed 2.0) it is possible to have PageSpeed add cryptographic hashes to resource urls to protect them from tampering with. Doing so eliminates one potential denial of service attack vector (possible two if the underlying unoptimized resources are served from virtual handlers, which will be protected as well).

To help existing customers if they want to transit towards using this new feature, there is mode where signed urls will be generated, but unsigned urls will still be accepted.

Integrating PageSpeed optimization into a CMS

Web performance vs Content Management Systems

Content management systems are not known for their efficiency from a web performance perspective  - especially the slightly older ones. From the vendor's perspective, it makes sense to build a very generic one-size-fits all solution to cater the needs of a broad range of customers.

A downside of the one-size-fits-all approach is that the html, scripts, images, and css that are generated by such systems are often far from being lean and mean. For example, some systems will forward any image that you might upload for display in a page without optimizing it for the web first.
Another case is that of a marketeer that enters blocking javascript into a content field for A/B split testing purposes, thereby unknowingly introducing a slowdown that might hurt overall conversion rates.

In both examples, the users of the CMS systems cannot be blamed for the degraded user experience on the website.

PageSpeed to the rescue

These inefficiencies is where Google's PageSpeed comes to the rescue, as it is able to automatically rewrite webserver output for fast delivery. Images will automatically resized and (thoroughly) optimized for both desktop and mobile, and javascript will be rewritten so it does not block the browser's network and/or rendering tasks.

Controlling pagespeed optimizations from the CMS

Here is a lightweight way to integrate pagespeed into your CMS: you can control which optimizations pagespeed will apply from script, by sending out a response header named "PageSpeedFilters". 
The trick is to let the CMS generate that header and put a value into it when a user has specified that for a page.
This is particularly useful after the initial tuning phase, in case a CMS user needs to enable or disable filters for one or more pages.

Approaching an integration - carefully

At We-Amp, we recently added page speed optimization into the mix for an agency that run lots of (e-commerce) websites through a content management system.

Steps taken in our approach:
  1. Install the PageSpeed module for the relevant server technology, IIS in our case.
  2. Set the base optimization level of the pagespeed module to 'PassThrough', which means only html will be parsed and reserialized. Let this run for a while, letting a significant amount of live traffic pass by. In this phase, keep an eye on conversion rates and event logs.
  3. If all is OK, it is time to flip the switch and set the optimization level to something a little more aggressive: optimizing for bandwith. This optimization level is designed to be as safe as possible, so pagespeed will be very conservative in it's rewriting. 
  4. Monitor the server load, conversion rates, and pagespeed statistics for a while to make sure all is well. If the server is spiking, it should usually settle down quickly as pagespeed learns how to best optimize the website. If you are tight on cpu, you can throttle by 
    • Limiting the number of concurrent image optimizations
    • Randomly dropping optimizing rewrites (eventually everything will be optimized anyway)
  5. Repeat step 3 and 4 for all websites involved.
  6. At this point, it is time to start tuning websites by enabling more aggressive optimizations in a controlled way. To effectively do so, tools to measure should be in place. A/B split test experiments are a very good approach to make sure you are on the right track when changes configuration, and doing so is facilitated by PageSpeed.
To figure out which optimizations make the most sense to enable, PageSpeed insights is a very good place to start. It will give you suggestions on what optimizations would be good to enable in the pagespeed module, and help you comply to best practices.


Saturday, April 18, 2015

Debugging Page Speed: the debug filter

When you are working with a PageSpeed server module, you sometimes need to debug why something isn't working out like you expected. Recently, Google's team has made a huge improvement on this, by emitting a lots of useful information via html comments when you enable the debug filter.

You will be able to see why certain files are not inlined or combined, what decisions are made and why when applying image optimization, and lots more.

Other useful information include timing data as measured on the server, including the time the server took to send the first byte into PageSpeed, the time it took PageSpeed to parse and optimize, the time PageSpeed spent idle waiting for optimizations and fetches to finish up, and more.

One more useful thing is that enabling the debug filter will make PageSpeed echo back the configuration that was applied for this request. Another improvement here is that this will now
also list a description of the filters, where previously this would only display short (cryptic :-)) codes for the enabled filters.

You can turn on the debug filter from the querystring (when allowed) by adding ?PageSpeedFilters=+debug

For an example, go to and click view source.
The enhanced debug filter is available as of IISpeed 2.0 (PageSpeed 1.9.x).

Happy optimizing!

Monday, March 30, 2015

Extending the IISpeed 2.0 beta 1

The previous beta expired at April 1st 2015

We are currently busy backporting the ResponsiveImagesFirstFilter from mod_pagespeed 1.10, this will provide partial srcset support. Because this has been a much requested feature we did not release 2.0 yet.

In the meanwhile we have extended the 2.0 beta 1 until June 1st 2015, you can download this extended version at

We are running IISpeed 2.0 beta 1 ourselves and found it to be very stable. If you have any feedback regarding 2.0, positive or negative, please mail

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  June 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