High Performance Web Sites blog

This is the fourth of five quick posts about some browser quirks that have come up in the last few weeks.

You can avoid blocking rendering in IE if you load stylesheets using DHTML and setTimeout.

A few weeks ago I had a meeting with a company that makes a popular widget. One technique they used to reduce their widget’s impact on the main page was to load a stylesheet dynamically, something like this:

var link = document.createElement('link');
link.rel = 'stylesheet';
link.type = 'text/css';
link.href = '/main.css';
document.getElementsByTagName('head')[0].appendChild(link);

Most of my attention for the past year has been on loading scripts dynamically to avoid blocking downloads. I haven’t focused on loading stylesheets dynamically. When it comes to stylesheets, blocking downloads isn’t an issue – stylesheets don’t block downloads (except in Firefox 2.0). The thing to worry about when downloading stylesheets is that IE blocks rendering until all stylesheets are downloaded¹, and other browsers might experience a Flash Of Unstyled Content (FOUC).

FOUC isn’t a concern for this widget – the rules in the dynamically-loaded stylesheet only apply to the widget, and the widget hasn’t been created yet so nothing can flash. If the point of loading the stylesheet dynamically is to not mess with the containing page, we have to make sure dynamic stylesheets don’t block the page from rendering in IE.

I created the DHTML stylesheet example to show what happens. The page loads a stylesheet dynamically. The stylesheet is configured to take 4 seconds to download. If you load the page in Internet Explorer the page is blank for 4 seconds. In order to decouple the stylesheet load from page rendering, the DHTML code has to be invoked using setTimeout. That’s what I do in the DHTML + setTimeout stylesheet test page. This works. The page renders immediately while the stylesheet is downloaded in the background.

This technique is applicable when you have stylesheets that you want to load in the page but the stylesheet’s rules don’t apply to any DOM elements in the page currently. This is a pretty small use case. It makes sense for widgets or pages that have DHTML features that aren’t invoked until after the page has loaded. If you find yourself in that situation, you can use this technique to avoid the blank white screen in IE.

The five posts in this series are:

• 5a Missing schema double download
• 5b document.write scripts block in Firefox
• 5c media=print stylesheets
• 5d dynamic stylesheets
• 5e speculative background images

This is the third of five quick posts about some browser quirks that have come up in the last few weeks.

Stylesheets set with media=”print” still block rendering in Internet Explorer.

A few weeks ago a friend at a top web company pinged me about a possible bug in Page Speed and YSlow. Both tools were complaining about stylesheets he placed at the bottom of his page, an obvious violation of my put stylesheets at the top rule from High Performance Web Sites. The reasoning behind this rule is that Internet Explorer won’t start rendering the page until all stylesheets are downloaded¹, and other browsers might produce the Flash Of Unstyled Content (FOUC). It’s best to put stylesheets at the top so they get downloaded as soon as possible.

His reason for putting these stylesheets at the bottom was that they were specified with media="print". Since these stylesheets weren’t going to be used to render the current page, he wanted to load them last so that other more important resources could get downloaded sooner. Going back to the reasons for the “put stylesheets at the top” rule, he wouldn’t have to worry about FOUC (the stylesheets wouldn’t be applied to the current page). But would he have to worry about IE blocking the page from rendering? Time for a test page.

The media=print stylesheets test page contains one stylesheet at the bottom with media="print". This stylesheet is configured to take 4 seconds to download. If you view this page in Internet Explorer you’ll see that rendering is indeed blocked for 4 seconds (tested on IE 6, 7, & 8).

I’m surprised browsers haven’t gotten to the point where they skip downloading stylesheets for a different media type than the current one. I’ve asked some web devs but no one can think of a good reason for doing this. In the meantime, even if you have stylesheets with media="print" you might want to follow the advice of Page Speed and YSlow and put them in the document HEAD. Or you could try loading them dynamically. That’s the topic I’ll cover in my next blog post.

The five posts in this series are:

