Feb 24, 2016
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.
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.
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
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 https://www.nuget.org/packages/WebMarkupMin.Core 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.
Thanks to Sitecore’s multi-site capability, creating a dedicated hostname for media is a few moments work in the Sites configuration section.
- 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.
Although not available to Sitecore developers until Windows Server 2016 is released, architectural considerations are worth investigating and testing now:
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 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?
We chose to use the “srcset” solution, coupled with https://github.com/scottjehl/picturefill 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.
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 email@example.com.