Sitecore Performance

Feb 24, 2016

The Problem

The average network load of individual web pages keeps getting bigger. Users expect more interactivity. Mobile manufacturers keep increasing the resolution of their handsets. In contrast, network bandwidth varies widely by region and device. Device CPU power and even the way the browser software parses the HTML document can have a huge impact in site performance.

The Objective

Improve page load times (perceived and actual) by optimizing all aspects of the page lifecycle, from server generation to browser rendering. While Sitecore developers have a large arsenal of tools to

keep the time-to-first-byte down via Rendering caching and Sitecore Search, there are plenty of developments in HTML land that we can leverage to maximize the use of bandwidth and browser horsepower to give users that “screen rattling” page delivery experience.

In this series we’re going to focus on a handful of interesting techniques, then discuss their implementation in Sitecore and our real-life experience with each technique.

Focus Points

Getting page times down involves more than aggressive output caching (although we’ll discuss that too). Each of the techniques here needs to be implemented. Most of them have some subtlety to them and a few can actually backfire if you overdo it.

We’re going to start with the Sitecore API and work down towards the client.

1. Efficient Item Access

Here, for the sake of completeness, it only takes one bad Sitecore Query to destroy a page’s performance. Make sure your XPath statements are concise and efficient and/or use Sitecore Search to grab Item data.

2. Caching Sitecore Renderings

Grabbing data from the API and performing logic to generate HTML takes time. Even the simplest of Renderings takes less time to retrieve from the HTML cache than it does to render it outright, because grabbing the cache allows Sitecore to skip many Rendering lifecycle events.

If it’s got a Data Source, cache it. If it’s unique to a given page, cache it. If it’s not unique to any page, cache it. If the caching rules are different from Sitecore’s stock options (data source, query string, parameter, user, etc.) use a custom cache key to manage the caching. Make sure you have broken your pages down into sublayouts, placeholders, and renderings in such a way that caching one part of a page isn’t blocked by the requirements of another part of the page. Cache, cache, cache!

3. Server-Side Image Optimization Content Authors

Don’t always upload images at the precise resolution needed for published display. It’s critical that all image URLs include the appropriate dimension-limiting tags to prevent Sitecore from accidentally serving a 10MB file on the home page.

Image resizing is not without its caveats. The CPU cost to resize a 6000px image down to 200px is not insignificant. Also, a resized image is not necessarily an optimized one, and may actually be a larger file than the original.

To get the performance needed for production websites, consider the following:

  • Adjusting the Media settings in the Sitecore Configuration Files, particularly those related to file size limits, anti-aliasing, image quality, and resizing strategies.
  • Installing a server-side image optimization tool such as Dianoga on Github

4. HTML Minification

Removing whitespace, optional end tags, empty attributes, and other human-only requirements from generated HTML documents can reduce the size of the file before it is compressed for transmission, and in some cases may improve the compression ratio of the document. As CMS developers we often see this technique used in stylesheet and JavaScript files.

By tapping into the Render Rendering Pipeline, we can ensure that all Renderings in Sitecore are minified, and stored minified in Cache. We chose to use and its associated MVC libraries to achieve a very flexible solution.

5. HTTP Compression

All browsers support compression of HTTP transmissions, which saves bandwidth. The good news is that this compression occurs at the web server level, not at the Sitecore level. The easy solution is to ensure that IIS has Dynamic Compression installed (this is a Windows Feature), and that it is enabled.


If your site is still running unencrypted, there’s a subtle trick you can use to boost the number of concurrent connections a browser will use to download your pages. It’s called Domain Sharding, and it involves giving separate hostnames for the web page, any CSS/JavaScript assets, and any media assets.

Thanks to Sitecore’s multi-site capability, creating a dedicated hostname for media is a few moments work in the Sites configuration section.

To optimize requests to static CSS/JavaScript assets further, create a discrete IIS Website for them and tweak it for performance:

  • Remove cookies by ensuring the website only supports static content.
  • Set the expiration headers for the site to something aggressive, like a month.
  • Both of these tweaks will earn you a higher YSlow rating.


