It is very important to speed up Page Load Time – don’t get me wrong. It is the initial perceived performance by a user who interacts with your site. But it is not all we need to focus on. Most of the time in modern web applications is spent in JavaScript, DOM Manipulations, XHR Calls and Rendering that happen after the initial page load. Automatic verification against Best Practices won’t work here anymore because we have to analyze individual user actions that do totally different things. The way this will work is to analyze the individual user actions, track performance metrics and automate regression detection based on these measured values.

From David Walsh comes a good writeup on the HTML5 link prefetch tag:

You use the link tag to do prefetching, setting the rel to "prefetch" and giving the URL to the resource to prefetch. When should you use link prefetching?

Whether prefetching is right for your website is up to you.  Here are a few ideas:

• When a series of pages is much like a slideshow, load the next 1-3 pages, previous 1-3 pages (assuming they aren't massive).
• Loading images to be used on most pages throughout the website.
• Loading the next page of the search results on your website.

Some things to know about link prefetching though:

A few more notes about link prefetching:

• Prefetching does work across domains, including pulling cookies from those sites.
• Prefetching can throw off website statistics as the user doesn't technically visit a given page.
• Mozilla Firefox, currently the only browser to support prefetching, has actually supported prefetching since 2003.

Steve Souders just pointed me to the great news that two great open source performance projects are working well together:

Pat Meenan just blogged about Page Speed results now available in Webpagetest. This is a great step toward greater consistency in the world of web performance, something that benefits developers and ultimately benefits web users.

The Page Speed SDK gives a path for folks to unify behind standard performance metrics and results. Great work!

One of his posts from 2008 entitled "Compression using Canvas and PNG-embedded data" had a good idea: if you want to compress JavaScript and CSS you could reverse engineer a packing algorithm in JavaScript or you could use a lossless packing system that is already in use and supported in browsers. In this case the packed format is PNG and the way to unpack it is by using the canvas API's getImageData() method:

As there are quite some interesting competitions going on that need really small JavaScript solutions Alex Le took up Jacob's work and wrapped it in a build script that concatenates, packs and converts to a PNG and unpacks it for the 10K competition with a JavaScript. In the process Alex also found some bug in Internet Explorer 9's canvas implementation as it only reads the first 8192 bytes of a PNG and returns 0 for the others :(.

It is pretty amazing how efficient this way of packing is. What we need to test now is when and if it is worth while to have the unpacking done on the client. Imagine adding your JS and CSS to the end of an image and cropping it in CSS to have all the info you need in an app in a single HTTP request. Let the games begin.

The advice?

The important thing is to always remember that reflowing and rendering HTML is the single most expensive operation browsers do. If your page feels sluggish it’s most likely a problem with rendering. While the easiest way to optimize is to get rid of as many nodes as you can, and trying to have simpler CSS rules, sometimes JavaScript is the culprit.

Following changes to the page, a Javascript query like someElement.offsetHeight will block execution - to give you the right answer, any pending reflow has to be executed first. So code like this:

could be twice as fast if you wrote it like this:

because there are two reflows in the first example, and only one in the second.

Interest in Canvas, as well as mobile apps, has led to a renaissance of old-school 8-bit graphics. Joe Huckaby of Effect Games has been playing around with color cycling, leading to some stunning effects.

Anyone remember Color cycling from the 90s? This was a technology often used in 8-bit video games of the era, to achieve interesting visual effects by cycling (shifting) the color palette. Back then video cards could only render 256 colors at a time, so a palette of selected colors was used. But the programmer could change this palette at will, and all the onscreen colors would instantly change to match. It was fast, and took virtually no memory.

There's a neat optimization going on here too: instead of clearing and redrawing the entire scene with each frame, he only updates the pixels that change:

In order to achieve fast frame rates in the browser, I had to get a little crazy in the engine implementation. Rendering a 640x480 indexed image on a 32-bit RGB canvas means walking through and drawing 307,200 pixels per frame, in JavaScript. That's a very big array to traverse, and some browsers just couldn't keep up. To overcome this, I pre-process the images when they are first loaded, and grab the pixels that reference colors which are animated (i.e. are part of cycling sets in the palette). Those pixel X/Y offsets are stored in a separate, smaller array, and thus only the pixels that change are refreshed onscreen. This optimization trick works so well, that the thing actually runs at a pretty decent speed on my iPhone 3GS and iPad!

The IE9 team wants to make it easier for developers and added a new Web Timing API in the browser. Web Timing is a W3C working draft and the API implemented the NavigationTiming part of the spec in window.msPerformance.timing and offers you a few sets of information without having to hack your own solution:

You have even more granular control in timingMeasures

Read the original post on MSDN and check out the demo on IE Test Drive

This is where Mike Samuel of Caja, and Lindsey Simon of Browserscope come in. They have a plan to help reverse code bloat with JavaScript:

Lots of compilers (incl. (JSMin, Dojo, YUI, Closure, Caja) remove unnecessary code from JavaScript to make the code you ship smaller. They seem like a natural place to address this problems. Optimization is just taking into account the context that code is going to run in to improve it; giving compilers information about browsers will help them avoid shipping code to support marginal browsers to modern browsers.

The JavaScript Knowledge Base (JSKB) on browserscope.org seeks to systematically capture this information in a way that compilers can use.
It collects facts about browsers using JavaScript snippet. The JavaScript code (!!window.JSON && typeof window.JSON.stringify === 'function') is true if JSON is defined. JSKB knows that this is true for Firefox 3.5 but not Netscape 2.0.

Caja Web Tools includes a code optimizer that uses these facts. If it sees code like if (typeof JSON.stringify !== 'function') { /* lots of code */ } it knows that the body will never be executed on Firefox 3.5, and can optimize it out. The key here is that the developer writes feature tests, not version tests, and as browsers roll out new features, JSKB captures that information, letting compilers produce smaller code for that browser.

The Caja team just released Caja Web Tools, which already uses JSKB to optimize code. We hope that other JavaScript compilers will adopt these techniques. If you're working on a JavaScript optimizer, take a look at our JSON APIs to get an idea of what the JSKB contains.

You can see graphically how this works and learn more about how browser detection info is packaged:

Definitely feels like there is a lot of room to do more with a compilation step that only sends down the right JS for the given browser.

You can now strap on some preloading goodness to your YUI application:

As well as just loading away, you can also wait for the user to focus on something on the page before reloading:

Or, to take it even further, only preload if the user is probably idle:

Nicely packaged.

It's the World Cup again. Being a Brit, I am on tender hooks with the first England game coming up tomorrow with the USA. A family feud for me. We start to see great microsites such as the Twitter @worldcup site, and as we think about what the fastest goal will be... what about the fastest website?

Dynatrace had some fun and did a performance test on FIFA.com:

• Time to First Impression/Drawing: 3.74s
  • Analysis: so it takes almost 4s until the user sees a visual indication of the page load – that is definitely too long and should be improved
  • Recommendation: < 1s is great. <2.5s is acceptable
• Time to onLoad: 8.25s
  • Analysis: it takes the browser 8.25 to download the initial document plus all referenced objects before it triggers the onLoad event that allows JavaScript to modify the page after it has been loaded – again – much too slow as nobody likes to wait 8s until the content is loaded
  • Recommendation: < 2s is great. <4s is acceptable
• Time to Fully Loaded: 8.6s
  • the page loads additional resources triggered by JavaScript onLoad handlers. I consider the page as fully loaded when all these additional requests are downloaded. I guess I don’t need to mention that 8.6s is not fast
  • Recommendations: < 2s is great. <5s is acceptable
• Number of HTTP Requests: 201
  • Analysis: 201 – that’s a lot of elements for a single page. We have seen many images that are the main contributor to this load. My first thought on this -> let’s seen how we can reduce this number by e.g.: merging files (more details later)
  • Recommendations: < 20 is great. < 100 is acceptable (This one is a hard recommendation as it really depends on the type of website – but – it is a good start to measure this KPI)
• Number and Impact of HTTP Redirects: 1/1.44s
  • Analysis: This is a very expensive and it seems unnecessary redirect from http://www.fifa.com/worldcup to http://www.fifa.com/worldcup/
  • Recommendations: 0. Avoid Redirects whenever possible
• Number and Impact of HTTP 400’s: 1/0.71s
  • Analysis: There seems to be a javascript file that results in a HTTP 403 Forbidden Response and takes a total of 0.71s.
  • Recommendations: 0. Avoid any 400’s and 500’s
• Size of JavaScript/CSS/Images: ~370kb/220kb/890kb
  • Analysis: Size of individual mime types is always a good indicator and helps to compare to other sites and other builds. 370kb of JavaScript and 220kb of CSS can probably reduced to a smaller size by using certain minimization techniques or by getting rid of unused code or styles
  • Recommendations: It is hard to give a definite threshold value. Keep in mind that these files need to be downloaded and parsed by the browser. The more content there is the more work on the browser. The goal must be to remove all information that is not needed for the current page. I often see developers packing everything in a huge global .js file. That might be a good practice but too often only a fraction of this code is actually used by the end-user. It is better to load what needs to be loaded in the beginning and delay load additional content when really needed
• Max/Average Wait Time: 4.31s/1.9s
  • Analysis: this means that resources have to wait up to 4.3s to be downloaded and that they have to wait 1.9s on average. This is way to much and can be reduced by either reducing the number of resources or by spreading them on multiple domains (Domain Sharding) in order to allow the browser to use more physical connections.
  • Recommendations: < 20ms is good. < 50ms is acceptable (as you can see – we are FAR OFF these numbers in this example)
• Single Resource Domains: 1
  • Analysis: from the timeline we can also see that there is one domain that only serves a single resource. In this particular case it seems to be serving an ad. We can assume that this might not be changeable but this KPI is a good indicator on whether it is worth paying the cost of a DNS Lookup and Connect if we only download a single resource from a domain
  • Recommendations: 0. Try to avoid single resource domains. It is not always possible – but do it if you can

The KPI’s tell me that the page is way too slow – especially the Full Page Load Time of 8.6s needs to be optimized. With the KPI’s we can already think about certain areas to focus on, e.g.: reducing the network roundtrips or minimizing content size. But there is much more. Let’s have a closer look into 4 different areas.

Then they get to analysis on the network, caching, JavaScript execution, and is all adds up to an F :/

• Browser Caching: F – 175 images have a short expires header, 4 have a header in the past
• Network: F – 201 Requests in total, 1 Redirect, 1 HTTP 400, duplicated image requests on different domains
• Server-Side: C - 10 App-Server Requests with a total of 3.6s -> analyze server-side processing
• JavaScript: D - Use CSS Lookups by ID instead of Class Name

Makinde Adeagbo gave that great talk at JSConf about the copious amount of code they were able to delete while speeding up the site. With folks like him and Tom Occhino on the case, you know good things are happening.

If you do a view source on the Facebook home page these days, you see a lot of this:

This is BigPipe, and it is explained by this Facebook Note:

To exploit the parallelism between web server and browser, BigPipe first breaks web pages into multiple chunks called pagelets. Just as a pipelining microprocessor divides an instruction’s life cycle into multiple stages (such as “instruction fetch”, “instruction decode”, “execution”, “register write back” etc.), BigPipe breaks the page generation process into several stages:

1. Request parsing: web server parses and sanity checks the HTTP request.
2. Data fetching: web server fetches data from storage tier.
3. Markup generation: web server generates HTML markup for the response.
4. Network transport: the response is transferred from web server to browser.
5. CSS downloading: browser downloads CSS required by the page.
6. DOM tree construction and CSS styling: browser constructs DOM tree of the document, and then applies CSS rules on it.
7. JavaScript downloading: browser downloads JavaScript resources referenced by the page.
8. JavaScript execution: browser executes JavaScript code of the page.

The first three stages are executed by the web server, and the last four stages are executed by the browser. Each pagelet must go through all these stages sequentially, but BigPipe enables several pagelets to be executed simultaneously in different stages.

The picture above uses Facebook’s home page as an example to demonstrate how web pages are decomposed into pagelets. The home page consists of several pagelets: “composer pagelet”, “navigation pagelet”, “news feed pagelet”, “request box pagelet”, “ads pagelet”, “friend suggestion box” and “connection box”, etc. Each of them is independent of each. When the "navigation pagelet" is displayed to the user, the "news feed pagelet" can still be being generated at the server.

In BigPipe, the life cycle of a user request is the following: The browser sends an HTTP request to web server. After receiving the HTTP request and performing some sanity check on it, web server immediately sends back an unclosed HTML document that includes an HTML tag and the first part of the tag. The tag includes BigPipe’s JavaScript library to interpret pagelet responses to be received later. In the tag, there is a template that specifies the logical structure of page and the placeholders for pagelets.

Performance results

The graph below shows the performance data comparing the 75th percentile user perceived latency for seeing the most important content in a page (e.g. news feed is considered the most important content on Facebook home page) on traditional model and BigPipe. The data is collected by loading Facebook home page 50 times using browsers with cold browser cache. The graph shows that BigPipe reduces user perceived latency by half in most browsers.

Thomas has a great post today on how he took the lovely Every Time Zone HTML5 app for the iPad and went deep to make it perform smoothly to match its beauty.

He has documented what he did:

• Canvas optimizations over images: Thomas found out that using -webkit-gradient produces images which slow down the rendering on the iPad itself. His optimization was to use a <canvas> and only repaint what was needed.
• Avoid text-shadow & box-shadow: Great. but slow
• Hardware-acceleration is quite new… and buggy (aside: he called out some new scripty2 hw accel demos coming maybe as soon as next week!)
• touch events fire before click events (use element[supportsTouch ? 'ontouchmove' : 'onmousemove'] = function(){})
• Avoid opacity: Found that it can interfere with hw acceleration
• Don't use a js lib unless you need it. Every bit matters

Maybe iPhone OS 4 will change the characteristics.... but who knows. Good stuff.

Show Slow will fire YSlow and Page Speed at your site and collect statistics on a daily basis so you can just sit back and enjoy the graphs!

You can also check out the Alex 100 scores.

Steve Souders said:

Reassuring that the correlation coefficient of Alexa 100 YSlow and Page Speed scores is 0.83!

A very nice utility. Why wouldn't you monitor your scores?

Well, Selim Arsever has found a similar tip for Canvas that caused a ~40% performance improvement on some of his code. He had an example that did pixel twiddling, looking like:

After listening to Stoyan talk perf, he wondered if there was an issue with the image.data access, and changed the code to:

He wrapped this all up in a benchmark that showed the perf diff. It actually really seemed to matter when using closures for namespaces:

After Moonwatcher ran SunSpider on the iPad, he concluded:

It's one thing not to be able to run Flash apps. But JavaScript performance like this effectively means the iPad can't run complex JavaScript apps either. Interesting.

Many folks in the comments are quick to retort that:

And have you noticed this to be an actual problem, in practice, or are you just obsessing over benchmarks?

and:

Heavy ajax sites like gmail run quite well on the iPad. Yes, I have an iPad and use it for such sites everyday (including for writing this post).

But it got me curious: what have you noticed about the iPad's performance and your web apps? Does it inhibit the types of experiences you're trying to create?

In my own experience, mobile devices have shown us that JavaScript-driven animations are generally a bad idea when you want multiple sprites or extreme performance, but CSS animations are there to fill the gap. Otherwise, JS perf. on mobile is generally fine for what I've tried to do.

I also find it interesting that while the iPad is slower than my MacBook Pro, I rarely notice it--and I certainly haven't noticed anything as dramatic as an alleged 27x gap. Have you?

Releasing the Page Speed SDK (all open source) is one step closer to having a common performance metric across all web development tools and environments. Imagine being able to get the same performance analysis results from Firebug, Web Inspector, HttpWatch, Fiddler, Keynote, and Gomez. This will help us develop a common vocabulary and bring more consistency and quality to the field of web performance optimization.

This is a quote from Steve on the new HAR to Page Speed work that he has built on top of other work:

The importance of an industry standard HTTP archive format is huge. Adoption of HAR allows companies and data gathering institutions (such as the Internet Archive) to record the web page experience and pull it up later for further review. It provides a way to exchange information across tools. And it provides an open standard for sharing web loading information between individuals – developer to developer as well as customer to customer support.

In their last few releases the Page Speed team has mentioned porting their performance analysis logic from JavaScript to C++. The resulting library is called “native library” – not too jazzy. But last week they released the Page Speed SDK. The documentation is slim, but I noticed a command-line tool called har_to_pagespeed.

I downloaded the SDK. It built fine on my Dreamhost shared server. Then I wrapped it with a file upload PHP page and created HAR to Page Speed.

Once you upload a HAR file you get page speed info and more:

For a full example, check out a CNN.com archive.

(Live blogging notes.)

At JSConf, Steve Souders walks us through several performance-optimising things on his mind lately.

Site Speed in PageRank

A week ago, Google announced site speed is going to be taken into account for PageRank. For Steve, this is a dream come true. Now companies are going to start investing in performance, so less of those slow-loading sites that frustrated him enough to get started down this performance path. One of the criticisms is that this will favour big companies, but Steve points out that smaller companies are often more nimble and able to adapt to changes like this.

As part of Google's webmaster tools, site performance is shown to respective site masters, along with some guidance. Another good resource is http://www.webpagetest.org/. Other than its main measurement service, a great feature of WebPageTest is side-by-side comparisons. Show your manager a side-by-side against a competitor for guaranteed satisfaction.

Performance of Third Party Widgets

There's been something of a reversal in performance hotspots. Five years ago, it was the core application code that was mostly slowing things down, much as teams would like to blame performance problem on 3rd party ads. Nowadays, those apps have been more finely tuned, and at the same time, people are using more 3rd party stuff - not just ads, but embedded widgets. All of which explains why Steve's been looking at third-party widgets lately. You can see what he's been up to at P3PC, a benchmark tool for third-party widgets.

A key question is how are the widgets embedded? People are no longer just doing the blocking document.write calls. Instead, it's much more common to dynamically create a script tag and append to the page. But where and how do you append it? jQuery's library code, for example, does it in a simple, elegant, manner:

Others, not so much. See Steve's recent blog posts for more analysis on these techniques (e.g. on Google Analytics).

Frag Tag

An early proposal from Steve and Alex Russell ...

<FRAG>
<script src="snippet.js"></script>
</FRAG>

The idea is that the frag loads independently; even document.write doesn't block. And it could go further, into a sandboxing mechanism. "If we had this frag tag, it would be one of the biggest things website owners could do to improve the performance of their pages."

Browser Disk Cache

The main message here is that browser disk cache is too small, and he's been talking to vendors about upping capacity. And there's a survey for you.

What makes sites feel slow?

So lately Steve's been going back to basics and looking at user perception, thinking not just about how fast the Javascript takes to load, but how fast till the user sees anything. So he's promoting the standard progressive enhancement pattern, similar to Facebook's earlier talk:

* Deliver HTML
* Defer JS
* Avoid DOM
* Decorate later.

He's done a couple of studies to this end:

* Charting page load time - as the user actually sees it - against market share...in an attempt to show faster sites mean bigger market share.
* Looking at initiail payload versus execution. Many of the sample (highly popular) sites are serving many functions on initial payload, which could be deferred until later - putting scripts at the bottom of the page, and loading scripts asynchronously.

Other Stuff

Check out:

* Browserscope, "a community-driven project for profiling web browsers".

* HTTP Archive Format (HAR). An industry standard for capturing Used in an increasing number of tools, e.g. NetExport plugin in Firebug.

* Velocity Conference, which Steve founded with O'Reilly. June 22-24, Santa Clara.

(Live blogging notes.)

Makinde Adeagbo is describing Facebook's Javascript performance optimisation efforts at JSConf. By 2009, it became clear something had to be done, as the trend was towards longer and longer page loads. Back in 2006, the objective had been super fast page loading: "If any page loads in under 100ms, it takes way too long". By 2008, given all the new interactive features on the page, the 100 millisecond target had expanded to 1 second, and by mid-2009, pages were taking 5 seconds to load. Even HipHop, the PHP compiler, was smaller than the Javascript code base. And when Steve Souders called out Facebook in his book numerous times, it only adding to the team's sense of fun and joy ;).

In June 2009, the team quickly chose a target by year's end by simply checking the load time without Javascript: 2.5 seconds. Thus, dropping load time from 5 seconds to 2.5 seconds was the goal for end of 2009.

The first initiative was to include the Javascript at the bottom of the page. Great, it's faster, but at what cost? A big one: Users try to click on controls, and nothing happens. Back to the drawing board, and the team refined the setup so that the actionable stuff was initialised on the top of the page. But how to minimise all this code at the top of the page? Here, the team exploited the observation that most controls work the same way:

* User clicks
* Sends ASync request
* Insert/Replace some content

So the team set up elements like this:

<a href="/ring.php rel="dialog">...</a>

... And then hijacked them with a standard listener routine, one that would work for most of the controls. (Most, not all; 80/20 principle is in effect here.) This way, they could have one small listener routine to handle most of the controls on the page. Once the user clicks, the server gets called and outputs a new snippet of Javascript:

The Javascript:

would be output by a PHP script, and then evaluated in the browser:

(A form of On-Demand Javascript.)

In fact, the team has a whole PHP library for outputting Javascript. For example, when a request comes in to expand a new story:

And they are using a convention: "ajaxify=1" on an element indicates it's ... Ajaxified.

At this point, the team had now Ajaxified a bunch of features, but people were still skeptical about more complicated features. For example, would setting status be too hard with the same techniques. So after some research, Makinde came back with an epiphany: the humble form. Whereas the previous async requests were effectively information-less - just a simple directive and maybe an ID - the requests would now include content too. And of course, most of these things look nothing like forms due to styling. But underneath, they're still forms, e.g. the entire comments block is a single form.

Nowadays, most of Facebook runs without complete page refreshes, by dynamically flipping the content and the fragment ID. (What Facebook calls page transitions.)

Ongoing, Makinde says performance optimisation requires ongoing vigilance. Every engineer has their special case, but in the scheme of things, it's better to say no to new features unless they can be strongly justified. For example, we can live with user submitting a form that hasn't yet been hijacked; a complete page refresh is fine on occasion. We don't like it, but we don't want to make it a special case just for the sake of it.

The Gantt charts tell a great tale: users now see content much earlier, and it's interactive. So how did they fare with that 2.5 second goal for year's end? Achieved by December 23. And Makinde wants people to know Facebook is hiring as they have more Javascript to write...and delete.

UPDATE: And here are the slides ...

As part of their on-going efforts to engage directly with the web developer community, Mozilla hosted a Web Caching Summit earlier this week to discuss how the web platform could better meet the needs of developers. In attendance were developers who work on Facebook, Google Search, Microsoft Office Live, Twitter, Yahoo, SproutCore, and Palm webOS. Arun Ranganathan moderated the gathering.

One of the core challenges identified by the group was that frequent visitors of a site are often missing resources in their browser cache that the site authors think should be there. In other words, why is the same user requesting a static cacheable image with a year-long expiration every few days?

A lively discussion ensued over 5 hours talking about this problem and others, touching on why this is the case and what page developers could do to maximize the cache-ablity of their websites.

A high-level summary of the outcome is:

- browsers should immediately investigate increasing the size of the browser cache
- Mozilla will learn more about caching behaviors in the browser, perhaps by using Test Pilot to collect more information from end users
- Mozilla will investigate means of prioritizing content in the cache, either by allowing developers to prioritize content (i.e., set some content on the page as a higher cache priority than others) or through implicitly prioritizing (e.g., CSS and JS above images).

What do you think browser vendors could do to improve caching?

However, if you are running require()-esque loader code in the browser you want to avoid blocking calls else Steve Souders will come over and beat you up.

I have seen a couple of interesting items in this area:

RequireJS

James Burke of Mozilla Messaging has spent a lot of time in the depths of dojo.require(). He has taken another look at the problem and RequireJS a solution that offers:

• some sort of #include/import/require
• ability to load nested dependencies
• ease of use for developer but then backed by an optimization tool that helps deployment

He walks through the problem and why other solutions like LABjs, CommonJS require, and Dojo itself don't cover all of his bases.

The end result is:

Google Analytics "async add to []" Pattern

When talking to Davis Frank of Pivotal about some Google Analytics code, he pointed me to details about the new GA asynchronous loader that we very excitedly blogged about since GA was such a blocking offender on the Web.

Part of the asynchronous API is that you, the developer create an array, and use the push() method to put commands on a queue. This means that you can start pushing commands immediately.

Then, when the GA code loads asynchronously, it takes over that array and wraps those standard methods. Now it can take the commands and fire them back to GA and push() can do more. Freaking brilliant.