YSlow rule #9 – Make JavaScript and CSS External

17. May 2011 · Write a comment · Categories: Performance · Tags: , , , , , ,

We’ve briefly touched this subject a number of times already. Making your JavaScript and CSS external simply means moving it from your HTML header to their own files, referenced as an external file in the header. So why does Yahoo think that this is a good idea? We’ve already discussed the possibility to cache resources in the browser client-side cache. Caching scripts and styles is definitely easier than caching HTML. JavaScript and CSS are typically only changed when changing something on the site like new styling, new features, etc. Changing HTML happens all the time when users write new content, new search results are found, etc. When inlined, the scripts and styles are typically not cached or at least not for a very long time. But wait, here’s the real bonus: scripts and styles are typically shared between multiple views. Moving all that static stuff to external files will make the browser cache them, serving the cached versions when loading page number 2, 3, and so on.

The YSlow documentation argues that you can sometimes benefit from inlining your script and styles directly in the HTML. This only goes for pages with a single page view per session like the Yahoo front page. I can see the point and noticed that pretty much all search engines do this. I still think that you should get a lot of visitors in order to do this kind of thing. So unless you’re Google or your front page uses an entirely different styling than the rest of your site, you should be covered by moving the static stuff to external files.

Another benefit is when debugging through Firebug. When I need to debug some inlined JavaScript, I typically spend some time wondering and then realizing that I can’t debug JavaScript from the HTML tab in Firebug. This usually causes a bit of confusion and sometimes even some pulling out of precious hair strands. The solution is to navigate to the scripts tab and selecting the HTML file. I can understand why the UI works that way, but I keep forgetting. Moving all JavaScript to an external file forces me to navigate to the scripts tab right away.

(Proofread by inWrite)

YSlow rule #8 – Avoid CSS Expressions

04. May 2011 · Write a comment · Categories: Performance · Tags: , ,

Time for another YSlow rule. This week we will be looking at rule number 8—avoid CSS expressions. My knowledge about CSS is very limited, and I’ve always seen CSS as a format for specifying style information rather than an actual programming language. It turns out that you can actually write JavaScript inside your CSS files. First of all, how stupid is that? Sounds a bit like writing JavaScript in your HTML code. I really like each language separated into its own set of files. The idea with CSS expressions should be to do dynamic styling depending on JavaScript code. I really can’t see the need for this, with the powers in JavaScript, jQuery, and even on the server-side when generating the markup.

So what’s the problem with doing CSS expressions? Let’s look at an example from the YSlow documentation:

background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );

The example above set the background color to either of two hex values, depending on the current time. The problem here is that the browser executes the code over and over again, each time the user interacts with the page (scroll, click, and even move the mouse). Even though this only affects the performance inside each individual browser, it can result in a slow-performing browser.
I’ve never used CSS expressions myself and won’t recommend anyone to do so. Also, CSS expressions are only supported by Internet Explorer 5 to 7. Microsoft has really done some cool stuff over the years, but this must be one of their greatest screwups.

(Proofread by inWrite)