Web page performance: Removing the white flicker delay

Feature:

Web page performance: Removing the white flicker delay

By Nirupa Katare

TheServerSide.com

Looking for ways to improve the performance of web page rendering and removal of the white flicker that often occurs when a web page loads? There are many tweaks and tips commonly talked about regarding web page development –  from design  to the final deployment of an application. However, most of the end user's time is spent on the front end, hence from the user's perspective the most promising area to look for improvement is with the web page and how speedily the web pages loads when user clicks on a link or URL.

Amongst the various problems with web page loading, white flicker is considered to be one of the common issues which occurs during page access, loading, reloading, and traversing Internet browsers. The white flicker occurs for various reasons including the browser trying to render the page before the style sheet has finished loading, JavaScript issues and other rendering faults. Browsers will always wait until everything (beyond images) has finished downloading before rendering.

We will briefly go through below mentioned some of the best practices for web developers which can help in making the web pages faster and reduce the white flicker while rendering the web pages:

  • Enable Compression on the Tomcat server
  • Implement Caching Filter
  • Dividing the pages in Divs
  • Including the Java Scripts at the end of the page
  • Setting the Background color on Body of java server pages
  • Put Style Sheets at the top in java server pages
  • Remove duplicate scripts in java server pages
  • Ensure that pages have only one DOCTYPE, HTML, Head and Body tags
  • Use GET in place of POST for fetching data requests

 

 

Introduction

  

 

For any web designer the foremost thing to keep in mind is their applications end users should have a wonderful experience that allows them to navigate through the web pages without any hitches. End users’ deals with web pages and they are least bothered about how it functions behind the scene. So a web designer has to take care of so many things to enhance the users experience, need to take care that user doesn’t get irritated when he browses through the website, reason being it is too slow to load the page or any white flicker occurs when he navigates to different links.

 

In this article I have focused on one of the common problems ‘White Flicker’, this occurs during page accessing, loading, reloading, and traversing on internet browsers. The tips that I recommend in this article are based on my personal experiences and if one follows these best practices , in addition to removal of white flicker, it proves  useful in enhancing the performance of loading web pages as well.

 

 

White Flicker

 

‘White Flicker’ is basically a kind of ‘flash/flicker’ that occurs when transiting between two web pages. It occurs during web page load in IE, when one clicks on a link, or menu which triggers to get the screen reload/refresh, during this refresh/reload of the screen.

 

Web pages loads slowly and gives a white flicker because many a times the browser is tied up with processing the components in the page as : images, style sheets, scripts, Flash etc. Before rendering any page, browsers will always wait until everything (beyond images) has finished downloading.

 

Listed below are some best practices which can help in reducing the white flicker/blinking and enhance the performance of web pages.

 

  1. Enable Compression on the Tomcat server:

Enabling the ‘compression on’ for large contents of the application can help on improving the performance. If we use Tomcat server to serve remote clients over the internet we can significantly improve page loading time, by enabling ‘content Compression’. Content become compressed when it transports over the internet. All modern browsers support HTTP/1.1 GZIP compression and if your server also enables it, the page load time decreases dramatically. They just are popping out in a browser, like if they were served from a local server.

 

 

To enable the compression ‘on’ the Tomcat server make the below entry in the ‘server.xml’ which is placed in the ‘conf’ folder of the server. 

 

 
  Text Box: Entry without Compression: <Connector port="8080" protocol="HTTP/1.1” connectionTimeout="20000" redirectPort="8443" /> After Enabling Compression: <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" compression="on" compressionMinSize="1024" noCompressionUserAgents="gozilla, traviata" compressableMimeType="text/javascript, application/x- javascript, application/javascript, text/html,text/css,text/plain, image/png,image/gif"/>


 

 *Please Note: Skip Compression for small files in Tomcat.

It is good to skip compressing too small files - the Compression overhead will take away all benefits and can result in even bigger file, instead.

 

  1. Implement Caching Filter:

