Remove 'init.js' and 'control.css' from your public SharePoint site

Search

Accessible SharePoint WebSites
Download ARF

Remove 'init.js' and 'control.css' from your public SharePoint site

http://blog.thekid.me.uk

Most of the SharePoint websites I work on do not expose any of the standard SharePoint functionality. They do not use webparts and so do not require any of the SharePoint javascript functionality.

SharePoint includes files to support the client side functionality of its controls, init.js, core.js, controls.css and core.css. These files are pretty large and in the interest of increasing the speed of loading your page its best to remove them, assuming they are not being used.

So a tip for your SharePoint publishing site is to remove them, but keep them available to your authors. You can do this using the AuthoringContainer control.

<PublishingWebControls:AuthoringContainer runat="server" id="AuthoringContainer1" DisplayAudience="AuthorsOnly">

    <SharePoint:CssRegistration name="<% $SPUrl:~sitecollection/Style Library/~language/Core Styles/controls.css %>" runat="server"/>

    <SharePoint:ScriptLink name="init.js" runat="server"/>

    <Sharepoint:CssLink runat="server"/>

</PublishingWebControls:AuthoringContainer>

By wrapping these controls with a SharePoint AuthoringContainer you can speed up the load time of your publishing site to your visitors, but keep the authoring functionality available to your site authors.

Sometimes I have also included the PlaceHolderAdditionalPageHead to ensure other unwanted js or css files are excluded.

<asp:ContentPlaceHolder id="PlaceHolderAdditionalPageHead" runat="server"/>

Another quick tip

Sometimes your custom CSS will not work well with the SharePoint field controls and so you need to fix the look and feel. This is important to make the editing experience as good as possible, ensuring the authors are happy. Personally I like to keep the default CSS specific to viewing the site and not try to have one CSS file for both viewing and authoring.

By using the SharePoint EditModePanel you can include a separate stylesheet, specifically designed to override any styles affecting the authoring look and feel. This makes the authoring experience much more usable, does not compromise your  original CSS and is only included when editing a page.

<PublishingWebControls:EditModePanel runat="server">

    <link type="text/css" rel="stylesheet" href="/Style Library/ARF_editing.css" />

</PublishingWebControls:EditModePanel>

Posted by Vincent Rothwell on Monday, 10 Nov 2008 10:42  - 10 Comments
Orininally printed from http://thekid.me.uk - Copyright Vincent Rothwell 2007
 

Comments

Tuesday, 11 Nov 2008 11:15 by Manish
This is helpful. Also on the same line you can see the article here: http://manish-sharepoint.blogspot.com/2008/05/improving-sharepoint-site-performance.html

Monday, 17 Nov 2008 02:04 by Richard Harbridge
Cute. I can't believe I didn't think of this. Thank you, Richard

Friday, 19 Dec 2008 03:14 by

Wednesday, 21 Jan 2009 07:56 by Yair
When you remove the init.js file, the OnLoad function spBodyOnLoadWrapper() throws an error. Is this function can be removed also? Thanks.

Monday, 23 Feb 2009 03:48 by Ergin BULUT
You can remove onload event on body tag or create a dummy spBodyOnLoadWrapper() function inside script tags over init.js line so in design mode spBodyOnLoadWrapper function in init.js file can overwrite dummy one.

Wednesday, 15 Apr 2009 02:39 by Mahmoud Algoul
I have create a dummy spBodyOnLoadWrapper() function inside script tags over init.js line, it removed one error from 3, and the error appear only for Anonymous users, any help please.

Wednesday, 10 Jun 2009 09:41 by Sam
Just to take note that if you use this method. Using the backend to upload Alternate CSS URL for a Site Master Template will not render in the Annoynomous Mode as the Alternate CSS URL will appear together with the CSS (eg: core.css) under the CSSLink Control.

Tuesday, 14 Jul 2009 07:44 by Brad
I tried this out and something else seems to still inject controls.css and init.js, even for anonymous. As a guess, if any sharepoint controls such as the search control or content query are on the page the controls must do a registerscript to force these to be included, even if anonymous? But that's just a guess.

Wednesday, 15 Jul 2009 03:08 by Brad
I tried this out and something else seems to still inject controls.css and init.js, even for anonymous. As a guess, if any sharepoint controls such as the search control or content query are on the page the controls must do a registerscript to force these to be included, even if anonymous? But that's just a guess.

Tuesday, 1 Sep 2009 03:58 by Scott
Well this certainly is an interesting concept. I am not sure how the following will be affected without the init.js. There is a KB article (http://support.microsoft.com/?kbid=931509 that suggests commenting out function ProcessImn() in init.js. However, if you do comment it out, you will loose the functionality of "Upload Multiple Documents" within a document library. As a result of commenting it out (or in the case of this article - removing the file) The client browser does not load MSO.DLL and when STSUPLD.DLL won't be able to locate it - breaking things as described above. So, this really is a question I guess... if you use the authoring container methodology as described in this article, does the multiple document upload feature remain ? Scott



Url

Email

Comments