• 5a Missing schema double download
• 5b document.write scripts block in Firefox
• 5c media=print stylesheets
• 5d dynamic stylesheets
• 5e speculative background images

This is the second of five quick posts about some browser quirks that have come up in the last few weeks.

Scripts loaded using document.write block other downloads in Firefox.

Unfortunately, document.write was invented. That problem was made a bzillion times worse when ads decided to use document.write to insert scripts into the content publisher’s page. It’s one line of code:

Fortunately, most of today’s newer browsers load scripts in parallel including scripts added via document.write. But a few weeks ago I noticed that Firefox 3.6 had some weird blocking behavior in a page with ads, and tracked it down to a script added using document.write.

The document.write scripts test page demonstrates the problem. It has four scripts. The first and second are inserted using document.write. The third and fourth are loaded the normal way (via HTML using SCRIPT SRC). All four scripts are configured to take 4 seconds to download. In IE8, Chrome 4, Safari 4, and Opera 10.10, the total page load time is ~4 seconds. All the scripts, even the ones inserted using document.write, are loaded in parallel. In Firefox, the total page load time is 12 seconds (tested on 2.0, 3.0, and 3.6). The first document.write script loads from 1-4 seconds, the second document.write scripts loads from 5-8 seconds, and the final two normal scripts are loaded in parallel from 9-12 seconds.

The issues with document.write are getting more well known. Some 3rd party code snippets (including Google Analytics) are switching away from document.write. But most 3rd party snippets still use document.write to insert their code into the publisher’s page. Here’s one more reason to avoid document.write.

The five posts in this series are:

• 5a Missing schema double download
• 5b document.write scripts block in Firefox
• 5c media=print stylesheets
• 5d dynamic stylesheets
• 5e speculative background images

This is the first of five quick posts about some browser quirks that have come up in the last few weeks.

Internet Explorer 7 & 8 will download stylesheets twice if the http(s) protocol is missing.

If you have an HTTPS page that loads resources with “http://” in the URL, IE halts the download and displays an error dialog. This is called mixed content and should be avoided. How should developers code their URLs to avoid this problem? You could do it on the backend in your HTML template language. But a practice that is getting wider adoption is protocol relative URLs.

A protocol relative URL doesn’t contain a protocol. For example,

becomes

Browsers substitute the protocol of the page itself for the resource’s missing protocol. Problem solved! In fact, today’s HttpWatch Blog posted about this: Using Protocol Relative URLs to Switch between HTTP and HTTPS.

However, if you try this in Internet Explorer 7 and 8 you’ll see that stylesheets specified with a protocol relative URL are downloaded twice. Hard to believe, but true. My officemate, Steve Lamm, discovered this when looking at the new Nexus One Phone page. That page fetches a stylesheet like this:

Notice there’s no protocol. If you load this page in Internet Explorer 7 and 8 the waterfall chart (nicely generated by HttpWatch) looks like this:

Notice 2496921881-SiteCss.css is downloaded twice, and each time it’s a 200 response, so it’s not being read from cache.

It turns out this only happens with stylesheets. The Missing schema, double download test page I created contains a stylesheet, an image, and a script that all have protocol relative URLs pointing to 1.cuzillion.com. The stylesheet is downloaded twice, but the image and script are only downloaded once. I added another stylesheet from 2.cuzillion.com that has a full URL (i.e., it starts with “http:”). This stylesheet is only downloaded once.

Developers should avoid using protocol relative URLs for stylesheets if they want their pages to be as fast as possible in Internet Explorer 7 & 8.

The five posts in this series are:

• 5a Missing schema double download
• 5b document.write scripts block in Firefox
• 5c media=print stylesheets
• 5d dynamic stylesheets
• 5e speculative background images

How are browsers doing when it comes to parallel script loading?

Back in the days of IE7 and Firefox 2.0, no browser loaded scripts in parallel with other resources. Instead, these older browsers would block all subsequent resource requests until the script was received, parsed, and executed. Here’s how the HTTP requests look when this blocking occurs in older browsers:

