12

So it seems to be that Sharepoint's front-end optimization is non-existant. For example, http://dfs.us.dell.com/Pages/DFSHomePage.aspx, according to YSlow, is serving up 14 separate JavaScript files, core.js being 265k be itself.

Does anyone know what JavaScript and CSS files you do not need to send across the wire for a public-facing site? I'm guessing most SP sites are serving up unnecessary files, files intended for the back-end/admin pages/interface.

I am not singling out the above URL, either, I've checked out a lot of SP sites and the front-end performance on them suck really bad. Even Microsoft's flagship SP site (sharepoint.microsoft.com/Pages/Default.aspx) is really bad, 11 JS files at 413k, 5 CSS files at 316k, just loading the home page loads 930k.

So, what is the SP community doing about this? Are you guys even aware of it?

Improve this question

10 Answers 10

Reset to default
3

The answer to the first part of the question is you don't need any of them if you are prepared to fully customize the HTML and CSS, and do your own web parts and other controls.

There are two problems here; first you need to make your public-facing site so it doesn't need the huge JavaScript and CSS files that are part of the SharePoint UI. You will probably lose some of that dependency anyway because you will start with a menu-less "minimal master page", and build the HTML page structure from there. (But you will need to keep the SharePoint page furniture for Windows authenticated users or at least the application pages).

The second problem is to stop the core.css, core.js, init.js, ie55up.css, etc. getting loaded in the anonymous view. This is more difficult than you might think as SharePoint tends to try to pop them back into the page when you think you have removed them. Some experts think it is diminishing returns to get rid of all of these - the more you remove, the more out-of-the-box functionality you break. But getting rid of the big core.css and core.js is usually well worth the effort.

Improve this answer
3

I was involved in optimizing a poorly-performing SharePoint 2007 site for an international airline. I wrote an optimzation checklist for SharePoint sites as a result of the work we did - it mainly considers thing from a dev standpoint, but optimization is definitely one of those '360 degree' things.

I also think Aptimize looks great - I'd love to try it out for real. However it's worth remembering it is just using techniques which you can implement 'manually' (e.g. minifying JavaScript/CSS, stiching images together etc.) which could work out more cost-effective. Much less implementation effort though, so YMMV.

Improve this answer
2

Don't forget to tune your IIS and use compression techniques for (at least) static files. This will lower the used bandwidth. You can also add http headers and allow caching of these files, on client/proxies, which reduces hits on the server.

On a side note it's worth mentioning that if you use jQuery (which is very popular nowadays in the SP world), you can take advantage of the Microsoft Ajax CDN, where Microsoft hosts the jQuery file, which allows for better caching abilities. Read ScottGu's announcement about this.

Having core.js hosted like this would be cool, right?

Improve this answer
1

Recently there's been a lot of articles about optimizing SharePoint performance (mostly because so many new sites are coming online using it). One of the main ones can be found here. Others can be found via a quick search. Use the same techniques you would on any site (move javascript to bottom of page, use CSS image sprites, etc.) to get more performance. I tuned our intranet site from 15 seconds down to 2 with some very basic techniques.

Yes, SharePoint is a bad culprit of large javascript and CSS files and it doesn't get much better with 2010. However keep applying some basic good pracices and you'll be fine.

Improve this answer
1

Well it looks like most of the online resources I know about have been covered here already, so I won't repeat them. However, one that I didn't see that you should check out once you've done all the SharePoint and IIS optimization but still need to get a little bit more:

http://aptimize.com

It's a pretty good, low-touch (ie. you don't have to change code and make it harder to maintain) way of reducing the request counts and overall delivery load and speed using all those tricky techniques like CSS Sprites, JS minification/combining, etc... that normally lead to hard to maintain sites (but in this case you don't have to sacrifice maintainability).

Improve this answer
1

I have been able removed about 17 SharePoint JavaScript requests for anonymous users using the technique by Chris O'Brien removing the script references included in 

HttpContext.Current.Items["sp-scriptlinks"]

I placed the control at the bottom of the page to be able to remove more files:

<custom:SuppressScriptsForAnonymousUsers runat="server" FilesToSuppress="core.js;SP.Ribbon.js;ie55up.js;msstring.js" />

This made size of the page go from approx 500 KB to approx 100 KB so it makes alot of difference. I still can't remove a couple of files, and if anyone have suggestions on how to remove them I would be happy to receive them, problem is I don't know what is outputting them. Therefore it is hard to use control adapter which would be nice. Here they are:

  • init.js - needed for PostBacks to work in SharePoint
  • WebResources.axd script - seems to include post back functions, which probably is needed for SharePoint to function
  • blank.js (requested twice) - includes only one function ULSPvi(), don't know what it does
  • ScriptResource.axd script - is the MicrosoftAjax.js library
  • Another ScriptResource.axd script - is the MicrosoftAjaxWebForms.js library
Improve this answer
2
  • Just noticed this. Cool, thanks for the feedback, I've been looking for other data. P.S. I heard recently my code/this approach is now used on several Microsoft sites including sharepoint.microsoft.com.
    – Chris O'Brien - MVP
    Commented Dec 22, 2011 at 17:08
  • That's nice! Yep, it has been working really well! Just make sure to test it, just noticed that init.js was needed for postbacks to work. Have removed it from the exemple.
    – Christian Fredh
    Commented Jan 3, 2012 at 13:21
0

Core.js mainly operates the site actions menu and other admin functions. So you can safely drop this for unauthenticated users.

Obviously your authenticated users will require core.js, but this won't affect the payload size of your public facing site for the majority of users.

Andrew Connell has looked into this area as well as lazy loading the core.js as Bil has said above.

Improve this answer
0

All of the above work very well (IIS Compression, lazy loading core.js, etc.) however I have also had to further optimize using the hardware load balancers (in my case these are BigIP F5's). Techniques in addition to compression and lazy loading that I have seen successful is "pinning" all .css, js, and image files in the F5 so that a roundtrip to the SharePoint content database is only needed once.

We are currently experimenting with an F5 Web Accelerator that forces a lot of things (.JS, .CSS, images, etc.) into the browser cache and does some nice optimization to these files on the fly when the response is generated from SharePoint and sent to the browser. Load tests are currently showing VERY good results.

Improve this answer
0

Rob,

We also use an F5. Do you have any references on how to perform the pinning of CSS, JS and images files in the F5?

Improve this answer
1
  • @cosje: Why don't you ask this as a new question (assuming its related to SharePoint)? Then Rob and others can answer. Thanks and welcome to the site!
    – Alex Angas
    Commented Oct 28, 2009 at 16:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.