Sunday, February 14th, 2010

Souders blasts off 5 in a row

Category: Performance

Steve Souders has done a weekly set of posts on browser quirks that have caught his eye. Here’s the roundup:

Missing schema double download

Internet Explorer 7 & 8 will download stylesheets twice if the http(s) protocol is missing. Interestingly, I rarely see anyone use “//×110.jpg” but here is a case to watch out for it.

document.write scripts block in Firefox

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:


  1. document.write('<script src="">< \/script>');

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.

media=print stylesheets

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

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.

dynamic stylesheets

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:


  1. var link = document.createElement('link');
  2. link.rel = 'stylesheet';
  3. link.type = 'text/css';
  4. link.href = '/main.css';
  5. 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 downloaded1, and other browsers might experience a Flash Of Unstyled Content (FOUC).

Speculative background images

Chrome and Safari start downloading background images before all styles are available. If a background image style gets overwritten this may cause wasteful downloads.

When my office-mate, Steve Lamm, pointed out this behavior to me, my first reaction was “that’s wasteful!” I love prefetching, but I’m not a big fan of most prefetching implementations because they’re too aggressive – they err too far on the side of downloading resources that never get used. After my initial reaction, I thought about this some more. How frequently would this speculative background image downloading be wasteful? I went on a search and couldn’t find any popular web site that overwrote the background-image style. Not one. I’m not saying pages like this don’t exist, I’m just saying it’s very atypical.

On the other hand, this speculative downloading of background images can really help performance and the user’s perception of page speed.

Posted by Dion Almaer at 10:32 am

4.5 rating from 33 votes


Comments feed TrackBack URI

Blocking continues even when using setTimeout. Take a look at an example that demonstrates the problem
(please open in FF and then in IE, and looking for difference)

if you have any problem for determination blocking in IE, look at screenshot

I’ve found so far the only solution that does not block IE, is to use js-css bridge

(function () (
var d = document, style = d.getElementsByTagName ( “head”) [0]. appendChild (d.createElement ( “style”));
style.type = “text/css”;
style.styleSheet.cssText = “/*your css*/ body {background: red}”;

Here is example of implementation

Comment by sirus — February 16, 2010

Don’t use document.write for anything ever. It does not play well with the DOM, scripts break, it’s just a complete and total mess.

Comment by jabcreations — February 27, 2010

Leave a comment

You must be logged in to post a comment.