The test page that generated this waterfall chart has six HTTP requests:

1. the HTML document
2. the 1st script – 2 seconds to download, 2 seconds to execute
3. the 2nd script – 2 seconds to download, 2 seconds to execute
4. an image – 1 second to download
5. a stylesheet- 1 second to download
6. an iframe – 1 second to download

The figure above shows how the scripts block each other and block the image, stylesheet, and iframe, as well. The image, stylesheet, and iframe download in parallel with each other, but not until the scripts are finished downloading sequentially.

The likely reason scripts were downloaded sequentially in older browsers was to preserve execution order. This is critical when code in the 2nd script depends on symbols defined in the 1st script. Preserving execution order avoids undefined symbol errors. But the missed opportunity is obvious – while the browser is downloading the first script and guaranteeing to execute it first, it could be downloading the other four resources in parallel.

Thankfully, newer browsers now load scripts in parallel!

This is a big win for today’s web apps that often contain 100K+ of JavaScript split across multiple files. Loading the same test page in IE8, Firefox 3.6, Chrome 4, and Safari 4 produces an HTTP waterfall chart like this:

Things look a lot better, but not as good as they should be. In this case, IE8 loads the two scripts and stylesheet in parallel, but the image and iframe are blocked. All of the newer browsers have similar limitations with regard to the extent to which they load scripts in parallel with other types of resources. This table from Browserscope shows where we are and the progress made to get to this point. The recently added “Compare” button added to Browserscope made it easy to generate this historical view.

While downloading scripts, IE8 still blocks on images and iframes. Chrome 4, Firefox 3.6, and Safari 4 block on iframes. Opera 10.10 blocks on all resource types. I’m confident parallel script loading will continue to improve based on the great progress made in the last batch of browsers. Let’s keep our eyes on the next browsers to see if things improve even more.

Page Speed 1.6 Beta was released today. There are a few big changes, but the most important fix is compatibility with Firefox 3.6. If you’re running the latest version of Firefox visit the download page to get Page Speed 1.6. Phew!

I wanted to highlight some of the new features mentioned in the 1.6 release notes: new rules and native library.

Three new rules were added as part of Page Speed 1.6:

• Specify a character set early – If you don’t specify a character set for your web pages or specify it too low in the page, the browser could parse it incorrectly. You can specify a character set using the META tag or in the Content-Type response header. Returning charset in the Content-Type header will ensure the browser sees it early. (See this Zoompf post for more information.)
• Minify HTML – Top performing web sites are already on top of this, right? Analyzing the Alexa U.S. top 10 shows an average savings of 8% if they minified their HTML. You can easily check your site with this new rule, and even save the optimized version.
• Minimize Request Size – Okay, this is cool and shows how Google tries to squeeze out every last drop of performance. This rule sees if the total size of the request headers exceed one packet (~1500 bytes). Requiring a roundtrip just to submit the request hurts performance, especially for users with high latency.

The other big feature I wanted to highlight first came out in Page Speed 1.5 but didn’t get much attention – the Page Speed C++ Native Library. It probably didn’t get much attention because it’s one of those changes that, if done correctly, no one notices. The work behind the native library involves porting the rules from JavaScript to C++. Why bother? Here’s what the release notes say:

This should speed up scoring, as well as allow rules to be run in programs other than just the Page Speed Firefox extension.

Making Page Speed run faster is great, but the idea of implementing the performance logic in a C++ library so the rules can be run in other programs is very cool. And where have we seen this recently? In the Site Performance section recently added to Webmaster Tools. Now we have a server-side tool that produces the same recommendations found from running the Page Speed add-on. Here are the rules that have been ported to the native library:

Webmaster Tools Site Performance today shows recommendations based on the rules in native library 1.5. Now that more rules have been added to native library 1.6, webmasters can expect to see those recommendations in the near future. But this integration shouldn’t stop with Webmaster Tools. I’d love to see other tools and services integrate native library. If you’re interested in using native library, check out the page-speed project on Google Code and contact the page-speed-discuss Google Group.

