Ravelrumba

Data URIs and Dynamic Stylesheets

Rob Flaherty — Thu, 17 Jun 2010 02:55:14 +0000

This a quick follow-up to a post I wrote a few months ago about embedding data URIs in stylesheets and a potential performance hazard regarding the way non data URI images are positioned in the network waterfall. What I found was that under certain circumstances the performance penalty was great enough to not only negate the benefits of using data URIs for images, but to actually increase the overall load time.

My solution was a hack: put the data URI images in a separate stylesheet and place the link to the stylesheet at the bottom of the page, after a script reference. This caused the browser to render the page after the main stylesheet (the one without the data URI images) and download the data URI stylesheet and other images in parallel. The result was a fast loading, progressively rendered page. But, in addition to producing invalid HTML, it went against the widely accepted best practice of keeping stylesheet references within the head.

Despite some great discussion in the comments, there didn’t seem to be a decent answer to the problem. I forgot about it for a couple of months and then the other day the very obvious and simple solution came to me.

A quick recap of the original obstacle

When you replace the background image references in your stylesheet with data URIs, the size of your stylesheet increases significantly as the image bits are moved from image files into the stylesheet. (After gzipping, the increase in stylesheet size equals the original size of the images.) The page weight is the same but the difference is that stylesheets block rendering and downloading of images referenced in stylesheets. This means the more data URI images you have in your stylesheet, the bigger your stylesheet, the longer it takes before the page is rendered, and the longer it takes before other non-data URI CSS images can be downloaded. For an example, see how page components 4 and 5 are blocked in the above image.

You might be wondering why we would have both data URI CSS images and regular CSS images. The reason is that IE8 only supports data URIs smaller than 32KB. So if you have an image 32KB+ you’ll need to serve it normally if you want your site to get along with IE8.

My previous hack/solution

One way I found to get around the problem was to move the data URI images into their own stylesheet (yes, adding an additional HTTP request) and force the browser to load the stylesheet asynchronously by placing the data URI stylesheet link in the body, after an external script reference. As you can see in the waterfall, the data URI images and the regular images are now downloaded in parallel.

A better way

Of course there’s a better way to achieve the same end. All we need to do to get the parallel downloading we want is make the dataURI stylesheet load asynchronously, something we can easily do with Javascript. Obviously the dataURI images will now be dependent on Javascript being enabled, so you’ll have to take that into consideration.


<html>
<head>
    <meta charset="utf-8" />
    <title>Title</title>
    <link href="style.css" rel="stylesheet" media="all" />
    <script>
        var datuURIs = document.createElement("link");
        document.head = document.head || document.getElementsByTagName('head')[0];
	datuURIs.href = "duri-images.css";
	datuURIs.rel = "stylesheet";
	document.head.appendChild(datuURIs);
    </script>
</head>

Whether the dynamically inserted stylesheet occurs before or after the main stylesheet does not seem to matter in most browsers, but it does in IE8. In IE8 the dynamic stylesheet will block if it comes before the regular stylesheet. So if you’re using this technique you’ll want to order the elements as I have above.

On the general subject of using embedded data URIs for images, is it worth fussing with all this stuff? In most cases I think the answer is probably not (yet, at least), in part because you can achieve a similar performance result with an aggressive use of CSS sprites. Although CSS sprites have their own overheard and drawbacks, overall I think they’re easier to work with, especially when you start having to worry about data URI workarounds for IE6 and IE7.

But there are certainly situations where data URIs might be a good fit. Mobile applications and “HTML5 apps” aimed at non-IE browsers come to mind. And if nothing else, they’re fun to play with.

HTML5 Slideshow

Rob Flaherty — Wed, 02 Jun 2010 00:39:12 +0000

Maybe it’s because I have weak PowerPoint computer hacking skills, but whenever I work on a presentation I find myself thinking, “Shouldn’t this be easier?” or “I’d rather be doing this with CSS.” So last week when I ran into my usual PowerPoint frustration I decided to devote a little time to correct the problem by writing a simple HTML/CSS/Javascript slideshow app.

You might ask, “Aren’t there already some browser-based presentation tools out there?” Yes! There’s HTML Slidy and Eric Meyer’s S5. There’s also Swinger. And surely others. Why didn’t I use one of those? The truth is that I wasn’t aware of them. Writing an HTML slideshow tool is not very difficult (at least in the minimalist fashion that I’ve conceived it) and I had finished building it before I bothered to see if others existed.

