High performing web pages are essential in providing a great experience to your users. In fact, I would say they are a requirement as our attention span continues to get smaller and our demand for instant gratification increases. In addition, the search giants, Google and Bing, are measuring how well your pages perform and considering that in their ranking algorithms.
We should always be looking to optimize our pages for the best load time possible. In this post, I will cover five specific things you can do to help improve page performance in Kentico.
1-Use Short IDs for Web Parts and Web Part Zones
When a Kentico web part is rendered as HTML, it is created with an ID parameter. This ID parameter is not only the ID value of the web part but a concatenation of that ID, the ID of the parent controls and a few other default characters. This is the native behavior when ASP.NET controls are rendered to HTML.
Each character adds to the total size of the page request and the larger the size, the longer it takes to process the page. Keeping your IDs short and sweet will help reduce any unnecessary bloat and will keep the request size to a minimum thus making the page faster to load. Trimming a few characters here and there likely won't make a huge impact on an existing site but if you optimize all of your IDs you may be able to trim a couple KBs. Alternatively, if you implement this as a best practice from the beginning, you will be starting from an optimized state.
What is the right size? I try to keep mine to 1-2 characters. A lot of developers will try to make the ID meaningful so that it is easily determined what the control is. This approach has a valid argument in other areas, but in the case of Kentico portal development, there is a name field which is suited for the just that purpose and does not impact the weight of the page.
2-Disable View State and Macros on Web Parts
Every web part has options to disable view state and macros, but by default, these are not checked. View state is used by ASP.NET to preserve specific values when a page is reloaded due to an event like clicking a button. We won't go into all of the details about that in this post, though. The important thing is that for the majority of your web parts you will not need view state and you should, therefore, disable it. View state is stored as base64-encoded strings in the HTML and if you leave your web parts set to use view state when it is not needed you are adding additional weight to the page and the heavier (or larger) the page is, the longer it takes to process.
Macro resolution is a powerful feature but is most likely one that you won't need on every web part. If you have a web part that you are not using any macros in you should disable to processing of macros. This will not reduce page weight but will improve processing time on the server as the control will not need to look for macros in the control values.
If you are not 100% sure whether you need view state or to process macros the best bet is simply to test. Turn those features off and test your page to ensure you are getting the correct output and functionality. If you are, then you know those are not needed but if anything stops working correctly or you are not getting the same results as when the features are enabled you probably need to leave them enabled. Test each one individually in that case though to determine whether you need only view state or macros as you might not need both.
3-Be Specific with Columns
A very common aspect of any web page in Kentico is the use of data bound controls. These controls can be repeaters, grids, data lists and more. They serve the purpose of getting specific data from the database to output on the page in a specific manner. However, they all have an often overlooked property that sets the columns for the control.
The columns property on these controls is used to set the query that returns the data. When this property is left blank, the query defaults to selecting all the columns of data and depending on what type of data you are returning this can be 70+ columns. In only the rarest of cases will you need all the columns of the data to achieve the output that you need and returning unnecessary columns means the query takes longer to execute and the data takes longer to transfer. You should identify the exact columns that you need to produce your output and enter these into the columns property on your data-bound control. This simple update is one that we have seen make a significant improvement to performance more times than not.
4-Enable Output Compression
There are a couple of settings that can be set site-wide that will improve the performance of your website. The first is enabling output compression. This setting allows the HTML output of the page to be compressed similar to zipping a file on your computer. This produces a smaller size which makes the request and processing time faster.
To enable this feature, go to the Settings application then expand System and click on Performance. It is the top setting that reads Enable output compression.
5-Enable CSS and JS Minification and Compression
This is by no means an exhaustive list of actions that you should take to improve page performance. It is a great place to start though and will give you an immediate improvement with minimal effort. If you are not sure how well your pages perform, I recommend using tools like Google's PageSpeed Insights
and Pingdom's Website Speed Test
. These tools will measure the overall performance of your pages as well as give you recommendations on how to make improvements.
How well do your pages perform? Have you implemented any of the above and seen improvements? I would love to hear some before and after results in the comments.