kylescholz.com :: blog http://www.kylescholz.com/blog/ en Copyright 2012 Mon, 20 Dec 2010 13:20:52 -0500 http://www.sixapart.com/movabletype/?v=5.01 http://blogs.law.harvard.edu/tech/rss Performance Calendar Each day this month, a web performance expert is posting an article on Performance Calendar. There is some really fantastic content here.

My contribution is Faster Ads with HTML5.

]]> http://www.kylescholz.com/blog/2010/12/performance_calendar.html http://www.kylescholz.com/blog/2010/12/performance_calendar.html performance Mon, 20 Dec 2010 13:20:52 -0500 HTML5 History is the Future HTML5 exposes a new API for web application developers to work with the history stack: 
interface History {
  ...
  void pushState(in any data, in DOMString title, in optional DOMString url);
  void replaceState(in any data, in DOMString title, in optional DOMString url);
};
interface HTMLBodyElement : HTMLElement {
  ...
  attribute Function onpopstate;
};

The new interface provides push/pop semantics that, until now, we've emulated using JavaScript libraries like Really Simple History.

Web Apps and History

Web applications need to interact with the browser history to support bookmarkable and "back-buttonable" states. This is a pretty common feature of Ajaxy applications. For example, visit http://www.viewru.com/#Bonobo and browse or search for your favorite musician. The application uses an Ajaxy, single-window-context model to keep the music playing while you browse, but supports bookmarks and the back-button because users expect these features to work in their browser.

Prior to the HTML5 History additions, a solution to this problem involved these two parts: 

// Store a representation of the state in the location hash
function setState(state) {
  window.location.hash = state;
}
// Detect a change to location.hash
var lastState;
window.setTimeout(function() {
  var state = window.location.hash;
  if (lastState != state) {
    lastState = state;
    handleState(state);
  }
}, 100);

The solution is less than ideal for several reasons:

Sluggishness
  • Executing a timeout function every 100ms won't make your app any faster.
  • 100ms delay in responding to back button actions.

Browser compatibility
  • The solution above doesn't work, for example, in IE 6-7, which won't add a history event on a hash change. Really Simple History gets around this by adding an iframe and issuing a call to your server for every state change. Webkit browsers present different challenges.

Not a stack
  • Suppose your application transitions from A->B->C. Can it transition directly back to A?

The HTML5 version looks like this: 

// Push the state onto the history stack
function setState(state) {
  window.history.pushState(state, '');
}
// Respond to a popstate event.
window.onpopstate = function(e) {
  handleState(e.state);
};

Here, state may be a string representation of the current application state, but it can also be an object. Note that it will be deep-copied on each pushState() operation.

Storing application state in the hash is a hack

You may point out that the new hashchange event in HTML5 addresses concerns about sluggishness, but why use location.hash at all? Storing application state in the location hash presents some real problems and limitations. Here's a short list:

  • Content isn't crawlable: Most crawlers do not execute JavaScript or traverse dynamic fragment ids. If you want users to find your site and content via Search Engines, this just won't do.
  • Audible "click" in IE: For some reason, IE makes a sound every time you update the location. Imagine if your application updated the location on every mousemove event!
  • HTTP-Referer is inaccurate or missing data: The fragment ID isn't exposed in the referrer.
  • Handling bookmarks requires extra round trip:
    • Fetch myApp.html
    • Parse myApp.html#myState (server can't see myState)
    • Fetch myState
  • Legacy (and non-JS) browsers effectively have different URI schemes and can't share bookmarks and links.

HTML5 History and URLs

