Blogs

Overview

Performance is a vital factor deciding the quality of a web application. Most of the performance issues happens on the front-end because developers pay much more attentions on the back-end dealing with business logic and data interaction. A front-end checklist items are created for the purpose of going over a web application to check and boost the performance before releasing it to customers.

Checklist Items

1. HTTP Requests

1.1 Reduce number of HTTP Requests
While developing, we may have multiple script and external css files and in some cases, it’s more reasonable to have multiple files instead of a single one due to the design and maintainable mechanism. This will increase the number of Http requests required to load a page because multiple requests are needed to download all of them.

As we know, browsers has a limitation of concurrent requests that it can process at the same time, especially IE6 and IE7 have a limit of two. This means the more http requests required to render the page, the slower load time is. Although all static files are cached for the second visit but it’s important to give better user experience if the first load time is fast. Therefore reducing number of HTTP requests required to load our web pages is very important for all Web UI projects.

Combining files is an efficient technique to reduce the number of HTTP requests. Therefore when delivering our web applications to users, we need to figure out a way to combine all script files into a single one and combine all external css files into a single one. With this, there are only two http requests needed to download javascript and css which is the key to faster pages.

Using CSS Sprites is also an efficient way to reduce number of HTTP Requests.

1.2 Caching

For all static components such as css, scripts, images, medias …. we need to implement a local cache by setting an expiry date or a maximum age in the HTTP headers to instruct the browser to load previously downloaded components from local disk rather than over the network. We can either custom the HTTP headers on our own or use APIs of a Web Application framework to achieve it.

Caching only affects page views only after a user has already visited our web site meaning it doesn’t bring any benefit regarding to performance for first visit. However, the benefits it brings to us are really great. It reduces a lot of HTTP requests saving a tons of loading time and bandwidth which is specially useful for web sites that have a huge number of hits daily. So always keep in mind that when you see a static component which is not cached, you need to make it being cached immediately.

1.3 Avoid Overusing HTTPS

The purpose of HTTPS protocol is securing identification of a network web server. However it increases response time because SSL connection requires several roundtrips between the browser and web server to allow them to agree on an encryption key. Overusing HTTPS can lead to performance degradation of our web pages.

Using HTTPS efficiently is a key to not also provide the security but also maintain a good shape of our web site’s performance:

  • Use HTTPS only for requests that need to secure such as ones that contain user login credentials.
  • Completely avoid using HTTPs for requests that only retrieve general information and downloading static components such as css, scripts, images…

2. Content

2.1 CSS&Script Minification

CSS&Script minification is a technique to remove all space characters such as space, tab, indent… in css and script files to reduce the total size of them hence reducing downloading time when clients request.

While creating contents of css and script files, it’s a best practice to use space characters to make code cleaner and easily maintainable. However these space characters expand the size of file unexpectedly increasing downloading time while the are really meaningless to clients. Therefore we need to figure out a mechanism to minify css and script files before delivering them to clients. We can either build our own methods or use third party tools such as JSMin or Google Minify.

2.2 Text Response Compression

Compression is a very useful method to reduce response time by reducing the size of HTTP response. By default, web servers are configured to compress a limited number of file types. However compression actually can be applied to every text response including .XML and .AXD files.

Gzip is an effective and popular compression and supported by most of web servers and browsers. It generally can reduce the response size by 60-70%. Therefore the optimal solution is always compressing our text responses by using Gzip in order to speed up our websites.

3. CSS

3.1 Use External CSS

Always use external CSS instead of inline or embedded ones. The benefits of external css are:

  • Reducing the size of HTML pages which helps to load page faster and reduce bandwidth. Besides of that, separating styling make your HTML code light and clear.
  • Formatting can be reused on multiple elements and across web pages.
  • Centralizing of entire site’s styling into one place which helps to easily maintain and modify our styles later on.

There maybe some arguments that using inline or embedded CSS is more efficient and faster because browser needs extra http requests to download the css files and time cost to look up css classes in external file. However, this cannot be a compelling reason to win again using external CSS because

  • CSS files are cached after first load and no extra http requests needed for later loads
  • The look up time of CSS engine can be reduced with a light and clear HTML DOM and robust CSS rules.

There should be some exceptions when using third party libraries such as DevExpress which we cannot control their styling mechanism but we should bear in mind that it’s important to completely avoid inline and embedded css and use external one in every cases because of overall benefits that it brings to us.

3.2 Put CSS in HEAD

Generally, we can put CSS links everywhere in a HTML page and it doesn’t change the total load-page time. However, putting CSS in HEAD of a HTML page creates a positive effect to user’s look and feel that the page seems to load faster due to progressing loading.

