Welcome to MSDN Blogs Sign in | Join | Help

Caching and crunching your JS Files on Office Live

Performance of a web application or page is still a huge pain point for internet users even in the day of pervasive broadband connectivity.  Some information came across my desk that says increases as small as a tenth or a half a second in page load time is enough to deter customers from purchasing on some well-known commerce web sites (which shall remain nameless here). 

 

Two common strategies to improve download perf on web pages are file caching and crunching/compression.  File caching could take a few different forms such as caching pages in memory so the server doesn’t have to access the file every time or caching pages in the temporary internet files of a browser.  Crunching is a shorthand term meaning removing all of the unnecessary comments, characters, whitespaces, etc. from a file before it is transmitted, thus reducing the payload and hopefully time of transmission.

 

Office Live has a handler that does both caching and crunching of javascript JS files hosted on our servers.  But caching JS files can prevent developers from seeing their changes real-time while they are updating code.  And crunching can make debugging script more difficult to read too. 

 

There are techniques to work-around caching that many web developers are aware of, but they may not work on Office Live.  Even if you hit F5 repeatedly, delete your temporary internet files, change proxies, etc. etc., you will probably still get the same JS file from the Office Live cache for at least 24 hours.  Also, you (the developer) don’t have the ability to make configuration changes on our servers that might avoid caching during code authoring.

 

So we’ve developed a few techniques to deal with our JS file caching and crunching and want to share them with you.

 

Circumvent JS file caching

The easy way to avoid caching of your JS files is to rename the file extension to something different, for example JSN or JSX. 

 

But if you are using a nice JavaScript editor like SharePoint Designer, you want to keep the advantages of intellisense, auto-complete and code coloring, so that means you need to keep the JS extension.  One way to have your cake and eat it too is to dynamically change a querystring parameter being passed to the JS file each time the file is requested.  This will make your JS file request unique, so you will always get a new copy of the file.

 

Here is a code snippet that does just that.  It has a function that appends a timestamp as the value for the querystring parameter “version”. Add the includeJS() function to your page, and every time you reference a JS file, just pass in the JS file name and path to the function. 

 

<script type="text/javascript" language="javascript">   

<!--

    function includeJS(src)

    {   

        document.write("<script type=\"text/javascript\" language=\"javascript\" src=\"" + src +

            "?version=" + new Date().getTime() + "\"></script>");

    }

-->

</script>

 

<script type="text/javascript" language="javascript">

    includeJS("js/stuff.js");

    includeJS("js/goo.js");

</script>

 

Avoid javascript crunching

If you are trying to pop your script into a script debugger, and are finding the code hard to read due to the javascript  compression that removes all of the tabs, spacing and so forth, the simplest solution is to just change the file extension of your JS file to something else like JSN or JSX.  Then just change the reference in your HTM or ASPX page to refer to the new file name.

 

Enable caching when done & other recommendations

When you are satisfied with the changes that you have made to your script, you should definitely take advantage of the caching and crunching by changing your file extension back to JS and/or remove any code you may have used to dynamically change the querystring parameters.  Your customers will be happy you did.

 

Also, we encourage you to version your JS files so that you can keep track of where you are with that file.  This will also help ensure that the other caches out there (proxies, browser) do not hang on to copies of your old JS files.  Something as simple as foo_1.js and foo_2.js should do the trick.

Published Thursday, November 16, 2006 10:40 AM by cbeiter

Comments

# Chris s unofficial Office Live developer blog Caching and crunching | Paid Surveys

New Comments to this post are disabled
 
Page view tracker