Front-End Performance
All my previous talks about ASP.Net performance were concentrating on server side enhancements, today I will focus on front-end performance as I will discuss some important Tips and Tricks for faster web page downloading. Before going through, I just want to point to a very important statistics which states that less than 10-20% of the total end-user response time is spent getting the HTML document to the browser and the other 80-90% is getting the page resources. This performance golden rule is made by Steve Souders in his book "High Performance Web Sites", he came to this conclusion by analyzing the top 10 internet websites. To emphasis this statistics let’s take a look at the ASP.Net website:
As you can see from the above graph that less than 10% of the response time is spent on HTML and the others for page resources. With Internet Explorer 8, the maximum number of concurrent connections from a single host process connecting via broadband to a single server has been increased to 6. In Internet Explorer 7 and earlier, the maximum number of concurrent connections per host process to a single server via HTTP 1.1 is 2. For HTTP 1.0, the limit is 4, though HTTP 1.1 connections are far more common today. Note that the maximum number of concurrent connections from a single host process connecting through dial-up (for instance, with a modem over a telephone line) to a single server remains the same as for Internet Explorer 7 and earlier, by this limitation you may face lateness if your website contains a lot of resources.
The following table summarizes the maximum number of concurrent connections based on the version of Internet Explorer running on the host, the host's connection speed, and the server's supported protocol version :
|
Version
|
HTTP 1.0 server (broadband connection) |
HTTP 1.1 server (broadband connection) |
HTTP 1.0 server (dial-up connection) |
HTTP 1.1 server (dial-up connection) |
| Internet Explorer 7 and earlier |
4 |
2 |
4 |
2 |
| Internet Explorer 8 |
6 |
6 |
4 |
2 |
Let’s now dive into front-end performance tips and tricks :
- Performance Tip #1 (View State) :
A Web application is stateless, View state is the method that the ASP.NET page framework uses by default to preserve page and control values between round trips, so you need to disable View State whenever possible especially when your page is just displaying data. You can disable View State by setting the page directive as follows :
<%@ Page EnableViewState="false" %>
For example Grid View generates massive view state, so it is better to replace it by a Repeater in case of data presentation. It is important to mention that a web page developer can disable view state for the page or for an individual control for performance. However, control state cannot be disabled. Control state is designed for storing a control's essential data (such as a pager control's page number) that must be available on postback to enable the control to function even when view state has been disabled. Microsoft recommends to use control state only for small amounts of critical data that are essential for the control across postbacks. Do not use control state as an alternative to view state.
Also you have to care about the naming convention of your controls as this will extremely affect the View State especially for hierarchal controls like Grid View, also it will affect the generated HTML code as each HTML control will have a ID of “GridView1_ctl02_ctl00” and name like “GridView1$ctl02$ctl00” which will increase the size of the generated user response.
- Performance Tip #2 (Page Scripts) :
Client-side scripting generally refers to the class of computer programs on the web that are executed client-side, by the user's web browser, instead of server-side (on the web server). All web developers depend on scripts to extended application accessibility, but you should always use external script files to produces faster pages because the script files are cached by the browser and this will minimize the amount of generated HTML code.
The dilemma with the external page scripts is that they block parallel resources downloading, as stated before that HTTP 1.1 specifications suggests that client browsers should download at most 2 resources in parallel per domain. For images and style sheets this standard is fine as you can download more than two images in parallel but scripts will block any additional page processing, while a script is downloading the browser won’t start any other resource downloads even for a different domain.
It is very important to place your scripts at the bottom of the page to prevent blank white screen and delayed downloads.
You can place your scripts at the bottom easily by using Ajax Script Manager as it has a property “LoadScriptsBeforeUI” by default this property is set to true, you can set it to false to enforce loading script after loading other resources as follows:
<asp:ScriptManager ID="MainScriptManager" runat="server" LoadScriptsBeforeUI="false">
<Scripts>
<asp:ScriptReference Path="jquery-1.3.2.js" />
</Scripts>
</asp:ScriptManager>
Another thing you should do before putting your script to production is to minify them to eliminate all white spaces [spaces, tabs, …] and comments. Studies showed that minifying script reduces the production script by 21% of the original one.
There is a very popular tool that can be used to minify JavaScript files which can be found here or you can use the one provided by Microsoft for AJAX that can be found here
One last thing I want to spot on; if your page contains multiple external script files then you need to combine them together in order to avoid the latency involved while loading each script on a separate connection. ASP.net 3.5 service pack 1 has a nice features and one of them allows you to do script combining, this can be done by using AJAX Script Manager that takes multiple script files and ships them to the client as one script file. The following snippet shows how to combine JavaScript files :
<asp:ScriptManager ID="combineScriptManager" runat="server" LoadScriptsBeforeUI="false">
<CompositeScript>
<Scripts>
<asp:ScriptReference Path="~/Scripts/JScript.js" />
<asp:ScriptReference Path="~/Scripts/JScript2.js" />
</Scripts>
</CompositeScript>
</asp:ScriptManager>
There is a very useful control that can be used to view which scripts that should be combined together “Script Reference Profiler”. The Script Reference Profiler is a helper control which provides information on the client-side scripts used within an ASP.NET AJAX page. These references can then be copied into a CompositeScript tag when using ASP.NET AJAX script combining to improve the performance of your ASP.NET AJAX applications by combining the multiple script requests into a single request. You can download this helper control here.
I included a web project that demonstrate all the tips discussed here ScriptsDemo.zip (13.03 kb)
Performance Tip #3 (Style Sheet) :
CSS is designed primarily to enable the separation of document content (written in HTML or a similar markup language) from document presentation, including elements such as the layout, colors, and fonts. This separation can improve content accessibility, provide more flexibility and control in the specification of presentation characteristics, enable multiple pages to share formatting, and reduce complexity and repetition in the structural content.
In order to optimize your web page rendering performance, you should use external CSS files as they will be cached by the client browser and it is better to put them in the Head section of your page as this will permit page progressive rendering as we want our browser to display whatever content it has as soon as possible.
The second thing that you must take care of is CSS expressions which is a powerful way to set CSS properties dynamically (IE feature only), you can do CSS expressions by using JavaScript as follows:
.cc
{
width : expression( Math.random() * 100);
background-color: Yellow;
}
The problem with CSS expression is that they are evaluated frequently than expected as they are evaluated when the page is rendered, resized, scrolled and with every mouse move. So you may have 100,000 evaluation with the mouse movement events which will degrade your page performance. If you need to set CSS properties dynamically then use explicit value when the expression is evaluated the first time or use page event handlers as an alternative of CSS expressions.
Another important rule regarding CSS is that you should minify them before putting them into production as this will help saving server bandwidth and make the web page loading faster. Studies showed that minified CSS files are less than the original ones by 25 %.The YUI tool can be used to minify CSS files, this tool can be found here.
The last rule that I want to talk about is “CSS Sprites”; CSS sprites allow you to create a single file that contains all the images laid out in a grid, meaning only a single image and only a single server call, with roughly the same file size because the empty space is compressed. In that file, you will place all individual "sprites" that make up your interface separated by enough space that they don’t start running over each other. You’ll then set the background position (using negative values to move the background up) and include enough space around each sprite so that only it appears in the background of the element, effectively masking the rest of the sprite images.
There are a lot of tools that gives you Sprites on the fly, I prefer to use Spritegen as it takes a group of images and generates a single image along with the sprite CSS. I included a web project that demonstrates Sprites and expressions StyleSheets.zip (848.11 kb). The following table provides a comparison between sprites and non sprite sites according to demo project:
|
|
Sprites
|
Non Sprites
|
|
HTTP Connections
|
1
|
8
|
|
Size
|
370 KB
|
500 KB
|
As you can see that by using sprites we saved 7 connections and image size which will provide better performance for our server bandwidth and faster page downloading. Sprites also can be used to provide themes to your website to allow better design.
It is important to mention that you must verify your images size before putting them into production, studies showed that most website developers use image size greater than required by the website design. You can use Developer Tools to generate a report for images size and resize them to save server bandwidth and client browser cache.
Be the first to rate this post
- Currently 0/5 Stars.
- 1
- 2
- 3
- 4
- 5