When developing websites, a lot of emphasis is put on performance. How long users wait to see a page can have a big impact on how well your site achieves your business goals.
A surprisingly small increase in the time for a page to load can cause people to give up and go elsewhere. In turn, that reduces those all-important conversion rate statistics for turning visitors into customers.
Recently, I spoke to the Manchester Sitecore user group about some of the tools and processes that developers can use to keep their Sitecore websites running fast. That discussion was fairly technical, (you can read a summary of it here) but the key messages are important for content editing and management staff to understand as well.
What should everyone in your project team understand about web performance?
Fundamentally, people browsing the internet have a fairly short attention span. I’m sure we’ve all been in the situation where we click a link in Google and find ourselves waiting a couple of seconds for the page to appear. The urge to click “back” and open the next link on the results page is pretty strong – and this isn’t just anecdotal.
Measurements taken by companies involved in content caching, stats and optimisation confirm this for us. The precise numbers vary a bit depending on what’s being measured, but one commonly cited stat from Akami suggests that: ‘…by the time users have waited 3 seconds, 79% of them have clicked away. That’s a lot of potential customers lost.’
What can we do to avoid losing users with slow sites?
At a high level, there are three concepts you can control that affect your users’ perception of your site’s speed: (I’m ignoring network performance here as that is often out of your direct control)
- Server processing time. That’s the length of time it takes your web servers to translate the user’s request for a page, into the set of data to send back to them. For websites built on Sitecore this is the time it takes your Content Deployment server to render the content and layout for your pages. To some extent, that’s affected by the speed of your physical servers, but the custom code your site runs and the content it processes has a significant effect here.
- Volume of data that needs to be downloaded to a user’s web browser. The amount of HTML you’re sending out, and the size of your images, CSS files and client-side script are important here. While network speeds will clearly affect this, you can control the size of the data that needs to be sent. Any work you do to optimise this will have benefits no matter what’s going on with the internet.
- How fast the user’s web browser can turn the HTML and other downloaded files into a visible web page. This rendering time is affected by file sizes, but it’s also governed by the complexity of the job you’re asking the browser to do. Complex client-side scripts or hard to render styling can make a significant difference here.
Sitecore performance isn’t just for developers!
Sitecore performance affects everyone involved with a project, not just developers. Do you want the experts at Kagool to help you improve the performance of your next Sitecore project? We’d love to chat. Get in touch with us today for a free demo or audit. For more detail, read on!
With those areas in mind, what tools can our project teams make use of to maintain a fast site speed?
As noted above, the sever-side performance is governed by how fast Sitecore can assemble your page and how fast your custom code runs. But both of those are affected by raw server performance.
Windows performance monitor
At its simplest, Windows tools like Process Monitor can record detailed information about how a machine is performing. You specify a set of things you want to examine, such as CPU load, memory usage or network traffic, and it will record data in real-time and graph it for you. This is good for showing trends over time, and allowing you to export raw measurements for other analysis.
You can get a very quick idea of how hard a server is working from tools like this. Trends on these graphs can show how requesting certain web pages affects servers, or it can show how hardware is coping with overall levels of load. As a rule of thumb, the higher the graphs are, or the bigger the spikes you see, the harder your infrastructure is working.
(If you’re working with Platform as a Service infrastructure, the monitoring tools are a bit different here, but things like Application Insights on Azure can be used to provide similar data)
What these graphs don’t tell you a lot about, is the underlying cause of the load you see. To look more specifically at why a server is working hard, you need more specific measuring tools.
Sitecore “Debug” view
Sitecore provides a really helpful tool built into Experience Editor. The “Debug” view available to editors will give detailed statistics on how hard Sitecore is working to render a page.
It breaks the data down in two key ways:
- How many content items are being accessed to render your web page. While you can get great personalisation benefits from having lots of components with data source items on your pages, each item read does have some performance cost. This tool can show you how many items each component reads – and crucially whether Sitecore read them from it’s in-memory cache or had to wait for the database server to send them back from disk.
- How long each component of your page took to execute. This includes the visible components in your UI as well as the invisible stuff happening in the background. For example, when Sitecore is running pipelines to work out what language to render content in or to send data to analytics. These numbers are shown in terms of absolute time and relative to the rest of the page. This gives you interesting ways of working out which components your developers need to focus some performance love on.A cache miss is a big performance penalty, so this can give you really important data about whether your caches are big enough, or if some components are reading lots of items
Visual studio
Once you’ve identified components that take a long time, your developers will need a bit more data on what aspects of them are taking a long time. Sitecore doesn’t examine statistics to this level, but code profiling tools can do this for you. Whilst many are available, Visual Studio (which most of your developers are probably using anyway) includes some really helpful tools.
As well as being able to monitor trends in memory / processor use for your code, it can also tell you down to the individual-line level which bits of your code are run the most, and which take the longest time. This can give developers really detailed information about where they should focus their efforts for making pages run faster.
One of the nice features about this tool is that while the data it collects is very detailed and technical, it is really well integrated with the overall code editing experience in Visual Studio. Clicking on a statistic that looks high can take you immediately to the piece of code that is responsible for it.
Browser “developer tools”
But as I mentioned before, how your server deals with running your website code is only part of the battle. A successful project will think about what happens on your user’s web browser when it tries to show the page onscreen.
Unsurprisingly there’s a whole other set of tools here. The web browsers your site targets can give you a wealth of information here. All the modern browsers include a “developer tools” feature which can give you detailed statistics on what the browser does to render your page:
Graphs like this can show you the effort expended on turning HTML, CSS and Javascript downloaded from your servers into a visible page. This lets your front-end experts spot where there are options to simplify or adjust the page to make things happen faster. But browsers can also track the work done to download the web page across the network.
You can see file sizes, download times and things like “how long did the browser wait before it had the free time to download this asset”. These statistics can help developers make more effective use of techniques like:
- Sitecore’s ability to resize images – if your server reduces the dimensions of an image to fit the space it’s being drawn in; it can make the download time much smaller.
- “Bundling” – a technique where lots of small CSS or JavaScript files are packed together as one larger file. This reduces the number of files being sent across the network, and it’s faster to send one big file than three smaller ones.
- “Sprite sheets” – Similar to bundling, this allows multiple images to be compiled together and sent as a single file.
- “Minification” and Compression – Stripping out comments and white-space that are just there for developers, and then using techniques similar to “zip files” to the amount of data that needs to be sent from the server to the browser.
- Picking the right image format for pictures – generally speaking photographs work best as “.jpg” files, and drawings will be smallest as “.png” files. Saving a photograph as “.png” can have a big effect on how much data is downloaded.
That’s a lot of stuff – how does this fit into a project plan?
Historically, with waterfall-style projects, this sort of testing would usually be scheduled towards the end of the project, as part of the quality and user acceptance phases of work.
This isn’t a great idea. The later in a project that you discover a performance challenge, the more difficult and expensive it is to fix.
Ideally you need to spot these challenges early, and fix them as soon as they crop up. The move to more agile project management approaches in recent years has helped a bit – since in the worst case, these checks should now be scheduled at the end of sprints, to examine the output of that sprint.
Performance should be checked day-to-day
But my presentation to the Manchester user group argued that this isn’t really enough. You’re still allowing developers to finish a task and move on to something else before checking these issues. I suggested that since these are all tools that are available during your development process, these tools and tasks are things that should be done day-to-day as part of the general process of writing code.
Modern developers talk in terms of “make it work, then make it pretty” when they construct the logic of their code. I’d argue that we should all be thinking in terms of “make it work, then make it fast and pretty” to make performance a core part of our projects.
Sitecore performance affects everyone involved on a project
While some of the data from the tools above is pretty technical, the overall trends shown by Sitecore’s debug statistics, or a web browser’s profiling tools are fairly easy to grasp. That means content editors can also see that a component or page takes much longer than others, and it doesn’t matter if they don’t understand why. After all, you don’t need to understand the code to raise a bug in how a page behaves – so why should you need to understand it to raise a performance issue?
So, a key step of our journey towards increasing customers and their satisfaction with our websites starts from having the whole project team thinking about performance.
Looking for help with your next Sitecore project? We’d love to hear from you. Get in touch with our Sitecore experts today for a free demo or audit.
