Have you ever wondered the best way to deliver your JavaScript to the client?  Well, Ken is a member of our local ColdFusion User-Group, and posed the following question:

I have a set of JavaScript functions that I used in lots of my code.  Which method is more efficient for use with CF pages:

  1. Have them in a .js file and cfinclude it.
  2. Have them in a .cfm file and cfinclude it.
  3. Have them in a .js and src= include it.
  4. Some other way I haven’t thought of.

In response to Ken’s question, I tried to offer some tips that would help him make a better decision for his clients.  In general, here is what I thought:

Using the <cfinclude> to deliver the JS with the HTML content is "faster" than including the JS file via the src attribute of the script tag.  My reasoning is that when you use the src attribute, the browser makes another request to the server (like an image) to retrieve the file; whereas by including it in the HTML output the browser is not making another request. 

    As far as the file extension, I would think you would want it to be a .JS file.  My reasoning here is that unless you have ColdFusion code within your JS file there is no reason to have ColdFusion process the page to look for CF code when there is none.  With a .cfm file, the file will first be processed by ColdFusion before being included (or delivered to the browser via your web server).

    Also, if you are concerned about the file size of your JS you should look into the possibility of compressing the file.  I have found dean edward’s packer program to work the best: dean.edwards.name/packer.  Keep in mind, in order for compression to work properly you should ensure that all statements are followed by a semi-colon and all if/else statements use {} brackets (since most compressions puts all the JS on one line).

I wanted to follow-up with this, and determine if the file extension matter to ColdFusion when including the file using <cfinclude>.  In the end, ColdFusion will process the file you include to determine if there is any ColdFusion code in, no matter the file extension.  The only time the file extension will have an impact is when the client requests the file from the web server, which will determine if it needs to be pre-processed prior to delivery to the client by examining the file extension and the settings of the web server.

I guess the best answer to this question that Ken posed, is to use either <cffile> or the java file library to read in the JS file and output the contents of the file directly within your CFM or HTML template that the client has requested.  For example, it would as simple as:

?View Code COLDFUSION
1
2
3
4
<cffile action="read" file="common.js" variable="jsoutput">
<script type="text/javascript" language="javascript">
<cfoutput>#jsoutput</cfoutput>
</script>

Or, using the java.io.FileReader and java.io.BufferedReader java libraries to read the file in line-by-line:

?View Code COLDFUSION
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<cfscript>
    function outputLine(line){
        WriteOutput(arguments.line);
    }
    function readFile(filename){
        var fileStr = '';
        var fileReaderClass = createObject("java", "java.io.FileReader");
        var fileReader = fileReaderClass.init(expandpath('.')&'\'&arguments.filename);
        var bufferedReader = createObject("java", "java.io.BufferedReader");
        bufferedReader.init(fileReader);
        try {
           do {
              fileStr = bufferedReader.readLine();
              outputLine(fileStr);
           } while (true);
        } catch (coldfusion.runtime.UndefinedVariableException e) {
            // this indicates end of file, ok to ignore error
        }
    }
    readFile('test.js');
</cfscript>

You can also download and use Ray Camden’s FileRead function available on cflib.org.

Update:

    Thanks to Charlie Arehart for pointing this out when using <cfinclude> to include JS in your CFM template:

If you do that, then you’re causing the full source of the JS code to be sent down to the browser on each page request (just as if you had simply placed the JS code onto the page itself).

This is where the script src attribute is so important (and performs better). That will cause the browser to go get the code, yes (as Brian said), but the browser will cache that and won’t go get it on subsequent requests.

If your end users visit such a page more than once, or especially if more than one page using the code would be visited by such a user, the benefit of the SCRIPT SRC should quickly add up.

This entry was posted on Thursday, July 19th, 2007 at 10:03 am.
Categories: Uncategorized.

No Comments, Comment or Ping

Reply to “Optimizing JS delivery to client”