The Zen Wall

We moved into a teardown 2BR/1BA house in 1993. After two years of infrastructure repairs (heating, plumbing, electrical, doors, windows) we started work on the yard. One of the jobs that I enjoyed most was building a dry stone retaining wall in the front yard. Here are the before and after pictures:

before

after

During this multi-month project my neighbor, Les Kaye, came by to survey the progress. Les is the Zen monk at the Kannon Do Zen Meditation Center and author of Zen at Work. He made a comment about my rock wall that I’ve always remembered – “very Zen-like”.

I’m not a Zen student, but I have read a few Zen books (Les’ Zen at Work, Tao Te Ching by Lao Tsu, the Tao of Leadership by John Heider, and Zen and the Art of Motorcycle Maintenance by Robert Pirsig). I think Les’ comment had to do with the way I was building the wall. I wasn’t using any tools, and didn’t have any drawings or plans. I had never built a dry stone wall before. I read a few articles on dry stone construction, got advice from the folks where I bought the stone, and then just started.

I had a sense of where the wall should go in the yard, and where the steps should go in the wall. I laid the base, and then worked up from there. I would try a few stones for a given spot until I found the right one. I could recognize if a stone worked, and if it didn’t. Sometimes I’d have to backtrack a bit to undo some bad stones and start over where the good stones left off. In the end, the wall turned out great. It’s now covered with moss, overhung by rosemary, and filled with lizards that come out to sunbathe in the summer.

Les’ comment that my rock wall project was Zen-like had to do with this marriage of an artistic sense of what was right with the technical process of building a wall. The separation of art and technology, and the need to rejoin them, is a major theme in Zen and the Art of Motorcycle Maintenance that’s been on my mind lately.

Art & Technology

The way I approached this rock wall project seems a bit ill-conceived. You certainly wouldn’t run a software development project this way. A well-planned project would make use of good tools. It would have a detailed plan. It would include people that had experience, at least in a consulting role. And it would have regular milestones that could be objectively measured and quantified. But these (technical, mechanical, objective) process parts aren’t sufficient to ensure success. A sense of craftsmanship is also needed.

I’ve had the experience where I’ve hired a home contractor who had all the right tools and experience, and was equipped with an agreed upon plan, but at the end of the job I wasn’t satisfied with the outcome. The end result didn’t fit. It was out of proportion – something we couldn’t have noticed looking at the plans. Or it didn’t fit the flow of the people living in the house – the light switches were placed in an awkward location in a counter intuitive order, or the door swung out too far and blocked traffic.

I’m not saying you shouldn’t have plans and tools, and metrics and experts. And I’m certainly not running down home contractors – many great contractors have worked on our house. I’m saying that the high quality results I’ve experienced resulted when technical skills were combined with a sense of what was “right” in the work. Robert Pirsig says it this way in describing a wall built in Korea:

[The wall] was beautiful, but not because of any masterful intellectual planning or any scientific supervision of the job, or any added expenditures to “stylize” it. It was beautiful because the people who worked on it had a way of looking at things that made them do it right unselfconsciously. They didn’t separate themselves from the work in such a way as to do it wrong. [...] In each case there’s a beautiful way of doing it and an ugly way of doing it, and in arriving at the high-quality, beautiful way of doing it, both an ability to see what “looks good” and an ability to understand the underlying methods to arrive at that “good” are needed.1

Beautiful Web Performance

My work on web performance has helped identify the “underlying methods” for arriving at a quality result in terms of a fast web site. To make it easy to find out which methods to use, I created YSlow and encouraged the team that launched Page Speed. But these tools don’t preclude the need to understand the techniques behind web performance. I was reminded of this today by an email I received through my web site. The emailer said he had installed YSlow and saw what needed to be fixed, and asked for the step-by-step instructions on how to accomplish these changes.

