Web performance and HTML5/CSS3

For many of us, HTML5 and CSS3 represent a huge leap forward. For years, we’ve been using a selection of hacks, tricks and plugins to get our websites to behave the way we want them to. Our demand for functionality has been running far ahead of standards.

Not any more. At least not to the same extent. HTML5 and CSS3 have made the life of many web developers immeasurably easier. We can now use a simple attribute or CSS declaration to achieve results that once required hundreds of lines of JavaScript.

But fewer sleepless nights for web developers are not the only benefit. The fact that browsers can now do so much more natively means that fewer bytes need to be transmitted between server and client. It also means fewer round-trips, as more websites can do without extra JavaScript files or images. In short, HTML5 and CSS3 should mean better performance.

Just how far have things improved?

We built two web pages. In terms of appearance and functionality, they’re pretty much the same – both are simple forms. Where they differ is in the code used to create them. One uses a combination of JavaScript and imagery (page A), while the other relies on HTML5 and CSS3 (page B).

The old way

Here’s the page as it might have been built pre-HTML5/CSS3. Note that this isn’t the only way it could have been done. It is not even the best way (more on this later). However, it is certainly representative.


Figure 1 – How a simple web form might have been built without HTML5 and CSS3


Figure 2 – A date picker created with jQuery UI


Figure 3 – A simple JavaScript function for email validation


Figure 4 – A text block animated with jQuery

The new way

Here are a few screen grabs of the page we built using HTML5 and CSS3 – page B.


Figure 5 – Page B: built with HTML5, CSS3 but no JavaScript and no images


Figure 6 – Setting the input type to “date” gives us a date picker


Figure 7 – Email validation without writing a JavaScript function


Figure 8 – Animation using the transition property

It’s worth dwelling on the text block animation for a moment. Here, we used CSS not only to expand and collapse the box on the click of a button, but also to change the colour and content of that button. We used a modified version of the Pure CSS3 Slide Down Toggle Demo, which you can find here: http://codepen.io/surjithctly/pen/pLDwe.

If we weren’t quite so concerned with styling, we could have used the <details> element instead.

Performance improvements

Does the new outperform the old? We tested both pages with Performance Analyser to find out.


Figure 9 – Page size and speed

The results were pretty definitive, with page B winning on every metric. It’s not hard to see why. Even from the simple graph in Figure 9, we can infer that page size has quite a bit to do with it.

A quick glance at the waterfall charts for each page tells us a little more:



Figure 10 – Waterfall charts for page A (top) and page B (bottom)

We needed just three objects (including the favicon) to build page B, compared to 11 for page A. JavaScript was the main limiting factor for the latter – just downloading jquery-ui.js took four times as long as it took page B to load completely.

An unfair test?

In some ways, this test is a little misleading. More could have been done to optimise page A. We downloaded a lot of redundant CSS, for example, and not all the CSS and JavaScript was minified. And while it’s also true to say that the CSS for page B wasn’t minified either, there was a lot less of it.

Still, we think page A is a fair representation of how such a form might be constructed. When deadlines are pressing, the priority is normally to get something working. If optimisation is considered at all, it all too often falls into the category of “something to look at when we’ve finished … if we get time”.

However, we decided to see what would happen if we did make some effort to get the page to load faster.

The first thing we did was cut out a lot of the redundant jQuery UI code, using the download builder (http://jqueryui.com/download/). We also used minified versions of the code, and concatenated the jQuery UI CSS with our own, minified, CSS file.

There are a couple of potential problems with doing all this. If we want to update the version of jQuery UI we’re using, we’ve made a bit more work for ourselves. Similarly, if we ever want to use other jQuery UI features, we’ll have to go back and rebuild the CSS and JS files. We’ve also made it harder to maintain our own CSS.

Nonetheless, these measures did result in some performance gains.

Let’s have a look at the waterfall chart for the improved page A:


Figure 11 – Waterfall chart for improved page A

Although it’s still nowhere near as fast as page B, we managed to cut both page size and load time by about 30%.

Still not as good as it could be

We used jQuery (and jQuery UI) because it’s quick, easy to use, and tried and tested. It’s also very widely used, so we thought this was a reasonable way to test the performance improvements that come with HTML5 and CSS3.

However, if we really wanted a high-performing page that avoided HTML5 and CSS3, we would probably opt for more customised solutions. In doing so, we could probably shave a few more bytes off our CSS and JS files.

What we couldn’t do, though, is avoid using JavaScript altogether. Nor could we avoid using images. Whatever we did, we would almost certainly end up with something larger than page B. And, unless we Base64 encoded all our images and inlined the JavaScript, it would also involve more round-trips.

What HTML5/CSS3 features did we use, and how widely supported are they?

Reading this so far, you might be forgiven for wondering why anyone is still using JavaScript for functionality that could now be achieved with HTML5 and CSS3.

Well, the obvious answer is that not all the features are universally supported. Everything used in this test worked in the latest version of Chrome (and our Performance Analyser tests were run using Chrome version 28). Other browsers might have struggled.

Here’s a summary of the features we used and the browsers that don’t support them (information from caniuse.com, correct at the time of writing – not all older browsers are included in this table).

Feature Not supported in
text-shadow property Internet Explorer 8 and 9
datalist element Internet Explorer 8 and 9
Opera Mini
iOS Safari
Android Browser
Internet Explorer Mobile
Blackberry Browser 7
input type=”date” Internet Explorer 8 and 9
Opera Mini
Internet Explorer Mobile
Android Browser 2.1–4.3
Blackberry Browser 7
input type=”email” Internet Explorer 8 and 9
iOS Safari
Opera Mini
Android Browser
Blackberry Browser 7
CSS gradients Internet Explorer 8 and 9
Opera Mini
border-radius property Internet Explorer 8
Opera Mini
transition property Internet Explorer 8 and 9
Opera Mini

As things stand, then, browser compatibility is still an issue, although there are ways around this, including the Modernizr library (http://modernizr.com/).

We can’t beat the speed of light, so let’s do the next best thing

Latency is the limiting factor that we can never completely avoid. No matter how much we optimise images, minify text files and refactor our CSS, there’s no getting away from the fact that, at some point, data will have to travel between the web server and the browser. And that data will never (as far as we know) be able to travel faster than the speed of light.

However, HTML5 and CSS3 help us to ensure that we don’t transfer more than we absolutely have to. Perhaps this is a sign that the web is growing up. We’re beginning to get an idea of the features and functionality that we’re going to want most often – things that browsers should be able to take care of out of the box.

We’ve already seen that this is an incredibly effective strategy from a performance point of view. How much further could it be taken? There has to be an argument for analysing data from a large number of sites to identify the most popular, performance-draining features and steering standards towards native browser support. For example, how many sites use social media feeds, buttons and widgets? And how many bytes of data are transferred unnecessarily just to load the same Facebook or Twitter icon from different sites?

The division between structure (HTML), style (CSS) and functionality (JavaScript) is one that’s been drilled into web developers for years (although some would argue that it’s been eroded by HTML5 and CSS3).

Perhaps it’s now time to pay more attention to the division between those jobs those could be done by the browser, and those that require something to be transferred from the web server. As things stand, there has to be so much more that could, in theory, be taken care of by the browser.

Leave a Reply

Your email address will not be published. Required fields are marked *