Filters are capable enough for manipulating a request or response (or both) that is sent to a web application. Filters provide this functionality in a method that won't affect servlet and JSPs being used by the web application unless that is the desired effect.  To implement the caching on the big files, adding a filter in the code can help out.  An example filter is given below:

 

 
  Text Box: Eg Filter: ExampleFilter.java package com.test.example.util; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class ExampleFilter implements Filter { FilterConfig fc; String cacheControl; public static final String HEAD_CACHE_CONTROL="Cache-Control"; public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException { HttpServletResponse response =(HttpServletResponse) res; // set the provided HTTP response parameters response.setHeader(HEAD_CACHE_CONTROL,cacheControl); // pass the request/response on chain.doFilter(req, response); } public void init(FilterConfig filterConfig) { this.fc = filterConfig; cacheControl=filterConfig.getInitParameter(HEAD_CACHE_CONTROL); } public void destroy() { this.fc = null; } }

 


 

 After adding this filter in the code, the corresponding entries are required in ‘web.xml’ for Web Client. The entries than need to be made in ‘web.xml’ are mentioned below:

 

 
  Text Box: <filter> <filter-name> ExampleFilter</filter-name> <filter-class>com.test.example.util.ExampleFilter </filter-class> <init-param> <param-name>Cache-Control</param-name> <param-value>max-age=5184000</param-value> </init-param> </filter>

 

 In addition to the above entries we also make entries for the files which need to be cached. This is done by adding various extensions of the files which need to be cached.

 We make below entries in web.xml:Text Box: <filter-mapping><filter-name> ExampleFilter</filter-name><url-pattern>*.css</url-pattern></filter-mapping> <filter-mapping><filter-name> ExampleFilter</filter-name><url-pattern>*.js</url-pattern></filter-mapping> <filter-mapping><filter-name> ExampleFilter</filter-name><url-pattern>/images/*</url-pattern></filter-mapping>

 

  By making the above filter mapping, the css, js and files at the location /images/ will be filtered for caching.

Similarly, we can enable caching for WebServices. Making a similar filter & making similar kind of entries in web.xml of the Web Service. The Filter mapping will be done for the Servlet on web service side.

Eg:

<filter-mapping>

<filter-name> ExampleFilter</filter-name>

<servlet-name>ContentServlet</servlet-name>

</filter-mapping>

 

  1. Changes on the Client side (JSPs):
  2. Dividing the JSPs in Divs:

The JSP coding also plays a vital role in the look and feel of the application. Some basic fundamentals should always be followed. While coding the jsp page, the basic page structure should be like; it should be grouped into five separate divs, and each of these div's should be given a unique ID selector. The divs are labeled; "container" (wrapped around the entire page's content), "top" (for the top banner), "leftnav" (for the smaller, left column), "content" (for the main content) and "footer" (for the footer across the bottom of the page).

css code that can be used for aligning these divs is as below:

 

 
  Text Box: #container { width: 90%; margin: 10px auto; background-color: #fff; color: #333; border: 1px solid gray; line-height: 130%; } #top { padding: .5em; background-color: #ddd; border-bottom: 1px solid gray; } #leftnav { float: left; width: 160px; margin: 0; padding: 1em; } #content { margin-left: 200px; border-left: 1px solid gray; padding: 1em; } #footer { clear: both; margin: 0; padding: .5em; color: #333; background-color: #ddd; border-top: 1px solid gray; }

 
 

 

 

  1. Including the JavaScripts Judiciously in JSPs:

 Parallel downloads blocking is the main problem caused by the scripts. The HTTP/1.1 specification suggests that browsers download no more than two components in parallel per hostname. If you serve your images from multiple hostnames, you can get more than two downloads to occur in parallel. While a script is downloading, however, the browser won't start any other downloads, even on different hostnames. So it’s suggested to include the scripts downloading judiciously in the application code.

 

Location of JavaScript’s included in jsp do matter in the application’s performance. It is always good to include the JavaScripts after the </HTML> tags in the jsps, unless it’s not required at the time of loading JSP. Practicing this will increase the performance of the screen loading; and JavaScripts will be loaded at the end.

 

Eg.  Such script tags as below should be added at the end of JSP code.

 

 <SCRIPT language=Javascript src="javascripts/myStyle_Common.js"></SCRIPT>

 

  1. Setting the Background color on Body of JSPs:

It is advisable to set the background-color similar to the color of the whole application in the body tag itself. By default the color is set to white, so while switching through the various screens of the application, there will be white blinking in those cases where the background color of the whole application is other than white.

Eg. In a web application the background color is set as Black. So the below code is used to set the bgcolor in all the JSPs.  

<body bgcolor="black" >

  1. Put StyleSheets at the top in JSPs:

The stylesheets used in the jsps do help in perceiving the application’s faster performance to the user. If the stylesheets are moved to the document HEAD makes pages appear to be loading faster. This is because putting stylesheets in the HEAD allows the page to render progressively. In our case the HTML page is the progress indicator When the browser loads the page progressively the header, the navigation bar, the logo at the top, etc. all serve as visual feedback for the user who is waiting for the page. This helps in improving the overall user experience about the application.

  1. Remove duplicate scripts in JSPs:

The performance of the application can also be reduced by including the same JavaScripts twice in the jsp. In Internet Explorer, if an external script is included twice and is not cacheable, it generates two HTTP requests during page loading. Even if the script is cacheable, extra HTTP requests occur when the user reloads the page this again will be a cause for the performance hit of the application. As a caution we should remove the duplicate scripts in the jsps.

  1. Ensure that JSP has only one  DOCTYPE, HTML, Head & Body tags:

It should be ensured that the JSP contains only one DOCTYPE, HTML, Head & Body tags. Many times it happens that the jsps we include in another jsp contains all these tags and hence these tags appear more than once. Multiple occurrences of these tags can also hamper the page loading performances. So such multiple tags should be avoided in the jsp codes.

  1. Use GET in place of Post for fetching data requests:

The decision for using POST or GET method for sending data should be done judiciously. The performance of the application also depends on the proper use of these methods. The POST is implemented in the browsers as a two-step process: sending the headers first, then sending data. And on the other hand the GET does it in one step. So it's best to use GET, which only takes one TCP packet to send (unless you have a lot of cookies). The maximum URL length in IE is 2K, so if you send more than 2K data you might not be able to use GET.

Reference(s)

  1. http://www.webmasterworld.com/apache/3091828.htm
  2. http://www.javafaq.nu/java-article1178.html     
  3. http://onjava.com/pub/a/onjava/2003/11/19/filters.html

 

 

Nirupa Katare has been working in J2EE field and has a close to 7 years of industry experience in core development. She is currently working with Infosys Limited as a Technology Lead and has extensive experience working in web technologies. She is interested in technology writing and has been documenting her learning on different technology areas, in form of technical write-ups on various topics.

18 Oct 2012

Related Content

Related Resources