If you want lots of configuration options, both S5 and HTML Slidy look great. And as a hosted option Swinger looks awesome. But if you just want a lightweight tool you can use to display HTML slides in your favorite browser, I think this little thing works well.

What it does

What I wanted was a way to write slides using HTML and CSS, and to be able to display the slides locally on my Mac in Chrome or Firefox, both of which support full-screen viewing. Since I didn’t have to worry about lesser browsers it was an easy opportunity to break out the HTML5 (although making it play nice in other browsers is first on my to-do list).

The features are better explained in the demo, but here’s a quick run-down:

Each slide exists as a section element inside an HTML document.
Javascript wrangles up the section elements and turns them into ordered slides.
jQuery is used for a few things, including firing events when new slides are loaded.
You can do some simple intra-slide fade-in stuff by giving things a class of “action”.
You can advance through the presentation with either your mouse or the keyboard.

Props

Edward O’Connor wrote an interesting post about marking up a slideshow in HTML5. For the structure of the HTML I followed most of his ideas.

That’s all! As always, feedback is greatly appreciated.

View the demo
Download from github

IE 8 Charset Bug

Rob Flaherty — Fri, 14 May 2010 21:12:38 +0000

Earlier today I was playing around with a performance test case when I noticed that stylesheets and scripts were being requested twice in IE8.

Eventually I figured out that the problem had to do with how the character set was specified. This is how things seem to work: In IE8, pages that rely on the META tag to define the character set — that is, pages that do NOT use the HTTP Content-type header to specify the character set — will request some stylesheets and scripts twice. Pages that indicate a character set via the HTTP Content-type header behave properly.

Test Page Using META Tag

On this page the character set is specified using only the META tag. The stylesheet and Javascript requests are sent twice. Notice that the initial requests do not receive a response.

View test page

Test Page Using Content-type HTTP Header

On this page the character set is specified with the Content-type HTTP header. The stylesheet and Javascript are requested only once.


header('Content-type: text/html; charset=utf-8');
?>

View test page

Other Test Pages

Interestingly, if you do not specify the character set at all, IE8 does not request the stylesheet and script twice. View test page.

If you use both the META tag and the Content-type HTTP header, the header will override the META tag and IE8 will only request the resources once. View test page.

Is it really a bug?

I was surprised to see that Googling this quirk did not turn up any results. My first thought was that the HTTP proxy was reporting false connections. But I was able to replicate the problem on HttpWatch, Charles, and WebPagetest.org. Additionally, inspecting the server logs revealed the extra requests for the stylesheets (but curiously not the Javascript).

Then I thought it might have something to do with my webhost’s nginx and Apache configurations. But I tested some other sites at random and found the same problem with pages that did not specify the charset via HTTP header (two such pages: John Resig’s blog and css3please.com).

Billy Hoffman has a great post about charset and performance issues, in which he mentions that Firefox will re-request a URL if it detects a new charset after the initial URL request. That sounds like a very possible explanation for what is going on here: the initial stylesheet and script requests are sent, THEN the browser parses the META tag, forcing the stylesheet and script to be re-requested. But this seems odd considering the META tag occurs in the document before the stylesheet and script references.

Specifying the character set server-side instead of with the META tag is already considered a best practice, but if this IE8 behavior is accurate, the penalty for not adhering to the best practice is significant.

Update (5/16/2010)

In the comments Dave posted a link to this post by Eric Lawrence, which explains the bug and announces that it was (mostly) fixed in a 3/30/10 update. The post is worth reading, but I wanted to highlight the part where Eric recommends using the Content-type header to specify the character set:

However, the Update kills the bug in Scenario #1 by disabling the Lookahead Downloader when a restart is encountered. Hence, we continue to strongly recommend that web developers specify the CHARSET in the HTTP Content-Type response header, as this ensures that the performance benefit of the Lookahead Downloader is realized.

iPad View Source Bookmarklet

Rob Flaherty — Mon, 26 Apr 2010 14:01:06 +0000

For a few years I’ve been using this little bookmarklet, written by Abe Fettig, on my iPhone to view page source in Mobile Safari. It works well, but unfortunately the output is not optimized for viewing on the iPhone. Because I use the bookmarklet so infrequently, it’s never really bothered me.

Then I installed the same bookmarklet on my iPad. I found myself using the iPad to browse the web more often, and more often wanting to click view source. Quickly the poor screen formatting became enough of a nuisance to motivate me to spend a few lines of code fixing it.

