Why is my Sitecore site running so slow? Check the front end performance

This is the first post in a series of blog posts under the theme I call Why is my Sitecore site running so slow? Lately, I have been pulled in to audit a number of Sitecore solutions because they had poor performance. One thing I noticed was that there is no real common cause for these sites to run slow - but what is common is that the client is always very frustrated, and typically blames Sitecore for the poor performance. That conclusion is rarely well founded - instead, the solution to the performance problem is typically found looking at the custom solution built on top of Sitecore or how it is used by the client. Most of the time, various pieces of code unexpectedly end up taxing the CPU, or has a poor implementation / performance when various events occur on the server. Or maybe the caching configuration is inadequate or not configured at all. Inefficient algorithms, use of Sitecore querying in optimistic ways or just incorrect use of third party components like Lucene are more often the cause that Sitecore itself. But one thing I notice is the the front end performance is often neglected completely by developers. You might have heard about front end analyzers like Yahoo's YSlow and AOL Pagetester - anyway, they are basically browser add-ons that monitor the performance of the site from a front end perspective. I specifically use YSlow, as it is very well structured, and it is considered an industry standard for front end performance analysis by many. YSlow grades a site A through F based on the following rules:
  • Make fewer HTTP requests
  • Use a Content Delivery Network (CDN)
  • Avoid empty src or href
  • Add Expires headers
  • Compress components with gzip
  • Put CSS at top
  • Put JavaScript at bottom
  • Avoid CSS expressions
  • Make JavaScript and CSS external
  • Reduce DNS lookups
  • Minify JavaScript and CSS
  • Avoid URL redirects
  • Remove duplicate JavaScript and CSS
  • Configure entity tags (ETags)
  • Make AJAX cacheable
  • Use GET for AJAX requests
  • Reduce the number of DOM elements
  • Avoid HTTP 404 (Not Found) error
  • Reduce cookie size
  • Use cookie-free domains
  • Avoid AlphaImageLoader filter
  • Do not scale images in HTML
  • Make favicon small and cacheable
I could go through each of these, but I'll leave that up to you the reader - but I typically find that the top of the list includes the most beneficial optimizations needed for most sites. Most large sites would probably get an overall grade of D or F in YSlow scoring, as they typically load way to many images and don't use CSS Sprites. A good score is a C or B - and that takes some paying attention to the YSlow rules. Getting an A score is virtually impossible for most sites - not even Yahoo get A on all their pages :-) Another important front end performance factor outside the YSlow framework is page weight - how many Kb do I need to download to get the full page rendered. This is often a shocker - I recently tested a site, and found that the home page required 2.2MB to be downloaded. It wasn't a visually expansive site - it was very plain. As I analyzed the YSlow report and specifically the HTTP connections, I realized that 1MB was images, and 1MB was scripts and stylesheets. The images weren't optimized JPEGs or PNGs - and all background images were loading in separate HTTP connections instead of a CSS Sprite. Moreover, the client didn't have fast hosting bandwidth - roughly 50Mb. You might ask why front end performance is so important - I mean, end users these days have tons of bandwidth and internet connections are getting faster and faster - as well as CPUs and Browsers are getting faster and faster... Well, that is true - but consider the new browser devices we're starting to adopt broadly: iPads, iPhones, Android phones, Netbooks etc. etc. - even refrigerators are now seen shipping with touchscreen browsers. These clients are not as fast, and may be more heavily impacted by poor network speeds/latency and slower processors. So, having 100 HTTP requests and 2.2MB of data to be downloaded to show a page might not be the best solution for these devices - at least I personally prefer getting the information vs. seeing a fancy page when I use any of these devices. Another reason to strive for better front-end performance is that we should not become lazy just because hardware and networks increase in performance - we should always optimize performance and think about the end user experience - and this is not always done on the server.  
Categories: Web Development
Tags: Sitecore;