Perhaps the most interesting feature of the new pushState() and replaceState() interfaces is the optional url argument. For the first time, web developers are able to change the effective URL to represent a change in application state without navigating away from a window context. It's very powerful. The location bar, bookmark service, and HTTP-Referer all reflect the new URL. This feature addresses many of the issues I mentioned above:

  • Content is crawlable: A developer may express all crawlable states of their application as valid URLs.
  • HTTP-Referer is meaningful: The referrer can reflect the latest state of the application and show or hide any information to/from 3rd parties, at the developer's discretion.
  • Bookmarks can be handled in a single fetch: Since application state can be expressed in a URL, it's possible to service a request for the application and state in one request/response.
  • Can use a single URI scheme to cover new and old browsers: Since information is encoded in URLs instead of the location hash, modern and legacy users can share bookmarks and links.
  • Audible "click" in IE? Okay, I don't know about this one, but it makes sense that programmatic operations on window.history would not have an audible side effect, right?

Availability and further reading

You can take these new features for a spin in Firefox nightlies. For more info, see:

]]> http://www.kylescholz.com/blog/2010/04/html5_history_is_the_future.html http://www.kylescholz.com/blog/2010/04/html5_history_is_the_future.html html5 Sun, 11 Apr 2010 13:59:10 -0500 It's pronounced "vyoo-roo" viewru. It also now works on Chrome 3 in addition to Chrome 4. On non-Chrome browsers, the user experience has been simplified so that it's reasonably performant. So browse and listen away with your browser of choice.

Also, nearly everyone that's asked me about viewru doesn't know how to pronounce it. I pronounce it "vyoo-roo" (like "guru" with a "view").]]> http://www.kylescholz.com/blog/2010/02/its_pronounced_viewroo_and_1.html http://www.kylescholz.com/blog/2010/02/its_pronounced_viewroo_and_1.html viewru Thu, 04 Feb 2010 21:55:38 -0500 Progressive XMLHttpRequest draft spec for XMLHttpRequest calls for support for progressive response handling:

4.7.6 The responseText attribute

The responseText attribute must return the result of running these steps:

1. If the state is not LOADING or DONE return the empty string and terminate these steps.

2. Return the text response entity body.

To rephrase for my purposes, responseText should return the intermediate contents of the response when an XMLHttpRequest is interrogated during the LOADING state. It'll take a little work to handle these partial responses as valid script, but let's first address browser support. Firefox and Webkit browsers already support this behavior if you set the Content-Type header of your response correctly. IE8 throws an exception when responseText is accessed before readyState reaches COMPLETE.

I ran a modified version of the streaming response tests I used in my last post to verify progressive XHR handling. The server returns several chunks in 100ms intervals that include script that indicates how much of the response was received before it is first handled by the browser.

  Bytes Buffered
Configuration Firefox 3.5 Chrome 3.0 IE 8
Tranfer-Encoding: chunked 111 536 N/A
Content-Type: text/html
Tranfer-Encoding: chunked 		111 N/A N/A
Content-Type: text/plain
Tranfer-Encoding: chunked
 		111 85 N/A
Content-Type: application/x-javascript
Tranfer-Encoding: chunked 		111 111 N/A

For Webkit browsers, it's critical to specify a Content-Type of "text/plain" or "application/x-javascript" when returning script content to an XHR for progressive handling. Seems reasonable, but it's easy to neglect. In my testing, I didn't see any change in behavior in the presence of a "charset" param.

Note that Microsoft's documentation for XMLHttpRequest now refers the to draft specification. I'm hopeful that we'll be seeing support for progressive responses soon.

Now, since we'll be interpreting partial response content as executable script, we'll need to do something to ensure that each chunk we evaluate terminates on a complete expression. For this test, I added delimiters between valid blocks of source: 

window.aFunction();
// -- //
window.bFunction();
// -- //

Where //--// is the delimiter. When outputting using chunked transfer encoding, you might organize code so that a delimiter is present at the end of each chunk boundary. On each readyState change, if the state is LOADING or DONE, I call a function to read the new content, identify a safe place to trim it, and append it to a buffer. 

var index = 0;
var buffer = '';
var DELIMITER = '//--//';

function handlePartialResponse(request) {
  var i = request.responseText.lastIndexOf(DELIMITER);
  if (i > index) {
    i += DELIMITER.length;
    var newChunk = request.responseText.substr(index, (i - index));
    buffer += newChunk;
    index = i;
    flushBuffer();
  }
}