Without any details of his web site, HTML & JavaScript frameworks, etc. it was impossible to generate step-by-step instructions. But even if it was possible, if he had followed someone else’s list of instructions he would be separated from the work and miss the experience of the “beautiful way of doing it”. Optimizing a web site isn’t something that can be undertaken without understanding what you’re changing and why. Doing so inevitably introduces complexity, confusion, and loss of quality. It would be better for him to develop that understanding, or if that’s not possible to use a framework that incorporates performance best practices.

In addition to an understanding of the underlying methods, the ability to see what “looks good” is also needed, as Pirsig says. When it comes to web performance, it’s pretty easy to distinguish the good from the bad. How does your site feel when you use it? How about when you use it from home or from a mobile device? WebPagetest.org helps by offering multiple ways to visualize the performance of your web site, and to compare that to other sites.

Over time, combining an understanding of the underlying methods for web performance with an ability to see what “looks good” leads to doing quality development “unselfconsciously”. It becomes second nature, and permeates every site you build. As I read Zen and the Art of Motorcycle Maintenance I was amazed at how well it spoke to the work I do, even more amazing given that it was published in 1974. The search for Quality is timeless. I recommend you read ZMM, or read it again as the case may be. Raising the level of quality in your work will benefit your users and your employer, but it’ll benefit you most of all.

¹Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance An Inquiry Into Values (P.S.) (New York, Harper Perennial Modern Classics, 2005) p. 298.

JQuery 1.4 was released yesterday. I lifted the text from the release announcement, removed stop words, converted to lowercase, and found the ten most used words:

1. jquery (71)
2. function (27)
3. performance (23)
4. object (20)
5. events (19)
6. element (15)
7. ajax (15)
8. dom (13)
9. json (12)
10. request (10)

That’s right, “performance” comes in third ahead of “object”, “element”, and even “dom”. Anyone think jQuery 1.4 had a focus on performance? Here’s what John Resig says.

Performance Overhaul of Popular Methods

Many of the most popular and commonly used jQuery methods have seen a significant rewrite in jQuery 1.4. When analyzing the code base we found that we were able to make some significant performance gains by comparing jQuery against itself: Seeing how many internal function calls were being made and to work to reduce the complexity of the code base.

He includes this chart that shows the reduction of complexity for some popular functions.

Of course, all of this is music to my ears. There was one other specific note that caught my eye in this commit comment:

Switched from using YUI Compressor to Google Compiler. Minified and Gzipped filesize reduced to 22,839 bytes from 26,169 bytes (13% decrease in filesize).

Minifying JavaScript is one of the rules I wrote about in High Performance Web Sites. Back then (2006-2007), the best tool for minifying was JSMin from Doug Crockford. It still might be the best tool today for minifying in realtime (e.g., dynamic Ajax and JSON responses). For minifying static files, YUI Compressor (released in late 2007) does a better job. It also works on CSS. So this move from YUI Compressor to the Google Closure Compiler by John Resig, someone who obviously cares about performance, is a big deal.

For jQuery 1.4, the savings from switching to Compiler was 13%. If you have done comparisons with your code, please add your stats via a comment below.

My last blog post (Stuck inside Classic Rock) got pretty esoteric at the end when I started talking about Quality, and I promised a follow-up post on how that related to web performance. I’m still working on that post, but am happy to take this digression. But is it a digression? I’ve been talking to folks over the past week about how they strive for and compromise on quality in their jobs. We all compromise on quality to a certain degree. But occasionally, a person is afforded the opportunity to dedicate a significant portion of their life to a single-minded purpose, and can reach levels of Quality that standout in comparison. John Resig has achieved that. Congratulations to John and the jQuery team. Keep up the good (high performance) work!

Help! I’m trapped inside Classic Rock and can’t get out!

I grew up in the 60s and 70s listening to what is now called “classic rock”. My first album was Creedence Clearwater Revival’s Cosmo’s Factory. Ramble Tamble is still one of my favorite rock songs. I bought that album when I was 10 years old. I wish I was that cool but I was (am) not – my next album was The Partridge Family Album.

