views:

642

answers:

2

I've been using the toolscriptmanager included in the AjaxControlToolkit on my site. This one has a CombineScript attribute that tells the scripmanager to combine the necessary scripts from ajax controls into one single script file. However, since 3.5, the standard scriptmanager has support for "<CompositScripts>" where you can combine (manually selected) scripts into one file.

Should I keep using toolscriptmanager or should I use CompositScript to maximize performance?

A: 

I got the feeling that ScriptManager's Composite Scripts is intended for use with mutliple js files.

<asp:ScriptManager ID="ScriptManager1" runat="server">
    <CompositeScript>
        <Scripts>
            <asp:ScriptReference Path="~/Scripts/Script1.js" />
            <asp:ScriptReference Path="~/Scripts/Script2.js" />
            <asp:ScriptReference Path="~/Scripts/Script3.js" />
        </Scripts>
    </CompositeScript>
</asp:ScriptManager>

While ToolScriptManager combined the auto-generated Resource scripts. (as well as other specified scripts: http://stackoverflow.com/questions/626659/combine-scripts-in-asp-net-ajax-toolkit)

ScriptManager will allow you to pick and choose which script file get combined, which depending on you site usage of the various files, would allow for fewer user downloads.

I would continue using the ToolkitScriptManager.

Chris
+2  A: 

The two tools are essentially two different approaches to the same goal.

The Toolkit's script manager aims to combine every available JS file, across the entire site. The benefit here is that it's easy to set up - you replace the ScriptManager and let it go. The downside is that unless every page uses the exact same set of scripts, you will force your users to download excessive amount of script code. If your homepage uses scripts A,B,C,D and an inner page uses A,B,C,D,E, then when your user hits the inner page, they'll have to redownload the contents of A,B,C,D because it will be part of a different combined script resource.

The CompositeScript feature is meant to be very picky about what scripts it includes. The developer must analyze what scripts are utilized on every page and add them to the combined script. In the previous example, you could select (in a master page, preferably) for A,B,C,D to be combined, but not E. Then your user would hit the homepage, and download A,B,C,D in one shot. They would then continue to the inner page, would already have A-D in their browser cache, and only have to download E.

So as with many things, it depends upon your architecture and how much effort you can afford to put into it. These both seem like extreme approaches, one from the side of include by default, one on exclude by default, and there doesn't seem to be any middle path. (How I wish there was one.)

EDIT: What was objectionable about this answer that required a downvote? Please explain yourself with a comment.

David
Thanks! (I hope I wasn't the one who downvoted it..???)We've actually chosen a third option, manually combining all scripts that's needed from all pages into one script file (A,B,C,D,E). This means that the users only have to do one single script-request once. Turned out that latency was a bigger issue than transfer time, specifically for users in asia. So reducing the amount of requests to a minimum was the best option for us.
Bjorn