Jaap Haagmans The all-round IT guy


CSS and Javascript parsing time related to page speed

For a client, I've been implementing front-end caching in a couple of test scenarios. I managed to get the TTFB (Time To First Bit) down to under 100 milliseconds (and coming from 1.6s on average, that's a big win), but I still wasn't happy about the full loading time. We were using a self-built CDN for our CSS, Javascript and images, which meant that these were also loaded in a few milliseconds, but the time between loading the page and loading the last couple of images was still 1.5 seconds. So, what happened there? There was no cascading-effect for these images (they were all requested at the same time), but I saw the following behaviour in my Firebug Net window:


Now, this is something I haven't really seen before. Between the time the Javascript and CSS is delivered and the images are loaded lies about 1 second of nothingness. That can't be right, can it?

Of course, I'm exaggerating a little here. I have seen this before and I know exactly what it means, but the scale surprised me. What this means is that it takes my browser a full second to parse the CSS and Javascript. That means that, no matter how much I can actually speed up loading this website on the server side, the website will never fully load in under 1 second because of the way the website is built. Always having to deal with server side performance issues (which was quite straight-forward in this case), this was the first time I actually had to deal with client-side performance.

You might notice that there are 17 requests to Javascript and CSS files. However, that's not really the issue here. Of course, it's best practise to combine and compress these files (preferably using application logic), which is something I will get to, but for testing purposes it actually helps in this case.

The CSS files loaded were big. Very big. And they totalled up to a whopping 220 KB. Looking at them, it seemed to me that someone had taken the C in CSS a little too literally. For every change to the website (including big redesigns), new lines were added in the CSS and old CSS was left untouched. I could spot blocks spanning hundreds of lines that were totally redundant through the entire website, relating to stuff that once existed, but was now removed from the website. So, I downloaded CSS Usage, a Firefox plugin that can spot unused CSS lines. With this tool, I was able to remove over a thousand lines of unused CSS in less than an hour.

However, this is unmeasurable. Even after deleting a thousand lines, I wasn't able to find any significant improvement in loading time. I needed some kind of profiler. Now, I've been told that Opera has some kind of CSS profiler built-in. And I once loved Opera (before Mozilla came into the picture), so I was happy to give it a whirl. Its timeline gave me a very good look at what's happening between receiving the CSS and finish building the actual page. But its profiler was actually able to record which CSS selectors were used through the entire website (by recording usage while clicking through the website). That meant I was actually able to remove -all- unused CSS selectors. Talk about clean-up, ey?

After doing this, the timeline seemed to approve of my changes. CSS loading time went down, but I'm still not entirely happy. At this point though, it got a little too front-endy for my taste, so I might get back to it at a later time. I could imagine that using a specific type of selectors or style properties could be slower than equivalent pieces of code. Or maybe our stylesheet as a whole just got too heavy. Do note that this -is- in fact a problem with the increase in mobile devices coming to these websites. So it's something we will have to be very wary of.

By moving most of the Javascript from the head tags to the bottom of the page (which is something I've done on most of my projects for a while now), the total loading time didn't get lower, but the DOM loads a lot faster. If your website isn't built by Javascript (which is done more and more in HTML5) this could make your website appear a lot faster. Be aware though, that if you have specific Javascript code that's essential to how your website works (like shopping cart functionality), you might want to keep that in the head, as it might frustrate end-users.

Speeding up the Javascript bit of things is a lot harder though. I myself tend to stay away from heavy JS frameworks like jQuery as much as possible. But I'm no front-ender. Most front-enders I know start with some kind of CSS bootstrap box, include jQuery and build from that. I like my code to be a little more modular if possible (although I'm very aware of the fact that I do use Ruby on Rails a lot, which will provoke a big "ugh" for people coming from more lean development backgrounds). jQuery is very powerful, but that makes it heavy which is not always needed.

However, I haven't really found the big answer. The client was quite happy (after looking at the numbers even more so), because I did my job well. At some point I will have to give the task back to a front-ender, but I really think a big redesign (from the ground up) is warranted in this case.

Comments (0) Trackbacks (0)

No comments yet.

Leave a comment

No trackbacks yet.