Through my teenage and college years I listened to the bands that make up every classic rock playlist: Allman Brothers, Grateful Dead, Rolling Stones, The Who, Steve Miller, Lynyrd Skynyrd, Bruce Springsteen, Led Zeppelin, Tom Petty, etc. I don’t listen to Partridge Family any more, but I listen to these other bands every day. My iTunes library is full of this music. My default station on both Pandora and Slacker is “Classic Rock”. And my main radio station is KFOG, home of “world class rock”.

Even though I love classic rock, I do like to mix in some new music now and then. New music that’s cut from the same mold, that is. Some new bands I’ve added over the years include Counting Crows, U2, and Red Hot Chili Peppers. That shows how old I am. I think of U2 as “new” – a band that’s been together for 30 years. I desperately needed some truly new music, so I grabbed the copy of Rolling Stone featuring the decade’s best songs & albums and went searching.

I found some great new (10 years old or less) music, and wanted to share what I found. What’s this have to do with web performance? I’ll get to that at the end. If you don’t want to wade through my music recommendations, skip to the bottom and find out what the connection is.

“New” Classic Rock

Here are singles I added via iTunes:

• Wake Up by Arcade Fire – Theme song from the Where the Wild Things Are movie. You should listen to this song first thing every morning when you get up.
• Take Me Out and No You Girls by Franz Ferdinand – Great lyrics to a good euro beat. Maybe danceable, but also capable of generating some headbanging.
• Hurt by Johnny Cash – Johnny Cash covers Nine Inch Nails?! I had to listen to this and was hooked. With lyrics like “what have I become” and “empire of dirt” it makes you think.
• One More Time by Daft Punk – Electro-disco dance mix. Play this in the car when the sun’s out and the windows are down, or the next time a dance party breaks out in your living room (whichever comes first).
• Paper Planes by M.I.A. – I’m not huge on hip-hop, so I fell short of buying the album. But this catchy song featured in Slumdog Millionaire is a great addition to the playlist. My daughters and wife liked it – bonus points!
• Float On by Modest Mouse – Singer Isaac Brock sounds like David Byrne in this song that mixes driving choruses with melodic lyrics.
• Last Nite by The Strokes – A rocking song that’ll get you moving.

I buy my CDs on Amazon. Just this week a buddy predicted the music industry would soon stop making CDs. I hope not. I have so much music it’s overwhelming. I like holding a collection of songs in my hand, taking it with me in the car or on a trip, looking at the cover art, and reading the liner notes. All of this helps me better capture a mental picture of the music. I also believe artists arrange songs together and in a particular order to achieve additional impact. True or not, I like physical CDs. Here’s what I bought:

• Fleet Foxes by Fleet Foxes – This was an easy, almost backward, transition from classic rock to new music. These guys sound like CSNY – harmonies and easy lyrics. Good listening.
• Funeral by Arcade Fire – I bought the single of Wake Up on iTunes and then got it again when I bought the CD – not smart. But it was worth the extra $0.69 to have that one song for the few days it took for the album to arrive.
• A Rush of Blood to the Head by Coldplay – Coldplay churns out hits, which is a turnoff for me. This album has hits, or at least songs you’ll recognize, like In My Place, The Scientist, and Clocks. But the lesser known songs on this album are what’s intriguing – Politik, God Put a Smile upon Your Face, Green Eyes – let’s face it, all the songs on this album are good or great.
• Yoshimi Battles the Pink Robots by The Flaming Lips – Wow. Incredible and hard to describe. It feels like someone used a Pink Floyd machine to translate a comic book to music. I listened to Flight Test and Yoshimi Battles the Pink Robots, Pt. 1 multiple times each day when I first got this. You can hear the influences from Cat Stevens (Flight Test) and Neil Young (In the Morning of the Magicians).
• Only by the Night by Kings of Leon – You’ll recognize the track Use Somebody. I like the singer’s voice – it reminds me of Bob Seeger.
• Z by My Morning Jacket – Southern rock meets Hothouse Flowers, with some early Who influence.

