At the Rich Web Experience conference this week, there were many talks about performance and tools like ySlow. Everybody acknowledges that downloading lots of javascript and css with multiple script or link tags is a key reason that Ajax sites are slow to start, due to the latency of multiple round trips over the network. Yet almost every example I saw at the show had multiple script tags and css links.
More over, none of the frameworks that I know provide mechanisms for easily switching from development mode (with individual scripts and links) to production mode with combined scripts that are stripped and compressed and it is an error prone process to edit markup in the transition from development to production.
So I have written ConcatServlet that allows multiple scripts tags like:
<script type="text/javascript" src="js/behaviour.js"></script>
<script type="text/javascript" src="js/ajax.js&/chat/chat.js"></script>
<script type="text/javascript" src="chat/chat.js"></script>
to be replaced with the single tag:
<script type="text/javascript"
src="concat?/js/behaviour.js&/js/ajax.js&/chat/chat.js">
</script>
The same servlet can also be used for css links.
The servlet uses RequestDispatcher.include, so it can be used with dynamic scripts, such as those generated for DWR. The down side of this approach is that it can’t get the last modified dates of the individual resources, so the browser will not well cache the combination. So the servlet may be run in development mode, where the content is always combined and served, or in production mode where the start time of the servlet is used as the last modified time. This is production, the servlet needs to be restarted before any changed scripts will be served in response to If-Modified-Since requests.
If this style of script and link tag is well received, then in future, the servlet could be modified to do a better job with detecting modifications, caching combinations and perhaps stripping comments and whitespace. It would also be possible to cache combinations in direct buffers so they can be served efficiently by Jetty’s NIO layer.
This servlet will be in the utilities jar of the 6.1.6 Jetty release.