Here’s an example of the source produced by Abe Fettig’s original bookmarklet (on the iPad):

Original View Source

It takes a lot of zoom pinching to get the text to a legible level. Here’s an example of what the improved version displays:

New and Improved

Much better. To do it I made two small additions (and a few tweaks) to the original. One, I added a viewport meta tag, setting the width to device-width. And two, I added overflow:auto and white-space: pre-wrap styles to the pre element wrapping the displayed source code. Behold:

Improved Bookmarklet Code

javascript:(function(){
    var w = window.open('about:blank'), 
        s = w.document;
    s.write('Source of '</span> <span style="color: #339933;">+</span> location.<span style="color: #660066;">href</span> <span style="color: #339933;">+</span> <span style="color: #3366CC;">'');
    s.close();
 
    var pre = s.body.appendChild(s.createElement("pre"));
    pre.style.overflow = 'auto';
    pre.style.whiteSpace = 'pre-wrap';
    pre.appendChild(s.createTextNode(document.documentElement.innerHTML));
})();

If you already know how to install a bookmarklet in Mobile Safari, here’s the raw code. Have fun.

For the rest of you, who might be thinking, “how do I get this teh hotness onto my business?”, worry not. We’ve got you covered. It’s like this…

How to Install a Bookmarklet on Mobile Safari

Navigate to this page on your iPad and select “Add Bookmark”. Change the name of the bookmark to “View Source” or whatever you like. Tap “Save”.

Next, copy the bookmarklet from here. (Select All > Copy.)

Lastly, go to your bookmarks, tap “Edit”, select the bookmark you just created, and replace the URL by pasting in the new code. Tap “Done” and you’re done.

A few things:

The source you’ll see is the DOM source (“generated source”), not the original HTML source.
The ends of some very long strings are partly hidden from view.
It works well on the iPad but on the iPhone the text wrapping does not work as well (the ends of more lines are cut off).
It should work in any browser that supports the white-space value pre-wrap. But I’ve only tested on iPad, iPhone, and Opera Mini on the iPhone.
For some reason the source code output is not fully selectable. You can Select All but you cannot define segments to select.

If anyone knows of a better solution, or has any recommendations to improve this one, please let me know. You can also fork the gist on github.

iPad HTTP Debugging with Charles

Rob Flaherty — Tue, 13 Apr 2010 21:09:47 +0000

After noticing that the caching in iPad Safari seemed a little funky, I made an effort to decipher some of the logic used by the browser cache. I didn’t get very far, but in the process I figured out how to route my iPad HTTP traffic through a web debugger on my laptop. It turns out it was very easy to do (although I’m sure there is a more complicated way to go about it).

What follows is a simple step-by-step for connecting your iPad to an HTTP debugging proxy. The main requirement is that your desktop/laptop and iPad be on the same wireless network. Then it’s just a matter of telling your iPad to use your desktop as an HTTP proxy.

I’m going to walk through how to do this on a Mac with the highly recommended HTTP proxy app Charles, but the same basic steps should also work for a Windows HTTP debugger such as Fiddler. (Update: Fiddler users, see Eric Lawrence’s comment below.) Additionally, the steps are the same for connecting your iPhone or iPod Touch.

1. Get your system IP address for your desktop

The easiest way to do this on a Mac is to Spotlight your way to the “Network Utility” app. Make sure you’re on your Wi-Fi network and take note of the IP address. This is your desktop’s local IP.

2. Tell your iPad about your desktop IP

On your iPad, go to Settings > Wi-Fi and click the arrow next your Wi-Fi connection. Under “HTTP Proxy”, select the Manual button and enter your desktop’s IP address in the Server field. Then enter “8888″ in the Port field. Close out.

3. Configure Charles

Open Charles and select Proxy > Proxy Settings. Under the Proxies tab, make sure the HTTP proxy value is set to 8888. Then click the “Mac OS X” tab and check “Enable Mac OS X Proxy” and “Use HTTP Proxy”. Click OK.

4. Start capturing HTTP traffic

Click the Record button in Charles and then load a web page in iPad Safari. You should see the following alert asking you if you want to allow your iPad to connect to Charles. Select “Allow”.

Now all of your HTTP traffic in iPad Safari should be recorded by Charles.

When you’re finished doing all of your fun HTTP debugging, don’t forget to turn off the HTTP proxy in the Wi-Fi settings of your iPad.