Kentico Website Speed Optimisation Basics

In July 2015, Kentico held User Group meetings in Melbourne and Sydney. I presented at both of these events in my capacity as Kentico MVP. The topic I chose was one we discuss extremely frequently with partners and clients alike: speed!

The following post does not go into great detail, but is rather an introduction to the vast world of optimisation techniques and possibilities, based on the presentation from the User Group meetings. It goes over some basics, or quick wins, and points to a few more advanced techniques which I'll dive into in more detail in later posts.

A fast website is no longer a "nice to have"

Why is website speed important? So many reasons:

• Google now takes speed into account when ranking sites.
• Time to first interaction greatly affects user experience.
• Growing numbers of mobile visitors are using shaky/inconsistent connections.
• Faster page load leads to lower CPU usage, which means fewer servers are required, and more money in your pocket!

What affects site speed?

Arguably the two most common site speed testing tools are Google’s PageSpeed Insights, and Yahoo’s YSlow.

PageSpeed Insights checks these factors:

• Browser caching*
• Render-blocking JS and CSS
• Optimize images*
• Prioritize visible content
• Enable compression*
• Minify JavaScript*
• Minify CSS*
• Reduce server response time*
• Avoid landing page redirects*
• Minify HTML*

As you can see, there are all sorts of things that need to be finely tuned to get your site performing extremely well. But the good news is Kentico can address almost all of these - the ones I’ve asterisked in the list above.

Of course, there are other factors affecting site speed that aren’t as easy for a Google robot to sniff out or just didn’t make PageSpeed’s list, such as:

• Number of HTTP requests
• Quality of user’s Internet connection
• Use of a CDN (Content Delivery Network)
• Multiple and/or cookieless domains
• JavaScript plugins (especially social)
• Hosting environment (servers)
• Traffic, including time of day/year

A common misconception

We occasionally hear statements such as this (usually from developers experienced in other platforms and unfamiliar with Kentico):

“Kentico’s portal method makes sites slower than other systems that use pure .NET code.”

My response usually:

• Both methods require work to be done to optimise for speed - raw code with no optimisation will perform terribly.
• Good/necessary optimisation usually results in improvements in orders of magnitude, not slight percentage gains.
• Performance tuning is actually easier in Portal than custom code in other systems! It’s these settings available in the Portal Method (Design tab) that we’ll be looking at in more detail in this post.

Picking your battles

I’ve mentioned a lot of different potential issues that could affect your site speed. But how do you know which ones you should be looking at?

I’d recommend starting by testing the speed of individual, key pages, such as your home page and key landing pages (product listings are classic culprits). A great way to pinpoint the issue is to use (or get your developer to use) the Chrome Dev Tools, Firebug, IE F12 developer tools, or a similar tool, so see a timeline of all the different parts of the page loading.

This allows you to see if the issue is your actual page taking a long time to load (as in the example above), or some other issue such as large images, or a social networking JavaScript plugin.

Reduce Server Response Time

This is one of the recommendations from PageSpeed Insights, and the one we’ll be talking about tackling in this post. If you see that the biggest issue is that your browser is “Waiting (TTFB)” for your page, then we need to optimise the way Kentico is loading and delivering the page.

Kentico offers a whole bunch of ways to do this - far more than I can cover in this post. The key methods are:

• ViewState
• Partial Caching
• Output Caching
• “Columns” property
• Shared datasources
• Custom code caching

Addressing these can have a dramatic effect on your site’s performance, and be much more effective than upgrading your server hardware.

Web Part “Performance” properties

In this post, I’ll just go through the easiest ones which you can and should tackle in EVERY website you have on Kentico, which were asterisked in the list above.

You (or your developer) should review and configure these settings every single time you add a web part to a template.

• ViewState - can usually be disabled, unless it’s required for things like forms.
• Partial Caching - can almost always be switched on (a number entered).
• Partial cache dependencies - these are complex but very powerful, enabling you to configure caching on all of your web parts, but still get the latest data as soon as it is updated.

For the non-technical readers: when caching is configured, Kentico will essentially keep the content it looked up in your database for that web part in previous page loads in memory, and not bother to go back and load it out of the database again, but just serve exactly what it served last time, for as long as you have the cache minutes configured. This saves a lot of time searching through your database for data, and can drastically improve load time. But if incorrectly configured, it can mean that updated content may not display on your site until the cache expires (i.e. the number of minutes you configured has passed).

(Apologies to the techies out there cringing at my very basic translation of how caching works!)

There are good reasons for the defaults (viewstate on and partial caching off), but you can and should change them when appropriate!

The Silver Bullet: Output Cache

Warning: proceed with caution!

Output caching does what partial caching does for individual web parts, except it does it for the entire page. This means for the number of minutes you configure, Kentico will not bother to look up any of the content for the page in the database, and just immediately server whatever it served last time.

This gives you amazing server-side performance, at a cost. If you have a static home page or landing page, it can have a dramatic effect. If your page has any dynamic content in it that can’t be cached/delayed for a few minutes, do not use it.

Note that it is possible to configure dependencies and use advanced features such as substitutions to use partial caching but still enable updated/dynamic data to come through, but that is well and truly beyond the scope of this post.

And so much more!

I really have only scratched the surface today. Huge gains can be made with these simple performance tweaks within Kentico, but with effort, Kentico can and will perform just as well as any system out there.