Finally, we evaluate the contents of the buffer. It's not necessary to remove the delimiter, since it's a valid JavaScript comment. 

function flushBuffer() {
  window.eval(buffer);
  buffer = '';
}

What would you use this for? Consider this technique for the response channel in your next Comet app or any time you're able to deliver part of a script response while doing expensive server side work to produce the rest.]]> http://www.kylescholz.com/blog/2010/01/progressive_xmlhttprequest_1.html http://www.kylescholz.com/blog/2010/01/progressive_xmlhttprequest_1.html performance Tue, 05 Jan 2010 23:07:08 -0500 Performance Implications of "charset". a post documenting the progressive response handling behavior of different browsers. I was specifically interested in how many bytes must be received or how much time must pass before a browser begins to parse content. My friend and colleague, Bryan McQuade (a co-author of Google PageSpeed), recently pointed out that character encoding detection is the source of buffering delay in response handling. Specifically, in the absence of a "charset" param in the Content-Type header, a browser may buffer a large quantity of content while looking for a <meta> tag declaring the content encoding.

I set up a new round of tests to identify the impact that content encoding declarations have on progressive response handling in different browsers. As in previous tests, the server returns several chunks, in 100ms intervals, each containing script that indicates how much of the response has been received.

  Bytes Buffered
Configuration Firefox 3.5 Chrome 3.0 IE 8
Tranfer-Encoding: chunked 1134 1056 300
Content-Type: text/html
Tranfer-Encoding: chunked 		204 1056 341
Content-Type: text/html
Tranfer-Encoding: chunked
...
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 		166 204 218
Content-Type: text/html; charset=utf-8
Tranfer-Encoding: chunked 		204 280 300

Note that the test doesn't account for content in the document <head>, so the numbers for the <meta> configuration are artificially short by ~70b.

It's clear that for Chrome and Firefox, indicating the charset has a measurable impact on performance. Now, is it more desirable to declare the charset in the Content-Type header or a <meta> tag? Darin Fisher suggests that placing it in the response header is more performant: The charset impacts how the response is parsed, so when the browser encounters the <meta> tag, it must reprocess everything it's handled so far. If you're forced to use the <meta>, place it as near as possible to the top of the document to reduce the amount of throwaway work done by the browser.]]> http://www.kylescholz.com/blog/2010/01/performance_implications_of_charset.html http://www.kylescholz.com/blog/2010/01/performance_implications_of_charset.html performance Sun, 03 Jan 2010 23:03:45 -0500 ViewRu: An Interactive Music Browser and Player JSViz and a whole bunch of demos to explore the space. A major point of frustration was JavaScript and DOM performance, especially while scaling the number of items or edges in a graph. JavaScript->DOM interaction has greatly improved in the latest generation of browsers, so a few weeks ago I set out to turn an old demo into a useful application:


ViewRu is an interactive music browser and player. It uses artist relationships from open APIs and music streams from YouTube to provide a single interface for exploring and listening to music. Presently, it takes advantage of browser features and performance only available in Google Chrome 4.

Check it out at www.viewru.com and let me know what you think.]]> http://www.kylescholz.com/blog/2010/01/viewru_an_interactive_music_br.html http://www.kylescholz.com/blog/2010/01/viewru_an_interactive_music_br.html viewru Sun, 03 Jan 2010 21:46:41 -0500 Firefox Paint Events Update I recently posted about a Firefox / Firebug extension for digging into Firefox's new MozAfterPaint events. I just posted my second update to the Firefox Addons site. In addition to highlighting the clip area of paint events, this update adds screenshots so it's possible to see the page state at the time of an event:

Note that capturing the screen for each paint event adds significant overhead, so it's wise to leave this feature disabled when not actively using it. Other handy features include the ability to view event details on the Firebug DOM tab:

And dig into the complete events details:

