In our pany we bine every Javascript file into one big (around 700kb but growing) minified and gzipped Javascript file. I am trying to assess the performance differences between using one big Javascript file for every page (minified and gzipped) and using several Javascript files, one for each page.

An obvious difference is that the big Javascript file can be cached by browsers after it has been loaded on the first page request and creates little overhead thereafter while when using several js files, there will be at least one uncached get request on each different page. So I would be trading a slower first initial page load for slower successive initial page loads.

In order to find out when the slow initial page load (using one big Javascript file) will bee problematic enough to justify the work of breaking up the bined file into smaller files and changing our build procedure, I would like to find out how long it takes for the code to be parsed, so I can estimate the total loading and parsing time.

So far my approach has been to add a script tag to a test page which takes the current time, appending a bigish script with Javascript and after that meassuring time again like so:

var head = document.getElementsByTagName('head')[0];
var script = document.createElement('script')
script.setAttribute('type', 'text/javascript');
script.src = 'path/700kbCombineFile.js';
start_time = new Date().getTime();
head.appendChild(script);

At the end of 700kbCombineFile.js, I appended:

console.log(new Date().getTime() - start_time)

Then I subtract the network transfer time obtained from firebug and receive approximately 700ms for a 700 kb file and about 300ms for a 300 kb file.

Does this approach make sense? Why not? Is there a better way/any tools for doing this?

In our pany we bine every Javascript file into one big (around 700kb but growing) minified and gzipped Javascript file. I am trying to assess the performance differences between using one big Javascript file for every page (minified and gzipped) and using several Javascript files, one for each page.

An obvious difference is that the big Javascript file can be cached by browsers after it has been loaded on the first page request and creates little overhead thereafter while when using several js files, there will be at least one uncached get request on each different page. So I would be trading a slower first initial page load for slower successive initial page loads.

In order to find out when the slow initial page load (using one big Javascript file) will bee problematic enough to justify the work of breaking up the bined file into smaller files and changing our build procedure, I would like to find out how long it takes for the code to be parsed, so I can estimate the total loading and parsing time.

So far my approach has been to add a script tag to a test page which takes the current time, appending a bigish script with Javascript and after that meassuring time again like so:

var head = document.getElementsByTagName('head')[0];
var script = document.createElement('script')
script.setAttribute('type', 'text/javascript');
script.src = 'path/700kbCombineFile.js';
start_time = new Date().getTime();
head.appendChild(script);

At the end of 700kbCombineFile.js, I appended:

console.log(new Date().getTime() - start_time)

Then I subtract the network transfer time obtained from firebug and receive approximately 700ms for a 700 kb file and about 300ms for a 300 kb file.

Does this approach make sense? Why not? Is there a better way/any tools for doing this?

• javascript

• Doesn't firebug tell you the http-load-time apart from the execution time? – Bergi Commented Jul 12, 2012 at 13:50
• 1 I dont think firebug tells you the execution time. Anyway, I am wondering about the parse time. I.e. the time it takes to parse the javascript, not the execution time – Johannes Degn Commented Jul 12, 2012 at 13:52
• Opera's Dragonfly can both show you accurate information on the HTTP connection, and distinguishes between "script pilation" and "thread execution" when profiling. – Bergi Commented Jul 12, 2012 at 13:57
• you can do like this: youtube./watch?v=nCgQDjiotG0 – Sebas Commented Jul 12, 2012 at 14:01
• @Bergi dragonfly does look promising (i pletely neglected opera until now), however with my method I get a result of 290 ms while dragonfly reports total load time of 30 ms and reading and processing of 12 ms if added up. I wonder what that means... – Johannes Degn Commented Jul 12, 2012 at 14:26

2 Answers 2

I think console.time("Parsetime")

and console.timeEnd("Parsetime")

gives you a more accurate measurement then the Date Object,
Article about javascript time accuracy

The amount of time taken to parse the JavaScript will vary significantly between browsers.

What you've got is the best method I can think of to measure the parse time, however, I would question whether this is the best measurement to judge which approach is more effective.

Personally, I'd consider the time taken for the load event on the window to fire, from the time the page was requested a better measurement on which approach to go for.

The time taken to download the page is important, and a file always been cached after 1st load is only ever true in a perfect world.