Velocity Europe – High Performance Berlin!
Velocity Europe is less than two weeks away. It’s happening November 8-9 in Berlin at the Hotel Maritim ProArte. I’ve heard good things about the venue and am excited to get there and check it out.
This event has been a long time coming. A handful of web performance and operations savants (including members of the Program Committee) have been encouraging us for years to bring Velocity to Europe, and now it’s actually happening. And (drum roll please) the price is only EUR 600 (excl. VAT) if you use the 20% discount code veu11sts. (And don’t forget about the free Velocity Online Conference this week – see more below.)
The Velocity Europe speaker line-up is exceptional. Some highlights include:
- Jon Jenkins from Amazon.com is talking about their approach to the challenges of mobile browsing. Jon is the Director of Software Development for Amazon Silk. I’m looking forward to more details about Silk’s split architecture.
- Tim Morrow delivers the background for Betfair’s promise to deliver a fast experience to their customers, and their progress on that promise.
- Theo Schlossnagle is a recognized leader at Velocity. He’s giving two talks on web operations careers and monitoring.
- Estelle Weyl joins Velocity for the first time talking about the nuances of mobile rendering performance. I learn something new everytime I hear Estelle speak, so am excited to welcome her to Velocity.
- Ivo Teel discusses the balance we all face between features and performance and how they’re handling that at Spil Games.
- Jeff Veen knows the importance of 3rd party performance and availability as the CEO of Typekit. Jeff’s an amazing, engaging speaker. Reading his session description gave me goosebumps with anticipation: Jeff sat on a couch in the Typekit offices, staring out the window, and wondering if everything their company had been working towards was about to slip through their fingers…
There’s much much more – lightning demos, browser vendor talks, Allspaw on anticipating failure, Mandelin on JavaScript performance – I’ve got to stop here but please check out the entire schedule.
I want to give a shout out to the Velocity Europe Program Committee: Patrick Debois, Aaron Peters, Schlomo Schapiro, Jeroen Tjepkema, and Sean Treadway. They’ve participated in numerous video concalls (yay Google Hangouts!) to review proposals, build the program, and shape Velocity to be a European conference. And they might have one more card up their sleeve – more on that later.
You can get a free warm-up for Velocity Europe at the Velocity Online Conference this week. It’s Wednesday October 26 9-11:30am PDT. John Allspaw, Velocity co-chair, has rounded up four speakers to cover several hot topics including monitoring, global DNS, and making yourself even more awesome(!). It’s free, but you have to register for Velocity OLC if you want to get in on the conversation.
If you’re heading to Berlin you should also check out CounchConf Berlin on Nov 7. NoSQL has great performance benefits and Couchbase is a good choice for many mobile apps. Use couchconf_discount for 10% off registration.
The last time I was in Berlin was for JSConf.eu 2009. The city had a high tech vibe and the crowd was extremely knowledgeable and enthusiastic. I’m excited to get back to Berlin for Velocity Europe and do the web performance and operations deep dives that are the core of Velocity. If you want to have a website that’s always fast and always up, Velocity Europe is the place to be. I hope to see you there.
HTTP Archive: new code, new charts
The HTTP Archive is a permanent record of web performance information started in October 2010. The world’s top 17,000 web pages are analyzed twice each month to collect information such as the number and size of HTTP requests, whether responses are cacheable, the percent of pages with errors, and the average Page Speed score. The code is open source and all the data is downloadable.
The next big step is to increase the number of URLs to 1 million. The biggest task to get to this point is improving the database schema and caching. This past week I made some significant code contributions around caching aggregate stats across all the web sites. Even with only 17K URLs the speed improvement for generating charts is noticeable.
The new stats cache allows me to aggregate more data than before, so I was able to add several trending charts. (The increases/decreases are Nov 15 2010 to Oct 15 2011.)
- percent of sites using Google Libraries API – up 6%
- percent of sites using Flash – down 2%
- percent of responses with caching headers – up 4%
- percent of requests made using HTTPS – up 1%
- percent of pages with one or more errors – down 2%
- percent of pages with one or more redirects – up 7%
Most of the news is good from a performance perspective, except for the increase in redirects. Here’s the caching headers chart as an example:
I dropped the following charts:
- popular JavaScript libraries – I created this chart using handcrafted regular expressions that attempted to find requests for popular frameworks such as jQuery and YUI. Those regexes are not always accurate and are hard to maintain. I recommend people use the JavaScript Usage Statistics from BuiltWith for this information.
- popular web servers – Again, BuiltWith’s Web Server Usage Statistics is a better reference for this information.
- sites with the most (JavaScript | CSS | Images | Flash) – These charts were interesting, but not that useful.
- popular scripts – This was a list of the top 5 most referenced scripts based on a specific URL. The problem is that the same script can have a URL that varies based on hostnames, querystring parameters, etc.
The new stats cache is a great step forward. I have a few more big coding sessions to finish but I hope to get enough done that we can start increasing the number of URLs in the next run or two. I’ll keep you posted.
frontend SPOF survey
Pat Meenan had a great blog post yesterday, Testing for Frontend SPOF. “SPOF” means single point of failure. I coined the term frontend SPOF to describe the all-too-likely situation where the HTML document returns successfully, but some other resource (a stylesheet, script, or font file) blocks the entire website from loading. This typically manifests itself as a blank white screen that the user stares out for 20 seconds or longer.
Frontend SPOF happens most frequently with third party content. If the HTML document returns successfully, then all the resources from the main website are likely to return successfully, as well. Third party content, however, isn’t controlled by the main website and thus could be suffering an outage or overload while the main website is working fine. As a result, the uptime of a website is no greater than the availability of the third party resources it uses that are in a position to cause frontend SPOF.
In my blog post of the same name I describe how Frontend SPOF happens and ways to avoid it, but I don’t provide a way for website owners to determine which third party resources may cause frontend SPOF. This is where Pat comes in. He’s created a public blackhole server: blackhole.webpagetest.org with the static IP address 72.66.115.13. Pointing your third party resources to this blackhole and reloading the page tells you if those resources cause frontend SPOF. Since Pat is the creator of WebPagetest.org, he has integrated this into the scripting capabilities of that tool so website owners can load their website and determine if any third party resources cause frontend SPOF.
/etc/hosts
I took a different approach outlined by Pat: I added the following lines to my /etc/hosts file (your location may vary) mapping these third party hostnames to point to the blackhole server:
72.66.115.13 apis.google.com 72.66.115.13 www.google-analytics.com 72.66.115.13 connect.facebook.net 72.66.115.13 platform.twitter.com 72.66.115.13 s7.addthis.com 72.66.115.13 l.addthiscdn.com 72.66.115.13 cf.addthis.com 72.66.115.13 api-public.addthis.com 72.66.115.13 widget.quantcast.com 72.66.115.13 ak.quantcast.com 72.66.115.13 assets.omniture.com 72.66.115.13 www.omniture.com 72.66.115.13 scripts.omniture.com 72.66.115.13 b.voicefive.com 72.66.115.13 ar.voicefive.com 72.66.115.13 c.statcounter.com 72.66.115.13 www.statcounter.com 72.66.115.13 www-beta.statcounter.com 72.66.115.13 js.revsci.net
After restarting my browser all requests to these hostnames will timeout. Pat’s blog post mentions 20 seconds for a timeout. He was running on Windows. I’m running on my Macbook where the timeout is 75 seconds! Any website that references third party content on these hostnames in a way that produces frontend SPOF will be blank for 75 seconds – an easy failure to spot.
survey says
THE GOOD: At this point I started loading the top 100 US websites. I was pleasantly surprised. None of the top 20 websites suffered from frontend SPOF. There were several that loaded third party content from these hostnames, but they had safeguarded themselves:
- MSN makes a request to
ar.voicefive.com, but does it asynchronously using a document.write technique. - AOL references
platform.twitter.com, but puts the SCRIPT tag at the very bottom of the BODY so page rendering isn’t blocked. - IMDB uses the async version of Google Analytics, and puts the
platform.twitter.comwidget in an iframe. - LiveJournal goes above and beyond by wrapping the Google +1 and Facebook widgets in a homegrown async script loader.
THE BAD: Going through the top 100 I found five websites that had frontend SPOF:
- CNET loads
http://platform.twitter.com/widgets.jsin the HEAD as a blocking script. - StumbleUpon loads
http://connect.facebook.net/en_US/all.jsat the top of BODY as a blocking script. - NFL loads
http://connect.facebook.net/en_US/all.jsin the HEAD as a blocking script. - Hulu, incredibly, loads Google Analytics in the HEAD as a blocking script. Please use the async snippet!
- Expedia loads
http://connect.facebook.net/en_US/all.jsas a blocking script in the middle of the page, so the right half of the page is blocked from rendering.
These results, although better than I expected, are still alarming. Although I only found five websites with frontend SPOF, that’s 5% of the overall sample. The percentage will likely grow as the sample size grows because best practices are more widely adopted by the top sites. Also, my list of third party hostnames is a small subset of all widgets and analytics available on the Web. And remember, I didn’t even look at ads.
Is it really worth blocking your site’s entire page for a widget button or analytics beacon – especially when workarounds exist? If you’re one of the five sites that faltered above, do yourself and your users a favor and find a way to avoid frontend SPOF. And if you’re outside the top 100, test your site using Pat’s blackhole server by editing /etc/hosts or following Pat’s instructions for testing frontend SPOF on WebPagetest.org.
Improving app cache
I recently found out about the W3C Workshop on The Future of Off-line Web Applications on November 5 in Redwood City. I won’t be able to attend (I’ll be heading to Velocity Europe), but I feel like app cache needs improving so I summarized my thoughts and sent it to the workshop organizers. I also pinged some mobile gurus and got their thoughts on app cache.
My Thoughts
SUMMARY: App cache is complicated and frequently produces an unexpected user experience. It’s also being (ab)used as a workaround for the fact that the browser’s cache does not cache in an effective way – this is just an arms race for finite resources.
DETAILS: I’ve spoken at many mobile-specific conferences and meetups in the last few months. When I explain the way app cache actually works, developers come up afterward and say “now I finally understand what was happening with my offline app.” These are the leading mobile developers in the world.
John Allsopp does a great job of outlining the gotchas, and I’ve added some (slides 50&51):
- HTML responses with the MANIFEST attribute are stored in app cache by default, even if they’re not in the CACHE: section of the manifest file.
- If a CACHE: resource 404s then none of the resources are cached.
- The manifest file must be changed in order for changed CACHE: resources to be updated.
- Modified CACHE: resources aren’t seen by the user until the second time they load the app – even if they’re online.
It’s easy to point out problems – you folks have the more difficult job of finding solutions. But I’ll make a few suggestions:
- Use updated resources on first load – The developer needs a way to say “if the user is online, then fetch (some/all) of the CACHE: resources that have changed before rendering the app”. I would vote to make this the default behavior, and provide a way to toggle it (in the manifest file or HTML attribute). Perhaps this should also be done at the individual resource level – “I want updated scripts to block the initial rendering, but nothing else”. The manifest file could have an indicator of which resources to check & download before doing the initial rendering.
- 404s – I haven’t tested this myself, but it seems like overkill. Every response in the CACHE: section should be cached, independent of the other responses. Perhaps this is browser-specific?
- updateReady flag – It’s great that developers can use the updateReady event to prompt the user to reload the app if any CACHE: resources have changed underneath them, but the bar is too high. In addition, have a flag that indicates that the browser should prompt the user automatically if any CACHE: resources were updated.
Finally, on the topic of arms race, I know many websites that are using app cache as a way to store images, scripts, and stylesheets. Why? It’s because the browser’s disk cache is poorly implemented. App cache provides a dedicated amount of space for a specific website (as opposed to a common shared space). App cache allows for prioritization – if I have 10M of resources I can put the scripts in the CACHE: section so they don’t get purged at the expense of less painful images.
Certainly a better solution would be for the browsers to have improved the behavior of disk cache 5 years ago. But given where we are, an increasing number of websites are consuming the user’s disk space. In most cases the user doesn’t have a way or doesn’t know how to clear app cache. Better user control over app cache is needed. I suggest that clearing “data” clears both the disk cache as well as app cache. Alternatively, we extend the browser UI to have an obvious “clear app cache” entry. Currently in Firefox and Chrome you can only clear app cache on a site-by-site basis, and the UI isn’t obvious. In Firefox it’s under Tools | Options | Advanced | Network | Remove. In Chrome it’s under chrome://appcache-internals/.
The most important near term fix is better patterns and examples.
- My first offline app had a login form on the index.html – how should I handle that?
- What if the JSON data in app cache requires authentication and the user is offline – use it or not?
- I’ve never seen an example that uses the FALLBACK: section.
Adoption of current app cache would go much more smoothly with patterns and examples that address these gaps, and perhaps a JS helper lib to wrap updateReady and other standard dev tasks.
Mobile Gurus
A great email thread resulted when I asked a bunch of mobile gurus for their thoughts about app cache. Here’s a summary of the comments that resulted:
| Scott Jehl | Agreed on app cache’s clumsiness. It’s so close though! The cache clearing is terrible for both users and developers. |
| Nicholas Zakas | +1 for AppCache clumsiness. My big complaint is requiring a special MIME type for the manifest file. This effectively limits its use to people who have access to their server configuration. |
| Yehuda Katz | My biggest concern is the lack of a feature that would make it possible to load the main index.html from cache, but only if the user agent is offline.Currently, if the user agent is online, the entire cache manifest, including the main index.html, is used. As a result, developers are required to come up with some non-standard UI to let the application user know that they should refresh the page in order to get more updated information.This is definitely the way to get the most performance, even when the user agent is online, but it creates an extremely clumsy workflow which significantly impedes adoption. I have given a number of talks on the cache manifest, and this caveat is the one that change the audience reaction from nodding heads to “oh no, another thing I have to spend time working out how to rebuild my application in order to use”.
Again, I understand the rationale for the design, but I think a way to say “if the user agent is online, block until the cache manifest is downloaded” would significantly improve adoption and widen the appropriate use-cases for the technology. |
| Scott Jehl | I agree – the necessary refresh is the biggest downfall for me, too. It’s really prohibitive for using appcache in progressive enhancement approaches (where there’s actually HTML content in the page that may update regularly).It’d be great if you could set up appcache to kick-in when the user is actually offline, but otherwise stay out of the way and let the browser defer to normal requests and caching. |
| Yehuda Katz | I actually think we can get away with a more aggressive approach. When the device is online, first request the application manifest. If the manifest is identical, continue using the app cache. This means a short blocking request for the app manifest, but the (good) atomic cache behavior. If the manifest is not identical, fall back to normal HTTP caching semantics.
It needs to be a single flag in the manifest I think. |
| Dion Almaer | Totally agree. In a recent mobile project we ended up writing our own caching system that had us use HTTP caching… It was very much a pain to have to do this work. |
I like Yehuda’s suggestion about a blocking manifest check when the user is online controlled by a flag in the manifest file. We need more thinking around how to improve app cache. Please checkout the W3C Workshop on The Future of Off-line Web Applications website and send them your thoughts.