The "image" attribute above is a data URL of the screen capture. I imagine this will have some other practical uses. Some other event types are logged for reference, and clicking on any event will reset the base time to the time of that event, to make it easier to see how actions relate to paints:

To use this extension, you will need a 3.1+ Firefox pre-release and Firebug 1.3. You can pick up the latest version of Firebug Paint Events here.

]]> http://www.kylescholz.com/blog/2009/01/firefox_paint_events_update.html http://www.kylescholz.com/blog/2009/01/firefox_paint_events_update.html performance Sun, 18 Jan 2009 17:16:55 -0500 Progressive Script Execution Recently I've been speaking to colleagues about progressive script execution, and it seems like a little-explored topic, so I'm sharing what I know. By progressive execution, I mean that scripts begin executing in the browser before the containing resource has been wholly received.

Dealing with Dynamic Response Sizes

One of the first hurdles people encounter with progressive response handling is that most HTTP responses have a Content-Length in the response header. This means that the size of the response must be known before any data is sent over the network. For static resources, this isn't such a problem because the entire response is available at once, but for dynamic resources, this means that the entire response must be determined before any part of it can be written to the network.

Imagine your web application performs an expensive operation that takes up to half a second to complete. If it takes another 500ms on average to transfer all of your HTML and CSS to users, it will take a full second to load your page. If you could transfer the bulk of that data while waiting for the operation to complete, then tack on the final bits, you might cut your response time in half.

This can be accomplished with effective use of HTTP Chunking ("Transfer-Encoding: chunked"). Chunked responses don't require a Content-Length header, so it's possible to do work after bytes have been sent to the network. While each chunk in the response will contain a header, indicating the size of the chunk, any number of chunks can be appended until a terminating delimiter is provided.

Executing Scripts Progressively

In the hypothetical example above, we were dealing with HTML and CSS, but suppose instead that we have a large amount of script to deliver with each response. Take note, external <script>s and XHRs are not progressively interpreted*. Other methods, such as inline <script>s and iframes are required. Also note, individual script blocks are not evaluated until the full contents have been received and parsed by the client. So it's advisable to split scripts into small sections, each wrapped in it's own block: 

<script>
...
</script>
<script>
...
</script>
<script>
...
</script>

The ideal size of these script blocks will vary by application and the connection characteristics of your users. You might consider typical packet size (about 1460b) and the behavior of TCP Slow Start as a guide.

Browser Support and Caveats

To explore progressive execution, I implemented a simple HTTP server in Perl (View Source for Example #1), that writes several small chunks (real HTTP chunks) that look like: 

<script>document.write('10: 737b: ' + n() + 'ms<br>')</script>

The fields indicate the chunk number, number of bytes written to the buffer, and a function call that outputs the milliseconds since the last script execution. I was surprised by two findings:
1) Webkit browsers don't support progressive execution at all. Ouch!
2) Other browsers don't begin parsing and executing until a byte threshhold has been reached, and this threshhold varies from browser-to-browser. In IE7, my output looks like: 

0: 127b: 0ms
1: 188b: 0ms
2: 249b: 0ms
3: 310b: 969ms
4: 371b: 1015ms
...

And in Firefox 3:

0: 127b: 2ms
1: 188b: 0ms
2: 249b: 1ms
3: 310b: 1ms
4: 371b: 1ms
5: 432b: 1ms
6: 493b: 0ms
7: 554b: 1ms
8: 615b: 1ms
9: 676b: 1ms
10: 737b: 1ms
11: 799b: 0ms
12: 861b: 1ms
13: 923b: 1ms
14: 985b: 1ms
15: 1047b: 876ms
16: 1110b: 1021ms
...

This shows that the threshhold in IE7 is about 200-300b, and in Firefox3, about 1kb. While scripts won't execute until the threshhold is reached, it may still be advantageous to deliver content smaller than the threshhold early to take advantage of idle network time. Though you might consider padding your response if it enables you to provide early feedback to users.

