Europe is definitely a hotspot for interest in web performance (WebPagetest sees almost as much traffic from there as the US). A huge "thank you" goes out to Aaron Peters who volunteered to expand our European testing footprint with a location in Amsterdam.
For an inaugural run, he ran some tests of the top online merchants in The Netherlands (according to Twinkle magazine) and from the looks of it there's quite a market need for Web Performance Optimization experts in the area.
(click on any of the urls to go to the test results for that page)
thomascook.nl - wow! poster-child material. Failures across the board with no persistent connections, caching, compression, nothing. It's actually amazing that it managed to load in 12 seconds at all.
www.wehkamp.nl - Non too bad on the standard things but a crazy number of javascript and css files in the head (and no caching) so a pretty poor user experience. A couple of tweaks could cut the load time in half and significantly speed up the start render time.
www.arke.nl - Apparently caching is passé - yet another site that doesn't like to use expires headers but what really surprised be was the 222KB of css that is being delivered without any compression. Both the sheer amount of CSS and the fact that it isn't compressed are pretty scary.
www.bol.com - Pretty much just got the keep-alives right. No compression, no caching, and a bunch of js/css files that need to be merged.
www.transavia.com - Yay, someone is actually compressing their javascript! Just a shame they have so much of it (150KB compressed) and in so many different files and wow, a 209KB png that should easily be an 8-bit (and MUCH smaller image).
www.oad.nl - And now we're back to the really low bar of failures across the board (including persistent connections) and a couple of 404's for good measure.
www.dell.nl - Dell did a reasonable job (though to be fair, it's probably a global template) and it's not a very rich landing page but they could still get quite a bit of improvement with image sprites and delaying the javascript.
www.cheaptickets.nl - Do I sound like a broken record yet? Other than persistent connections - epic fail!
www.d-reizen.nl - In DESPERATE need of some SpriteMe love (in addition to the usual suspects).
The sad part is that with just a couple of minutes of work every one of these sites could load in half the time and present a MUCH better user experience. We've already seen time and time again that conversions, sales, etc all increase substantially with improved page performance and as I see over and over again, the vast majority of sites aren't even taking the five-minutes to handle the absolute basics (most of which can be done just with configuration changes).
Wednesday, May 26, 2010
Thursday, May 13, 2010
Are pages getting faster?
Last year I did some bulk analysis on the test data from WebPagetest to get a snapshot of what the distribution of results looked like. It's about time to update the data and compare how the distributions have changed over time. It will take a while to crunch the data and generate pretty charts but before going there I thought it would be interesting to see how individual pages have changed over the last year...
How sites have changed over the last year
I looked for any pages that were tested in the last 4 months that also had been tested prior to 4/30/09 and it turns out there were 1279 pages with tests from both time periods. I'll see about making the raw (anonymized) data available but the aggregate results are pretty interesting.
Median values were used to eliminate the influence of pages with huge swings:
Load Time: +0.533 s
Time to first byte: +0.117 s
Time to start render: +0.179 s
Hmm, that's unfortunate - in aggregate, sites got slower.
Given that these are sites that were tested on WebPagetest in the first place, you'd think someone was actually working on optimizing them (or they were large, popular sites that people were randomly testing - but I doubt there were 1200 of those).
Let's see if we can dig into some of the page stats and see what's going on...
Page Size: +48 KB
Requests: +4
Connections: +1
DNS Lookups: +1
Looks like in general the back-end got a little bit slower (the first byte times) and the pages got a little heavier with more requests. Nothing really surprising here but it does seem that optimization is either not keeping up with the increased richness of the pages or (more likely) optimizing the pages has not yet made it's way into the dev cycle.
On the plus side, there's lots of room for improvement.
How sites have changed over the last year
I looked for any pages that were tested in the last 4 months that also had been tested prior to 4/30/09 and it turns out there were 1279 pages with tests from both time periods. I'll see about making the raw (anonymized) data available but the aggregate results are pretty interesting.
Median values were used to eliminate the influence of pages with huge swings:
Load Time: +0.533 s
Time to first byte: +0.117 s
Time to start render: +0.179 s
Hmm, that's unfortunate - in aggregate, sites got slower.
Given that these are sites that were tested on WebPagetest in the first place, you'd think someone was actually working on optimizing them (or they were large, popular sites that people were randomly testing - but I doubt there were 1200 of those).
Let's see if we can dig into some of the page stats and see what's going on...
Page Size: +48 KB
Requests: +4
Connections: +1
DNS Lookups: +1
Looks like in general the back-end got a little bit slower (the first byte times) and the pages got a little heavier with more requests. Nothing really surprising here but it does seem that optimization is either not keeping up with the increased richness of the pages or (more likely) optimizing the pages has not yet made it's way into the dev cycle.
On the plus side, there's lots of room for improvement.
Sunday, April 11, 2010
What happens when your site get mentioned is a google blog posting?
This:
In case you missed it, Google announced that site performance now affects your search rankings and in the article they included WebPagetest in the list of tools to use. I appreciate the props but it's been a busy day adding more testing capacity to get ready for Monday :-)
Edit: As expected, Monday was pretty busy:
Edit: As expected, Monday was pretty busy:
Friday, March 5, 2010
Google to offer CDN services?
Sadly no, not that I'm aware of but it would make total sense and maybe if there is enough interest they would consider it. This is one of those "wouldn't it be nice if..." posts but there is also a fair bit of thought that went into the how's and why's.
Google has been pushing to make the web faster on various fronts from Chrome to SPDY to Page Speed to Google DNS and have been saying that they would like the Internet to be as fast as turning the pages in a magazine. Once you get past a lot of the optimizations, there really is no way around the problem - to get faster you need to use a CDN for static content because the speed of light isn't getting any faster and it doesn't matter how fast your Internet connection is, the real performance killer is latency.
I've thought a fair bit about how I think they could do it and it should fit really well into their model as well as their suite of offerings. I'm thinking they could offer a zero-config version that looks a lot like how coral cache works. Basically just prepend .cdn.google.com with your origin and the traffic would go through Google's CDN (www.webpagetest.org.cdn.google.com for example). That way everything needed to fetch the origin content is already embedded in the request and the site owner doesn't need to do anything. For custom urls they could make it part of Google apps and let you configure custom CNAME's and origin servers.
From an infrastructure perspective it really doesn't get any easier than that (assuming you're not trying to bill people for bandwidth utilization and storage). They'd obviously need to put some protections in place to prevent it from turning into a massive download farm (limit mime types and file sizes?). Most CDN providers are trying to focus on the more lucrative "bits" anyway (streaming, etc) so taking away the static content portion of the market wouldn't completely obliterate the market and it would probably be the single most impactful thing they could do to speed up the web at large.
There would also be other benefits that may not be as obvious. They could get significantly more bang by deploying SPDY if they also owned the other end of the connection for a lot of the requests (so anything going through the Google CDN would be significantly faster in chrome). It also seems like a much more cost-effective strategy than laying fiber in communities and would be a perfect fit for their current application model (basically just a software deployment and it would work).
Just like with Google Analytics I expect there would be a huge number of sites that would switch over and start using it and by having a standard way to do it I would expect to start seeing things like Wordpress plugins that automatically servs all of your static content through the Google CDN making it an automatic speed-up.
Other than the obvious elephant in the room around the costs and infrastructure to run it, am I missing something? It really should be that easy and voila - faster web for everyone.
Google has been pushing to make the web faster on various fronts from Chrome to SPDY to Page Speed to Google DNS and have been saying that they would like the Internet to be as fast as turning the pages in a magazine. Once you get past a lot of the optimizations, there really is no way around the problem - to get faster you need to use a CDN for static content because the speed of light isn't getting any faster and it doesn't matter how fast your Internet connection is, the real performance killer is latency.
I've thought a fair bit about how I think they could do it and it should fit really well into their model as well as their suite of offerings. I'm thinking they could offer a zero-config version that looks a lot like how coral cache works. Basically just prepend .cdn.google.com with your origin and the traffic would go through Google's CDN (www.webpagetest.org.cdn.google.com for example). That way everything needed to fetch the origin content is already embedded in the request and the site owner doesn't need to do anything. For custom urls they could make it part of Google apps and let you configure custom CNAME's and origin servers.
From an infrastructure perspective it really doesn't get any easier than that (assuming you're not trying to bill people for bandwidth utilization and storage). They'd obviously need to put some protections in place to prevent it from turning into a massive download farm (limit mime types and file sizes?). Most CDN providers are trying to focus on the more lucrative "bits" anyway (streaming, etc) so taking away the static content portion of the market wouldn't completely obliterate the market and it would probably be the single most impactful thing they could do to speed up the web at large.
There would also be other benefits that may not be as obvious. They could get significantly more bang by deploying SPDY if they also owned the other end of the connection for a lot of the requests (so anything going through the Google CDN would be significantly faster in chrome). It also seems like a much more cost-effective strategy than laying fiber in communities and would be a perfect fit for their current application model (basically just a software deployment and it would work).
Just like with Google Analytics I expect there would be a huge number of sites that would switch over and start using it and by having a standard way to do it I would expect to start seeing things like Wordpress plugins that automatically servs all of your static content through the Google CDN making it an automatic speed-up.
Other than the obvious elephant in the room around the costs and infrastructure to run it, am I missing something? It really should be that easy and voila - faster web for everyone.
Saturday, February 20, 2010
Exciting new CDN (MaxCDN)
A common complaint from users of WebPagetest is that I should make using a CDN (Content Distribution Network) an optional check (and it was a common complaint against YSlow as well before they did make it configurable in version 2). It's usually because their site is too small to justify the expense or complexity of integrating with one of the CDN providers. Recently I had a few different people ping me to add MaxCDN to the known list of CDN's that I check so while I was at it I thought I'd check them out.
I must admit, I came away totally impressed (so much so that I decided to use them for WebPagetest). They are doing a lot of things "right" that most of the CDN companies don't bother because it's too difficult and to top it off the barrier to entry is pretty much non-existent (Trial pricing of $10 for 1TB right now with great normal prices as well).
Here are some of the highlights:
Anycast instead of DNS-based localization
Every CDN I have seen uses DNS to send each user to the closest server. There are some serious problems with this approach:
Simple configuration
It literally just takes a few minutes to set it up and have it working. You don't have to upload the files, just set up an alias (the call them "zones") and tell it what to map it to and all of the resources will be fetched automatically when they are referenced.
For example, I set up a zone "webpagetest" that points to "http://www.webpagetest.org/" and gave it a DNS alias of cdn.webpagetest.org (their UI will tell you what to set the CNAME record to for it to work). Now everything that can be accessed from www.webpagetest.org can also be referenced from cdn.webpagetest.org but using their CDN. The hardest part is changing the relative paths I used to reference the js, css and images on my site to use a full path through the CDN.
They have a few plugins that automate the configuration for some of the common CMS platforms (wordpress for example).
An eye towards performance
Rather than just taking on the market with a well-architected inexpensive CDN they are also pushing the envelope on helping their customers optimize their sites by making it easy to do through the CDN. They recently updated their control panel to make it easy to add multiple aliases for the same content so splitting requests across domains just got that much easier and it looks like they are looking to push more and more capabilities into the edge.
In a time when most CDN providers are interested in streaming and other large bandwidth uses (more money since you pay for the bandwidth you use) it's really exciting to see a new player come in and shake things up where it really matters for most sites - making pages faster. Bonus points for it being so cheap that there's really no excuse to NOT use a CDN if your site is on the Internet.
Exciting Times!
I must admit, I came away totally impressed (so much so that I decided to use them for WebPagetest). They are doing a lot of things "right" that most of the CDN companies don't bother because it's too difficult and to top it off the barrier to entry is pretty much non-existent (Trial pricing of $10 for 1TB right now with great normal prices as well).
Here are some of the highlights:
Anycast instead of DNS-based localization
Every CDN I have seen uses DNS to send each user to the closest server. There are some serious problems with this approach:
- The CDN provider actually only ever sees your user's DNS server's IP address (that of their ISP, company, whatever). This is reasonable as long as they are using a DNS server that is close to them but the servers are usually regional at best (and if they are using something like OpenDNS it may not be anywhere near the actual user). This can result in sending the user to a CDN server (POP) that is not anywhere near them.
- The localization is only as good as their ability to figure out where the user's DNS server is. They can usually locate the large ISP DNS servers well but a corporation or individual running their own resolver may be hit or miss (depending on how accurate their database is).
- By relying on DNS they usually have a low TTL (Time To Live) on the DNS records - as low as 1 minute. This means that all of the caching that goes on for DNS at the various levels (local PC, ISP, etc) gets flushed every minute and the pain of a new lookup can be pretty bad depending on the DNS architecture of the CDN provider.
Simple configuration
It literally just takes a few minutes to set it up and have it working. You don't have to upload the files, just set up an alias (the call them "zones") and tell it what to map it to and all of the resources will be fetched automatically when they are referenced.
For example, I set up a zone "webpagetest" that points to "http://www.webpagetest.org/" and gave it a DNS alias of cdn.webpagetest.org (their UI will tell you what to set the CNAME record to for it to work). Now everything that can be accessed from www.webpagetest.org can also be referenced from cdn.webpagetest.org but using their CDN. The hardest part is changing the relative paths I used to reference the js, css and images on my site to use a full path through the CDN.
They have a few plugins that automate the configuration for some of the common CMS platforms (wordpress for example).
An eye towards performance
Rather than just taking on the market with a well-architected inexpensive CDN they are also pushing the envelope on helping their customers optimize their sites by making it easy to do through the CDN. They recently updated their control panel to make it easy to add multiple aliases for the same content so splitting requests across domains just got that much easier and it looks like they are looking to push more and more capabilities into the edge.
In a time when most CDN providers are interested in streaming and other large bandwidth uses (more money since you pay for the bandwidth you use) it's really exciting to see a new player come in and shake things up where it really matters for most sites - making pages faster. Bonus points for it being so cheap that there's really no excuse to NOT use a CDN if your site is on the Internet.
Exciting Times!
Monday, January 11, 2010
We can do better (as an industry)!
For the most part, web site performance optimization has been something that an experienced developer had to be involved in and if they weren't then odds are your site doesn't perform well. Why do we have to work so hard to make them faster (and more importantly, why are they not fast automatically)? I think there are some key areas that could help significantly if they were addressed:
Hosting Providers
If a hosting provider does not have persistent connections and gzipping for html, css and js enabled by default they should be out of business. Period. Maybe it is time to keep a public record of which hosting providers are configured well for performance and which aren't but things are in pretty bad shape.
I'm appalled by the number of sites that get tested with persistent connections disabled and the owners contact me asking how to fix it but they can't because the hosting provider has it disabled. Enabling gzip for html, js and css mime types by default will also go a long way to helping (and it will likely help their bottom line as they will be serving fewer bytes).
CMS Platforms
This is for the Drupals, Joomla's and Wordpresses of the world. You control the platform 100%, make it fast by default for people installing rather than requiring acceleration plugins or significant tuning and tweaking. Since they all have custom plugin and theming API's there is a HUGE opportunity here. Fixing wordpress installs is another topic I see WAY too frequently, particularly when plugins are involved. Some suggestions:
This is for the jQuery, MooTools, YUI Library, etc. Provide samples that are already optimized. Developers are REALLY good at copy and paste. If you give them a sample that is going to perform poorly then that's what they use. Every example I have ever seen for a js toolkit throws the individual components all in the head as separate files. This is probably the worst thing you can do for page performance but everyone does it because that's how all of the samples tell you how to do it.
Hosting Providers
If a hosting provider does not have persistent connections and gzipping for html, css and js enabled by default they should be out of business. Period. Maybe it is time to keep a public record of which hosting providers are configured well for performance and which aren't but things are in pretty bad shape.
I'm appalled by the number of sites that get tested with persistent connections disabled and the owners contact me asking how to fix it but they can't because the hosting provider has it disabled. Enabling gzip for html, js and css mime types by default will also go a long way to helping (and it will likely help their bottom line as they will be serving fewer bytes).
CMS Platforms
This is for the Drupals, Joomla's and Wordpresses of the world. You control the platform 100%, make it fast by default for people installing rather than requiring acceleration plugins or significant tuning and tweaking. Since they all have custom plugin and theming API's there is a HUGE opportunity here. Fixing wordpress installs is another topic I see WAY too frequently, particularly when plugins are involved. Some suggestions:
- Force use of an API call to include CSS in a page template and then do the necessary processing to combine the files together, do the versioning, have long expiration times, etc (and bonus points for inlining the background images for appropriate browsers and for fancier tricks like inlining the css for first view, etc).
- Provide API's and hooks for javascript on pages along with async loading and combining. Make it HARD to load js in the head and strongly discourage it.
- Provide automatic image compression with reasonable quality levels (that could be overridden if needed but that defaults to re-compressing images and stripping any exif information off).
This is for the jQuery, MooTools, YUI Library, etc. Provide samples that are already optimized. Developers are REALLY good at copy and paste. If you give them a sample that is going to perform poorly then that's what they use. Every example I have ever seen for a js toolkit throws the individual components all in the head as separate files. This is probably the worst thing you can do for page performance but everyone does it because that's how all of the samples tell you how to do it.
Friday, December 4, 2009
WebPagetest outage
Update 2: All back to fully operational now, sorry for the inconvenience.
Update: I have disabled the forums and authentication integration as well as made some changes to at least bring the main testing online. The forums will be back once Dreamhost fixes the problems with the MySQL server.
Sorry, Dreamhost seems to be having all sorts of problems trying to keep the server that runs WebPagetest running so the site has been unavailable for the better part of the day. I've been harassing them on a fairly regular basis so hopefully they will get it cleared up soon.
Ahh, how I miss the days where it was running in my basement and I could just run home and kick it :-)
Thanks,
-Pat
Update: I have disabled the forums and authentication integration as well as made some changes to at least bring the main testing online. The forums will be back once Dreamhost fixes the problems with the MySQL server.
Sorry, Dreamhost seems to be having all sorts of problems trying to keep the server that runs WebPagetest running so the site has been unavailable for the better part of the day. I've been harassing them on a fairly regular basis so hopefully they will get it cleared up soon.
Ahh, how I miss the days where it was running in my basement and I could just run home and kick it :-)
Thanks,
-Pat
Subscribe to:
Posts (Atom)