What’s the Connection?

It has been a few weeks since my last blog post. I’m having a hard time getting going again after the long holiday break. This blog post on classic rock was an easy first step back into the world of blogging.

But there’s more to it than that.

I’m slow getting back into blogging because I’m having trouble imagining putting down words that have value. Over the break I read Zen and the Art of Motorcycle Maintenance by Robert Pirsig (for the third time). My mind is still swimming from the visions and thoughts stirred up by that book. Having experienced what an author is capable of with words, how can I attempt to do anything even remotely similar? I am not worthy!

It gets worse, or at least more complicated.

As I drive around listening to my “new” classic rock, I get the same overwhelming, swimming feeling. Many of these songs move me. They’re beautiful. Even the headbanging songs are beautiful. They’re beautiful in the way the artist has reached through the car stereo speakers and changed the way I feel. They’re beautiful in the way they connect and convey. Just like ZMM is beautiful and connects and conveys. And I stop and ask myself – Is my blog beautiful? Really what I mean is, can my blog connect and convey?

I’ve spent a lot of time over the last year thinking about and observing how we connect with each other through writing, music, art, movies, personal interactions, and the Web. I’ve been thinking about what makes those connections more successful, more enjoyable, and ultimately more moving. For my world I’ve been concerned with what makes a blog post, tech presentation, book, or piece of code more beautiful. It came down to asking and defining – What is Beauty? And that’s when I hit a brick wall. I couldn’t define it. I know it when I see it. I can experience it. But I can’t define it. How can I improve something I can’t define?

As I read ZMM, I realized this was similar to Phaedrus’ struggle to define Quality. And the connection Phaedrus found between Quality and what the Greeks called aretê, or Excellence, is similarly connected to what I have been calling Beauty, and is probably a better name for what I’ve been searching to improve. Quality, Excellence, and Beauty – they’re all the same, or at least closely related.

Quality, excellence, and beauty are, or at least should be, in our work. And that’s the connection. This music is excellent and beautiful, and I want to find that quality in the world of web performance, and find a way to express it and communicate it, and have all of us carry it with us as we do our work. As I read ZMM, I saw many similarities between web performance and motorcycle maintenance. I feel like there’s at least one more blog post on the topic, if not an entire book. Hmmm, Zen and the Art of Web Performance. I like it. But let’s see how the blog post goes first. Stay tuned…

This is a fun story that has a security and performance point to it.

Earlier today, Dion Almaer tweeted:

Wow, Doug added an alert() to http://www.json.org/json2.js which just alerted a LOT of people on the Internet. Proving a point on hotlinks?

I was talking to Doug about his keynote at Add-on-Con tomorrow, and asked him what the motivation was for this alert message. It turns out his webhosting service had contacted him about the unusually high amount of traffic on json.org. Doug investigated and discovered that OnlineBootyCall was linking directly to http://json.org/json.js, in spite of this statement in the file:

USE YOUR OWN COPY. IT IS EXTREMELY UNWISE TO LOAD CODE FROM SERVERS YOU DO NOT CONTROL.

Linking directly to http://json.org/json.js is bad. Certainly, it puts a load on Doug’s webhosting company that shouldn’t be there. But more importantly, it exposes the content site to security and performance vulnerabilities. Loading third party scripts into the parent window gives that third party access to cookies and other potentially confidential information in the page. Accessing that script from a third party domain requires an additional DNS lookup (which can be costly). Also, if the script is at the top of the page (which it is in this case) and the third party site is slow or not responding, the entire page is left blank for thirty seconds or more.

It’s best to reduce the number of third party scripts on your site. That was the reason Doug added the alert message to the top of json.js. If you haven’t gone to OnlineBootyCall yet today, here’s what you would’ve seen:

In Doug’s words,

I’m helping onlinebootycall improve its performance.