It's not necessary to create a new chunk for each script block to achieve progressive execution, but you must be able to determine the size of each chunk before it can be written. It's also important to flush the network buffer at logical intervals (at the close of each script block, for example).

A modified version of the demo HTTP server (View Source for Example #2) demonstrates that progressive execution can be achieved within chunks. For this example, each chunk contains 5 script blocks. I precomputed the total size of each chunk, and appended the output in 1 second intervals. Output for a run in IE follows: 

0: 127b: 0ms
1: 188b: 0ms
2: 249b: 0ms
3: 310b: 1016ms
4: 371b: 922ms
...

And for Firefox 3:

0: 127b: 1ms
1: 188b: 1ms
2: 249b: 1ms
3: 310b: 1ms
4: 371b: 1ms
5: 432b: 1ms
6: 493b: 1ms
7: 554b: 1ms
8: 615b: 2ms
9: 676b: 1ms
10: 737b: 1ms
11: 799b: 1ms
12: 861b: 1ms
13: 923b: 1ms
14: 985b: 1ms
15: 1047b: 1136ms
16: 1110b: 817ms
...

That concludes my overview. I'm interested in questions and ideas for further exploration.

* XHR implementations that notify when bytes are received could theoretically be evaluated progressively, but to evaluate JavaScript safely in such a context would require a fair amount of infrastructure. Also, I haven't seen this done yet, but I'd love a pointer if anyone has.

]]> http://www.kylescholz.com/blog/2009/01/progressive_script_execution.html http://www.kylescholz.com/blog/2009/01/progressive_script_execution.html performance Tue, 06 Jan 2009 01:59:39 -0500 Digging into Paint Events in Firebug I'm always on the prowl for new tools and signals for analyzing and improving frontend performance. When Mozilla announced the new MozAfterPaint event in Firefox nightlies, I got excited and got to work.

John Resig posted a bookmarklet for viewing MozAfterPaint events, but I'm primarily interested in paint events that fire before onload(), so a bookmarklet isn't ideal. I stayed up late last night and created a simple Firebug extension for capturing and viewing these events. To use:


After restarting, you'll have a "Paints" tab in Firebug. Mouse over the events to see the clip areas highlighted.

Thanks to Mozilla for making MozAfterPaint available! I've only started digging in and I'll try to follow up with some observations. In the meantime, post away, I'm interested in yours.

]]> http://www.kylescholz.com/blog/2008/11/digging_into_paint_events_in_f_1.html http://www.kylescholz.com/blog/2008/11/digging_into_paint_events_in_f_1.html performance Sun, 16 Nov 2008 17:18:15 -0500 A Quick svg2vml Example: Gradients A couple weeks ago I mentioned the first release of svg2vml, a lightweight library that enables cross platform, JavaScript-driven vector graphics. Here's a quick example where I use svg2vml to create Digg style gradient buttons:

If you're reading from a feed reader that doesn't embed iframes, you'll need to click through to see the example.

Check out the frame source for full details. Notice that the button itself is an HTML DIV and that we use CSS and HTML elements to define and position our text. So it's possible to mix HTML and vector graphics as you see fit.

We're just scratching the surface. svg2vml can do all kinds of cool stuff. Have fun!

]]> http://www.kylescholz.com/blog/2007/03/svg2vml_example_digg_b.html http://www.kylescholz.com/blog/2007/03/svg2vml_example_digg_b.html svg2vml Mon, 26 Mar 2007 15:37:29 -0500 svg2vml Project Announced Today on the JSViz Blog, Lorien announced svg2vml, a thin translation layer that enables VML capable browsers (Internet Explorer) to display a subset of SVG without any new code.

Checkout the full post for details.

]]> http://www.kylescholz.com/blog/2007/03/svg2vml_project_announced.html http://www.kylescholz.com/blog/2007/03/svg2vml_project_announced.html svg2vml Sat, 10 Mar 2007 23:44:21 -0500 Gone Googlin' Hey friends, sorry I haven't been posting or responding to any of your e-mails lately! I assure you I've got an excuse. I'm moving from my place in Rochester, New York to California next week to start a new job with Google. I'll let you know more when I can, but please hang tight in the meantime.