If your site is running over HTTPS/TLS as Google suggests you should then you want to take a different path:Don’t do any Domain Sharding – Negotiating the HTTPS/TLS handshake takes time for each hostname that has to be negotiated – this can affect apparent page speed.

Make sure all your links use local paths to prevent needless HTTPS/TLS negotiations.

8. HTTP/2


Although not available to Sitecore developers until Windows Server 2016 is released, architectural considerations are worth investigating and testing now:


Bite-sized CSS & JavaScript files that apply to specific pages or even renderings. Set up your site to use SSL/TLS, since all browsers that implement HTTP/2 require it to be encrypted.

9. Critical Styles and Critical JavaScript

In the recent past, we separated the concerns of styling and interactivity from “semantic” markup by placing all styles and JavaScript functions in discrete files. These were referenced by the HTML document and loaded when the link was encountered by the browser.

The problem with this strategy is its effect on perceived page load time:

  • The browser will stop rendering the page while it downloads the related document. – Over a slower 3G or DSL connection this can mean an additional few seconds before the user sees the page.
  • The browser must parse the entire document, including style definitions and JavaScript functions that are not being used on page, or even on screen at the moment. – Depending on the size of the source document and the CPU power of the device, this can introduce another second or two to the perceived page load.

The solution is to look at what the user needs to see on page in order to begin utilizing the page:

  • What is the minimum loaded state for a page to be “useable” (readable, clickable)?
  • What markup, styles, and script functions are required to make the page above the fold appear to be “done loading”?
  • Based on the above constraints, style and script tags containing only the essential ingredients are added to the page, typically in the document header. Full stylesheets and script file references are placed below the fold, so they don’t halt the browser’s parsing of the relevant first-load content.

10. Critical SVG

In order to support varying pixel densities, iconography is often served via vector images. Because these files are effectively text, it is possible to embed SVG images directly into the HTML document. The complexity of the rendered image needs to be taken into account, because the browser still needs to parse the SVG, and this can take significant time. In many cases we found that removing inline SVG definitions had a positive effect on perceived page load time.

11. Right-Size Images

Sitecore developers have always been able to resize images on request, ensuring that we don’t deliver any more pixels than are strictly necessary, but how do we handle this with responsive markup, across devices that support a wide range of pixel density?

The answer is to use HTML5 responsive image tags. There are two solutions out there, the <picture/> tag, and the <img srcset=”” /> attribute. Both require some JavaScript shimming in order to be viable across most modern browsers.

We chose to use the “srcset” solution, coupled with for support in older browsers (namely IE), and also to maintain compatibility with the Sitecore Experience Editor.

What do these solutions do? They allow you to specify unique image URLs for each pixel width that the image tag needs to support. (i.e. breakpoints and retina variations). You can specify a “reasonable” default image size that will work on slower connections and older browsers.

In the case of the <picture/> tag, you can specify newer, more modern image file types with fallbacks if the browser doesn’t support them.
When supported, only the correct URL for the specified width is automatically called by the browser, allowing portrait oriented phones to get away with much smaller images than retina iPads, improving download times and perceived page load speed.

12. Lazy-Loaded Images

Image-centric pages (like home pages) can get bogged down by the browser because it will stop and load each image it encounters in markup, regardless of whether that image is actually visible. In practical terms this means that the archetypical home page slideshow can bog down perceived load time.

Lazy-loaded images aren’t new; they’ve been a standard JavaScript technique since HTML 4, but the approach matters. Moving all images to CSS and JavaScript reduces support for the Sitecore Experience Editor and has a negative impact on SEO, WCAG and ARIA. Luckily, responsive image tags are easily adapted to the task with a little JavaScript help. We used to ensure that images were only loaded when they could be seen by the user.

Time to Get to Work

We’ve discussed a 12-point list of areas to consider in order to take your Sitecore-hosted pages from “pretty good” performance to perceived page load times that rival the experience when developing a site locally.

Want to learn how Genuine's Sitecore experts can help you on your next website development project? Get in touch with us at