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)

This week I have chosen to combine rule numbers 6 and 7. Why? Because they focus on pretty much the same thing: where to put style sheet and script references. According to rule number 6, you should put all your styling in the head section of your HTML document. The YSlow documentation explains why. There’s no magical formula you should know in order to obey this rule, so just do it.

The difficult thing about the two rules is putting JavaScript at the bottom. And by bottom I do not mean the bottom of the head section, but just before the closing body tag. In order to do this, first you need to write your JavaScript unobtrusive, which simply means that you separate your view (HTML) from your controller (JavaScript). When split into these two logical components, you won’t have any nasty document.write statements inlined in your HTML. Placing the script references should now be simple, but you typically still need to execute some JavaScript. Don’t worry, jQuery comes to your rescue with the ready function:


$(document).ready(function() {

// Place some code here

});

The function specified inside the ready method is executed after the DOM has been loaded.

When doing ASP.NET MVC, you most often use a master page for all the common stuff like your menu, header, footer, etc. I’ve used content place holders to ease the implementation of JavaScript in my views, with a master page, which looks like this:

<%@ Master Language="C#" Inherits="System.Web.Mvc.ViewMasterPage" %>
<html>
<head>
<!-- Styles and stuff -->
</head>
<body>
  <!-- Your HTML goes here -->
  <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.5.2/jquery.min.js"></script>

  <script type="text/javascript">
    $(document).ready(function() {
      <asp:ContentPlaceHolder ID="domready" runat="server"></asp:ContentPlaceHolder>
    });
  </script>
</body>
</html>

In your view, you will be able to add a content place holder and write JavaScript right inside. The code will run when the DOM is ready.

(Proofread by inWrite)