I've got plenty of JSViz news to share and I'll be posting as time and wifi permit over the next week.

]]> http://www.kylescholz.com/blog/2007/02/gone_googlin.html http://www.kylescholz.com/blog/2007/02/gone_googlin.html google Fri, 09 Feb 2007 16:15:53 -0500 Tutorial: Building a Snowflake Graph from XML I just posted this new tutorial on jsviz.org...

JSViz 0.3.3 includes a few examples to help you get started. In this tutorial, I'm going to go over one of them. We'll create a Snowflake Graph from the contents of an XML file. You can find the example source, with comments based on this tutorial in the 0.3.3 Distribution.

Here's the final product

1) Start with a new HTML file

Add appropriate JSViz imports and an empty "init()" function body:

Continue reading this post at jsviz.org...

]]> http://www.kylescholz.com/blog/2007/01/tutorial_building_a_snowflake.html http://www.kylescholz.com/blog/2007/01/tutorial_building_a_snowflake.html jsviz Mon, 22 Jan 2007 20:27:27 -0500 JSViz 0.3.3 Released The jsviz.org website is now available but I'll be cross-posting big news here to keep subscribers and search traffic informed:

JSViz 0.3.3 is now available. This release includes two major features:

Snowflake Model is an updated implementation of the "Tree Model" offered in JSViz 0.2. This is a geometric model, offering superior speed to Force Directed layouts, but only capable of representing hierarchical data (sorry, no circuits).

An Example Snowflake Graph

Layouts offer a simplified interface to the core JSViz libraries. New projects can now be created with minimal code and simple configuration. Additional examples, using Layouts:

An Example Force Directed Graph with Data Loader
An Example Force Directed Graph with Randomly Generated Data

You can download the full source as a single ZIP archive or browse individual files on the Download page

I'll follow up with tutorials shortly.

]]> http://www.kylescholz.com/blog/2007/01/jsviz_033_released.html http://www.kylescholz.com/blog/2007/01/jsviz_033_released.html jsviz Sun, 21 Jan 2007 23:31:38 -0500 More Music Mashing I've received a lots of great comments and e-mails about the music recommendations demo I posted a week or so ago. But a number of you mentioned that the recommendations were a little funny. Questions and observations so far:

  • Theivery Corporation is the center of the universe! Every album ever released is 3 or fewer hops away from a Theivery Corporation album.
  • Why is every album I search for related to Beck? or Moby? or Neil Young? Though I'll point out, the man has been in almost every band that's ever released an album. Seriously, that album by the Back Street Boys and Young is one of my favorites!
  • How is this tool useful if the only related albums to my search are by the same artist?

Right. So ... There's a lesson here:

There's always a little bit of "magic" in a mashup.

The music recommendations demo gets album relationships from Amazon.com's E-commerce API. Similarity is based on buying patterns, which apparently lead to some unexpected or disappointing results. So I decided to try out an alternative.

I worked up a quick mashup using the Audioscrobbler (Last.fm) API for Artist-to-Artist recommendations. Audioscrobbler uses the listening patterns of it's users to determine relationships. Unfortunately, the images served up with this API aren't especially useful in identifying artists, especially when scaled down. So this demo is currently text-only. If you're interested, the demo could be extended to grab an album image from Amazon.com. I tried this and bailed out quickly because it added a lot of latency to the addition of new nodes, but you may be able to cut this down using an image cache.

So give it a try.

Oh, one more thing! These demos don't work so well in ie7. This isn't an issue with the JSViz 0.3.1 API. I'll fix the demos when I have some spare time. Thanks for all the feedback. It's useful in driving this project.

]]> http://www.kylescholz.com/blog/2006/11/more_music_mashing.html http://www.kylescholz.com/blog/2006/11/more_music_mashing.html visualization Sun, 05 Nov 2006 23:11:35 -0500