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.