We are creating web applications which serve a wide range of customers with different internet connections. Slow response time is hard to avoid in special cases such as dial-up connection and based on The 3 Important Limits Rule, we need to give users visual feedback to show the progress in loading page so that they don’t leave our sites. Reality proves that putting CSS at the bottom of HTML page will end up with a blank page which users only see during the loading time.

3.3 Use CSS Sprites

CSS Sprites is a technique which combines a lot of images into one single background file and uses background-position to select the desired images. With this technique, browsers only need to download one file instead of hundreds of files for all the background images in one page. Icons on page are great candidates to apply CSS Sprites technique.

There are arguments that if we split that big background image into smaller ones, the page can load faster but that is not true.

  • As pointed out in Reducing number HTTP Requests section, the page is loaded slower with more http requests. In case of splitting one big background image into smaller ones, each of those is a separate http request and it could easily lead to hundreds of http requests if we have a tons of icons on page.
  • Combining all images into one single file will reduce the total image size hence reducing downloading time and bandwidth.

A tutorial about CSS Sprites could be found here.

3.4 Use CSS Shorthand Properties

A CSS shorthand property is a CSS style property that combines multiple properties into one instead of using a separate declaration for each individual property. This help to dramatically reduce the size of our CSS files, hence reducing the bandwidth and downloading time. Whenever a property has its shorthand declaration, we must use it.

An example about using background property, instead of declaring:


element { 
 background-color: #fff;
 background-image: url(image.gif);
 background-repeat: no-repeat;
 background-position: top left;
}

We can combine those individual properties into a shorthand one


element { 
 background: #fff url(image.gif) no-repeat top left;
}

3.5 Avoid CSS Expressions

Completely avoid using CSS expressions because:

  • It degrades rendering performance.
  • It is deprecated in Internet Explorer 8 and not supported by other browsers.

4. Script

4.1 Use External Script Files

Always use external script files instead of writing script directly in HTML pages. The reason is the same to Use external CSS section.

4.2 Put Script At the Bottom of Page

The problem when we put script on top of page is that the browser stops rendering page until the script file is finished downloading. That means users will feel a delay between the time they access the page and the time first visual elements are rendered successfully. This delay can become very long if we include heavy script files on page and some functions are executed immediately after the files are downloaded.

There are some browsers that don’t allow parallel downloads when a script file is downloaded meaning if we include scripts before CSS links in HEAD, no CSS files are concurrently downloaded until the script file is downloaded. This can cause a bad performance rendering for our web pages.

The optimal solution is putting script at the bottom of page before the closing body tags. There should be exceptions when we want to execute some functions while browser renders the page so we need to include script at the top. However we should minimized the number of these cases and bare in mind this optimal solution for faster loading page.

4.3 Eliminate Duplicate Scripts

We used to encounter this problem in several our web application projects when there were scripts included twice or three times in one page. This is really bad because:

  • It causes unnecessary HTTP requests to download duplicate files. There are some arguments that the file will be cached after first request so the second request only download the file from local disk. This is correct for most of browsers except Internet Explorer (yes always Internet Explorer :( ). In Internet Explorer, if an external script is included twice and is not cacheable, it generates two HTTP requests during page loading.
  • For complex OOP scriptings, it would be a nightmare because there should be tons of script errors after the page is finished loading.

Most of duplicate-script problems are unexpected and avoidable so bear in mind that we need to eliminate every duplicate scripts on page in order to boost our web site’s performance.

5. Images

5.1 Avoid scaling images in HTML

If you need a 50x50px image, you should create an image exactly that size instead creating a 500x500px one then scale it in HTML. Scaling image in HTML brings two bad effects:

  • Cost more bandwidth and increase downloading time unexpectedly.
  • For some old browsers, scaling image causes a uncomfortable blur effect to the viewers.

Except that we use a third party library and we don’t have control over the its images , scaling image in HTML should be avoided completely.

5.2 Avoid using images to display text

Using images to display text increases the load times of our web pages because more images mean a heavier web page. For most of the case, CSS can help us in styling the text without embedding it into an image. Except the case we apply special visual effect to text, using images to display text must be completely avoided.

6. Cookie

Recude Cookie Size

When we want to optimize our web page, one thing we should care is cookie size. We may not pay much attention about this detail since today users have a hi-speed connection so it only costs extra hundreds of miliseconds for cookie downloading. However, with a dial-up user, that extra time can be 10 times greater and we need to consider this case seriously.

  1. “When the Cookie Crumbles” is a very useful article mentioning Cookie factor in web performance optimization where a list of cookie sizes and their corresponding time was illustrate clearly. From there we can easily see the bigger cookie size is, the response time is longer. Moreover, there are size limits of a cookie varying among browsers which we should be aware.

The key takeaway here is we need to reduce the size of cookie as much as possible and the ideal value is no more than 500 bytes per cookie.