Out of the box the SharePoint inject a lot of javascript files and controls for various purpose, like page UI functionalities or backward compatible. E.g corev4.js and SharePointWebControls:UIVerisonedContent.
These additional JS files or components were generated huge amount of overhead when loading a page, see the comparison at below.
That is about 4 times smaller (22.36KB and 80.25KB) than out-of-the-box template, some more the customized template (removed edit scripts and control) was consisted more images and content query webpart compare to standard but empty page.
So my recommendation for public website when using the SharePoint.
- Remove the SharePoint script files from masterpage if you not need them, such as <SharePoint:ScriptLink language="javascript" name="core.js" defer="true" runat="server"/>. Only inject those scripts when in edit mode by using PublishingWebControls:EditModePanel.
- Remove SharePoint editing stylesheets, such as speditingstyle.css, edit-mode-21.css, webtagging.css, wpeditmodev4.css and forms.css. Inject them by using the Editmodepanel.
- Remove the controls from masterpage or page layouts, not to hide or disable them. As system still generate but hide them by style.
how do you account for the javascript errors one might get as a result of removing the script files?
ReplyDeleteCan you elaborate more about the issue you have?
ReplyDeleteThe best way to deal with the javascript error is to fix the source problem.
If the error was SharePoint core script then make sure your custom scripts are not conflict to it. To try it out, go to machine which has error occurred and browse to uncustomised SharePoint site, if problem still exist then it worth to check on alternate access mapping is setup correctly.