Is using inline JavaScript preferred to an external include if the script is really short?

Question

I use External JavaScripts in a website as I always try to keep JavaScript at bottom and external.

But Google page speed is giving this suggestion

The following external resources have small response bodies. Inlining the response in HTML can reduce blocking of page rendering.

http://websiteurl/ should inline the following small resources: http://websiteurl/script.js

This external js file has only this content

$(document).ready(function() {
    $("#various2").fancybox({
        'width': 485,
        'height': 691,
    });
});

But in Yslow I get this suggestion

Grade n/a on Make JavaScript and CSS external

Only consider this if your property is a common user home page.

There are a total of 3 inline scripts

JavaScript and CSS that are inlined in HTML documents get downloaded each time the HTML document is requested. This reduces the number of HTTP requests but increases the HTML document size. On the other hand, if the JavaScript and CSS are in external files cached by the browser, the HTML document size is reduced without increasing the number of HTTP requests.

Which is right Google or Yahoo?

Answer 1

This is a bit of a problematic example, on quite a few fronts.

You can organise your scripts in such a way that you do not need to inline that JS. For example you could have a common.js file that runs that snippet, other similar snippets and simplifies your code.

Additionally, this seems to have awoken "never inline any JavaScript EVER" architecture police. Turns out that sometimes it is a best practice to inline JavaScript, for example look at the common snippet from Google analytics.

Why are Google suggesting you should inline this tiny script?

• Because 20% of the page visits you get have an unprimed cache
• If you have a cache miss, it is likely a new connection to your site will need to be opened (1 round trip) and then the data delivered in the 2nd round trip. (if you are lucky you get to use a keepalive connection and it is cut to 1 round trip.
• For a general "global" English web application you are looking at a typical 110ms round trip time for a service hosted in the US. If you are using a CDN the number would probably be halved.
• Even if the resource is local, the web browser may still need to access the disk to grab that tiny file.
• Non async or defer JavaScript script tags are blocking, if this script is somewhere in the middle of your page, it will be stuck there until the script downloads.

From a performance perspective if the only 2 options are:

1. Place a 50 char JavaScript bit inline
2. Place the 50 chars in a separate file and serve it.

Considering that you are a good web citizen and compress all your content, the amount of additional payload this adds is negligible compared to the 20 percent risk of giving people a considerable delay. I would always choose #1.

In an imperfect world it is very rare to have such a clear and easy set of options. There is an option 3 that involved async loading jQuery and grabbing this functionality from a common area.

Answer 2

Making scripts inline can have some detrimental effects -

a) Code organization - Your code gets scattered in between your markup, thus affecting readability

b) Code Minification and obfuscation becomes difficult

Its best to keep your js in seperate files, and then at build time integrate all of them into a single file, and minify and obfuscate this.

Answer 3

This is not quite true. You can configure the web server (well atleast apache) to make the scrips/ccs inlined when they are served.

Here is a useful link

http://www.websiteoptimization.com/speed/tweak/mod_pagespeed/

Answer 4

There are two factors to consider here. One is download time, the other is maintainability. Both of these are impacted by how many times a piece of Javascript is needed.

With respect to download time, you obviously have two choices: include the JS in the body of the page, or as an external file. Including the JS in the body does save an extra HTTP request, although it also bloats the HTML a bit and can be a pain to maintain if you have several scripts you're putting inline on several different pages.

Another important consideration is whether or not the JS is needed immediately on the page. If a small piece of JS is needed as soon as the page loads, then putting it inline may be a good idea. If it's being used for something asynchronous in the future, then putting it an external file may still be a good choice.

Answer 5

I usually write javascript inline, especially if the script is this small. I would say just paste it in your code. It won't increase the http document size by a lot.

Answer 6

While inlining the script will save a request, as Yslow suggests it increases the HTML document size, and mixes content/markup with code/logic, which you generally want to avoid from as much as possible.

The reason Yslow gives this caveat:

Only consider this if your property is a common user home page.

Is that if the page is loaded frequently, it's worth it to have the javascript external, since the files will be cached in the browser. So, if you combine your JS into one file, on the first request you incur one extra request, and on subsequent requests the file is loaded from the cache.

Answer 7

Aaron Peters talk from last year's Velocity EU gives a good insight into the options, and course you should choose - http://www.slideshare.net/startrender/fast-loading-javascript

For really small snippet of js it's really not worth putting them in an external file as the network overhead of retrieving them will dwarf the benefits.

Depending on the latency it may be ever worth including large scripts e.g. Bind mobile has loads of js in the first page loaded which it then cached in localstorage for later pages.

Addy Osmani recently put together a experimental library to help people play with caching scripts in localstorage - http://addyosmani.github.com/basket.js/