Why Is SharePoint So Slow?

Here at Bamboo, we spend a LOT of time in SharePoint — probably more than is healthy. But that doesn’t mean we don’t also spend time on the rest of the Internet, updating our fantasy team lineups, reading WordPress sites, and playing with the latest and greatest applications out there on the Web. And if there’s one thing that hasn’t changed in my four years of using, testing, extending, and working with SharePoint on a daily basis (along with the rest of the Web), it’s this :

SharePoint is shockingly slow.  And I want to know why.

We’re living in the middle of a truly incredible browser renaissance. Developers and analysts can all put their preferred spin on it, but let’s face it — the era of the coolest, most responsive, most interactive sites and applications operating in resource-heavy, proprietary run-times like Flash and Silverlight isn’t just dead — it’s decomposing. The raw, standards-powered browser experience we clumsily categorize as “HTML5” is here right now, and to be blunt… it’s absolutely fantastic. With innovations like the canvas tag, hardware accelerated CSS animations, and better, lighter, more powerful JavaScript libraries that give us seamlessly interactive experiences with our content, browsers like Chrome, Safari, and the upcoming IE10 are making life on the Web a more natural, fluid experience. It’s getting better — literally — the day.

Now, let’s go back to SharePoint. We’re living in a world where I can manipulate reams of data with the click of a mouse without so much as reloading a page. But in SharePoint? I can’t so much as open a list item without running into a time-suck like this :

Attention, SharePoint. It’s 2011, not 1996. People are doing actual, real-life WORK on the Web. Millions of information drones like yours truly are being pushed to the almighty cloud with the promise of a desktop-like (or at least a Facebook-like) experience inside our Web browsers. You simply can’t expect users to get anything done with constant interruptions like this, disorienting full-screen page reloads, and general stuck-in-the-mud performance. Whether that’s from long page rendering times, frustrating workflows for common tasks like editing list items, or the frequency of security prompts and access problems — or a combination of all these things — it doesn’t matter to the end user. The bottom line is getting something done in SharePoint extracts an enormous cost from workers in time, patience, and engagement with their work. If you’re waiting for your most creative, motivated team members to start revolutionizing your business with user-driven productivity applications built in SharePoint, be prepared to wait for a very long time. 

I’d ask whose fault this is (or, more constructively, how we can fix it), but that simply leads us to another problem. There are SO many people to blame — it’s our hardware setup, our configuration, the number of items in our lists, our column types, the timer… it’s always something. And yet, somehow, a couple kids in a Palo Alto apartment can let me DJ streaming music to people all across the planet without so much as a “please wait” cursor? You want to see the “consumerization of IT”? Start giving workers the kind of responsive, satisfying tools and Web experiences they’re getting at home. Until then, all the “Like” buttons and micro-blogging in the world isn’t going to do squat.

Microsoft continues to do amazing things with SharePoint, but I remain completely baffled at how muddy and anti-human the basic mechanics of interacting with SharePoint really are. It simply takes way, way too long to do anything of any real importance. The speed of the Web is always changing, but one thing’s for sure — it’s a hell of a lot faster than SharePoint.

So engineers, consultants and geniuses of the industry, riddle me this. Why is SharePoint so slow? And does anyone care?

Craig Humphrey
re: Why Is SharePoint So Slow?
on Tue, Dec 6 2011 5:14 PM

My 2c says:

SharePoint is a general purpose tool, built on a general purpose platform, designed to be as many things to as many different people as possible.

General purpose tools are rarely as efficient as purpose built tools.

Having said that, you could spend (a lot of) time working through a bazzillion different options in disk, RAM, CPU, SQL, network, load-balancing, caching, etc, settings to work your way through bottlenecks.

I guess that’s why MS’s reccomended configurations are always speced so high.

Reality is that you end up tuning for as “acceptable” performance as your budget allows.

I’m just happy for the performance gains to be had going from SP2007 (on svr2003 x86) to SP2010 (on svr208R2 x64), even if the VMs (!) are lower spec!



Nate Sullivan
re: Why Is SharePoint So Slow?
on Tue, Dec 6 2011 9:29 PM

One of those two sides of the performance coin (stuff like page loading, rendering performance, and how long it takes to pull data) seems to get a decent amount of focus in the industry.

To me, the other half — the general purpose nature — is the real hurdle. SharePoint’s getting a lot of buzz as an application development environment, but the quality of those applications may be inherently limited the nature of the platform and the way people interact with it.

You can address some of those things with (ahem, Bamboo) web parts and custom components, but the efficiency gaps between purpose built and general purpose tools is something I don’t think enough business decision makers really take into account.