Client Side Performance In Web Applications


Published on

Client-side optimization for web applications is an important issue that must be considered by any web developer. This paper presents some approaches regarding web applications client-side optimization. We
discuss the optimization techniques that refer to CSS, JavaScript and HTML. We also we o er a preview on various tools that can be used for pro ling, debugging and optimizing, such as Firebug. The final part of the paper sums some conclusions regarding client-side optimization.

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Client Side Performance In Web Applications

  1. 1. A study on client-side web applications performance Ungureanu Vlad-Costel1 and Honciuc Irina1 Computer Science Faculty, ”Al. I. Cuza” University of Iasi Software Systems Engineering specialization Abstract. Client-side optimization for web applications is an important issue that must be considered by any web developer. This paper presents some approaches regarding web applications client-side optimization. We discuss the optimization techniques that refer to CSS, JavaScript and HTML. We also we offer a preview on various tools that can be used for profiling, debugging and optimizing, such as Firebug. The final part of the paper sums some conclusions regarding client-side optimization. 1 Introduction Web applications are more and more used in our everyday life, exponentially growing in terms of users and daily access. Some applications, like YouTube or Twitter, just to name a few, pass over one billion views each day. In these conditions, the need for higher performance in web applications is obvious, but not only from the server side, but also from the client side. In order to sustain such big services, companies have many resources in terms of employees, broadband, technologies, frameworks and hardware at their dis- posal. On the other hand, the home user is not interested in the expensive resources a company can allocate for an application, but rather the performance of the application. Before we go any further, we must state that an application can benefit from two types of optimizations. First, an application can be optimized in aspects regarding the way the server will serve a request from an user (server side) and in aspects regarding the user interaction with the application (client side). Most developers will state that server side optimizations are the most impor- tant to ensure a quality service. Without being far from the truth, server side problems can make an web application unusable. Just to prove a point consider a select statement (of course running on the server) that joins six tables, each with several million rows, just to return a list of four friends to a user on Twit- ter. As extreme this may sound, the point is clear: server side optimization is mandatory. However, can a client side flaw or problem cause an application to stop re- sponding or to become unusable? The answer is ’Yes’. Imagine an Application that uses AJAX techniques to show a table with employees of a multinational corporation. The user enters the page and wants to see several hundred people
  2. 2. 2 Ungureanu Vlad-Costel and Honciuc Irina in the table, the server has no problem running such a simple query and parsing the results and the client has no problem receiving the page update contain- ing the list of people. In this situation, if the table allows row selection, this feature may become unusable, since the large content in the page can slow the JavaScript code that handles the selection. A solution for this problem is a sim- ple pagination, which simplifies the page content and allows JavaScript code to run without problems. So we can see that client side optimizations are also required in order to ensure a performant web application. 2 HTTP Requests One of the basic requirements for high web application performance is to make fewer HTTP requests. Standard requests that move the user from one page to another generate discontinuity in application usage and may lead to high load time since in each response the page must be constructed by the browser, the elements must be interpreted, the CSS must be applied and all dynamic elements must be loaded again. The major inconvenient is that the user may initiate requests that reload the page only to submit the changes to a single element. Lately almost all major web application have turned to AJAX techniques, thus relieving the user from the tiring request-response cycle of the old appli- cations. One of the most obvious examples we can name is form validation per- formed after each field is completed. Even though the advantages are remarkable, this approach is not without risks. Two situations are easily observable in the client side interaction. Considering the form validation example imagine what would happen if the validation routine would be triggered by multiple events like ”on focus” , ”on focus changed” , ”on value changed” and so on. The multitude of useless request would then be sent to the server and would most probably return the obvious result the fields are not completed correctly. Thus, a good optimization would be to limit the number of events that trigger validation requests [1] only to the required ones, for example ”on focus lost”. The other situation is when validation of a field takes too much time and the application still waits for a response. The optimization required is to treat the validation of each field in a separate request [1]. Obviously, simple validations can be grouped in a single request according to the situation. Another issue concerning HTTP request is the way the requests are sent. The most effective way is to send requests in parallel rather than in sequence [1]. One last optimization considering HTTP requests is avoiding redirections, since the number of redirects will exponential increase the time of the request due to standard operation (resolve host, open socket etc.) for each redirect.
  3. 3. A study on client-side web applications performance 3 3 JavaScript Since JavaScript is a major component of AJAX it is only natural to dis- cuss script optimizations. It’s important to add that JavaScript is run within a browser, thus on the client side. For those that really want to increase performance there are a few rules of organizing the code when using JavaScript in your application: – put JavaScript at the bottom of the page, since the HTML Rendering Engine runs before the JavaScript Virtual Machine; – JavaScript code must be external since it is downloaded the first time and then is cached for later usage. Repetitive JavaScript code is downloaded and executed each time; – logically group scripts so that they get loaded in the pages where they are needed. Avoid loading very large script files in pages where only several lines are required; – compacting the code leads to increased performance since each client will download less until it can cache a script file. Aside from the organization of the code in an application, JavaScript can still be optimized though various techniques, tips and tricks. Since the code will be run on the client’s browser it is up to the developer to begin optimizing the code in such a way that is faster and more efficient. All code contains data, some of which is used more frequently. A good optimization consists in ”caching” the frequently used objects into user defined variables [2]. For example, the engine will look up ”documents.images” every time it is encountered in the following code [2]: JavaScript code that should be optimized <script type="text/javascript"> for (i=0;i<document.images.length;i++) document.images[i].src="blank.gif" </script> If we use a variable instead, the number of calls to the ”images” object will be cut in half. Variables also offer the possibility to avoid looking-up functions that are used repeatedly. Each time a function is executed, in a loop, it is looked up in each iteration. Saving the method in a variable will prevent the function from being looked up each time. But, variables can also slow down JavaScript code if not used properly. Variables are looked up based on a scope chain, starting from the most specific scope and ending with the least specific one, which may take a lot of time. If the variable is not found each scope is investigated. A simple example of a poor variable declaration is represented in the code below: JavaScript poor variable declaration
  4. 4. 4 Ungureanu Vlad-Costel and Honciuc Irina function WorkOnLocalVariable() { local_variable = ObtainValueFromDOM(); return (local_variable + 1); } The variable ”local variable” is required only in the functions scope but because it is not properly declared it will be looked up in all scope. To solve this problem the variable should have been preceded by ”var” keyword. Like most coding languages, JavaScript is also predisposed to memory leaks. Avoiding memory leaks is not really an optimization but rather common sense, but it can exponentially increase performance. Memory leaks issues are associ- ated with hidden nodes in the page structure [4] (inserting images in a hidden node) and with objects caught in circular references (garbage collecting host objects in circular references). These situations seem to be browser dependent, but avoiding them surely eliminates these known issues. While code related improvements can optimize a web application’s perfor- mance, logic also helps avoiding slowing the client. Several tips in working with DOM elements can prevent bad performance [3, 4]: – avoid DOM if possible or make them as infrequently as possible; – instead of attaching event handlers to each element list, attach the event handler to their parent in order to avoid passing through all the elements. Overwhelming a single page of the application with too much JavaScript code will lead to slow performance even though there seems to be a tendency for page centric applications. Page centric application have limited functionality with small to moderate amounts of JavaScript code, while complex web applications with a lot of functionality would have to much code executed in them [3]. Finally, even though it does not make the subject of this paper, JavaScript performance depends on the engine that interprets it. These engines are specific to the browser the web application is accessed with and have various advantages and disadvantages. A brief look over a comparative study [5] shows a constant care in increasing the performance of these engines. 4 CSS CSS plays a major role in the development of web applications. Similarly, to JavaScript several optimizations can be done in order to increase the applications performance in terms of code organization [10]: – CSS should be external in order to benefit from caching [6]; – CSS references should be put on top of the web page, since the HTML Rendering Engine that also interprets CSS is called first; – CSS file size can influence the loading speed [7, 8]; – try to avoid CSS circular references or duplicate references [11].
  5. 5. A study on client-side web applications performance 5 Probably the first thing to consider when optimizing CSS is repetitive declara- tion. The following code example shows a common mistake that can increase the CSS file size: CSS repetitive declaration h2 { font-size: 1.5em; padding: 10px 10px 10px 25px; margin: 10px 0; border: 1px solid #ddd; background: #f0f0f0 url(crown.gif) no-repeat 5px 10px; } p2 { font-size: 1.5em; padding: 10px 10px 10px 25px; margin: 10px 0; border: 1px solid #ddd; background: #f0f0f0 url(crown.gif) no-repeat 5px 10px; } .block { font-size: 1.5em; padding: 10px 10px 10px 25px; margin: 10px 0; border: 1px solid #ddd; background: #f0f0f0 url(crown.gif) no-repeat 5px 10px; } Considering that more than one person usually develops web applications, over a long period of time such mistakes are likely to happen. As a quick fix for the above example, we can group the CSS code as follows [6, 7]: CSS optimization h2, p, .block { font-size: 1.5em; padding: 10px 10px 10px 25px; margin: 10px 0; border: 1px solid #ddd; background: #f0f0f0 url(crown.gif) no-repeat 5px 10px; } Another similar practice is to minimize the code by taking advantage of the logical grouping of properties. The following list includes the most commonly used ”shorthands” [6, 7, 9]: – font (controls ”font-size”, ”font-weight”, ”line-height”, etc.; – background (controls element backgrounds, placement, repeating, etc.); – list-style (sets the properties of the list item ”bullet”);
  6. 6. 6 Ungureanu Vlad-Costel and Honciuc Irina – margin (defines the width of margins on the sides of a box); – border (defines properties for the borders on a box - there are several short- hand properties involving borders); – padding (defines the width of padding within the sides of a box). A problem generated by the CSS that determines low performance in JavaScript related to repaints and reflows by the browser. Several CSS elements may trig- ger unnecessary repaints or reflows like setting a property of the style attribute, changing font, changing width or height and activation CSS pseudo classes (”: hover”) [11]. Several performance tweaks may be applying animations to el- ements that have fixed or absolute position (animation does not affect other elements) and avoiding JavaScript expressions in CSS [11]. 5 HTML Since HTML is the main building block of web application, over the years, almost all the problems have been corrected and all bugs fixed. On a different note, browsers have evolved and increased in performance. In this condition HTML optimization seems unnecessary. As with all other technologies, several practices may improve HTML behavior, out of which we will point out the following [12]: – removing white spaces (space, enter, tab); – using strict DTD for maximizing render speed; – omit redundant tags; – minimize headers, metadata and ALT values. One last performance optimization may be not using the ”table” elements for layout and positioning. It is true that in some cases ”table” may reduce the html flexibility, influence the positioning of other HTML elements or it may have a slow render when widths and heights for all rendered table cells have to be determined and changed when rendering each new table cell [13, 14]. Although these are valid points, they are almost impossible to test since browsers have reached extreme performance masking all the effort required to work with tables. Many technologies that generate HTML code (JSF, IceFaces, RichFaces etc.) confirm that tables can now be used without fear of slow performance since each of them uses tables for at least one of their user interface components (example : IceFaces ”panelGrid” component). 6 Firebug Firebug is a Firefox plug-in, considered by many developers a ”must-have” tool for building web applications. Since this plug-in provides multiple functionalities for testing, profiling and debugging web application it comes natural to discuss it in greater detail. Firebug offers the possibility to check all HTTP requests [15]. A small exam- ple is provided by the following screen capture:
  7. 7. A study on client-side web applications performance 7 Fig. 1. Firebug HTTP requests list In Figure 6, we can see that firebug is able to track each request the time it took for the request to return a response and the address the request was sent to. Aside from that, Firebug can interpret each request and determine if the the request was for downloading one of the following files: HTML, CSS, JavaScript, images or Flash files [15]. For these resources, Firebug can specify the size, the time they took to download and if they had been cached before. We mentioned before that the client is influenced by the number of request the web application makes, the URL it sends requests to and the size of the files it downloads (JavaScript, CSS and HTML)[15]. Firebug provides a way to analyze this information, to filter the HTTP request, remove duplicated files and discovered oversized files that are downloaded. Firebug network monitor can also determine request and response headers for normal and Ajax requests. Figure 6 provides an example: Fig. 2. Request and response headers provided by Firebug Another feature of Firebug is that it allows for CSS inspection and manip- ulation in real time [15]. When using the CSS inspector we can see either the entire CSS file for the loaded page or we can go into details by selecting a HTML element and reviewing what CSS code is applied to it.
  8. 8. 8 Ungureanu Vlad-Costel and Honciuc Irina Fig. 3. CSS inspection with Firebug Firebug provides powerful CSS editor features like auto-complete, validation, cascade inspection and code enabling, all of which have and instant result on the inspected web page. Of course while inspecting the CSS we inspect the HTML elements of the page, thus we can say the Firebug also provides an HTML inspector [15]. While the features mentioned above are useful, other complicated and im- portant features may also be required in developing a web application. In order to satisfy the ”must-have” attribute, Firebug provides a way to find errors, sort and search through any existing errors in the page. However, since most errors in a web application are related to JavaScript, Firebug also provides many helpful features like inspecting, debugging and logging all JavaScript’s executed in the inspected page [15]. Fig. 4. JavaScript debugging with Firebug
  9. 9. A study on client-side web applications performance 9 Considering all features (HTML, CSS, HTTP Request, JavaScript) we can clearly state that Firebug is an valuable asset when it comes to developing and testing the performances of an web application. It is also important to state that the installation is very easy and the usage is intuitive, help is rarely required in using a feature and performances are great, even though older version have performance issues and crashes. 7 Optimizing CSS Several services provide optimization tools for CSS files. Optimization seems to refer only to size and format, and most services do a decent job in decreasing the size of the CSS code. The following code (”shiny.css”) will be used to test some optimization tools: CSS code used to test some optimization tools .easytabletitle { background: url(./shinyimages/shinyheader.gif) #FFF; background: repeat-x scroll center left; font: normal normal normal; font-size: 11px; font-family: Verdana, Geneva, Arial, Helvetica,sans-serif; padding-left: 5px; padding-right: 5px; padding-top: 5px; padding-bottom: 5px; border: 1px solid; border-color: #CCC; text-align: left; } .easytableheader { background: url(./shinyimages/shinyheader.gif) #FFF repeat-x scroll center left; font: normal normal normal 11px Verdana, Geneva, Arial, Helvetica, sans-serif; padding: 5px; border: 1px solid #CCC; text-align: left; } The first application we used to optimize this code is ”Online CSS Optimizer” [16]. It manages to save 23 % of the file size with the outcome from Example 6. The second application we used is ”Clean CSS” [17] which manages to save 30 % of the file size with the outcome from Example 7. shiny1.css
  10. 10. 10 Ungureanu Vlad-Costel and Honciuc Irina .easytabletitle{font:11px verdana,geneva,arial,helvetica,sans serif;padding:5pxbackground:url(./shinyimages/shinyheader.gif) #FFF;background:repeat-x scroll center left;font:normal normal normal;border:1px solid;border-color:#CCC}.easytabletitle, .easytableheader{text-align:left}.easytableheader{background: url(./shinyimages/shinyheader.gif) #FFF repeat-x scroll center left;font:normal normal normal 11px Verdana, Geneva,Arial, Helvetica,sans-serif;padding:5px;border:1px solid #CCC} shiny2.css .easytabletitle{background:repeat-x scroll center left; font:normal normal normal;font-size:11px;font-family:Verdana, Geneva,Arial, Helvetica,sans-serif;border:1px solid;text-align: left;border-color:#CCC;padding:5px;}.easytableheader{background :url(./shinyimages/shinyheader.gif)#FFF repeat-x scroll center left;font:normal normal normal 11px Verdana, Geneva,Arial, Helvetica, sans-serif;border:1px solid #CCC;text-align:left; padding:5px;} Note that all that the applications do is to remove white spaces reducing file size but making the file almost unreadable. Aside from the smaller size of the file, neither application found the error in the CSS file (found with W3C CSS Valuator) [18] and neither was able to group the CSS according to the ”shorthands” (like background, font or padding). With this result we can state that CSS optimization is still in at its beginnings and probably will remain this way since broadband and computer performance get better and better. 8 Ajax Optimization There seem to be several Ajax optimization tools available. First, we started to test ”Razor Profiler” [19] which has two modes of working: probe application or start an in-browser profiler, both requiring using their proxy. After all configu- rations had been done we discovered that the profiler was unable to profile the target application due to host name path. The profiler was unable to determine the problem or to point out any hints in order to get it working. The second application we used is ”Y Slow” plug-in for Firefox [20]. Although not as impressive as the previous application, ”Y Slow” turned out to be a great profiler. This profiler targets some of the most known issues in web application development and tests if the given application avoids them. After the analysis is completed the plug-in gives a grade to each aspect representing the application optimization regarding that aspect. Aside from the fact that ”Y Slow” searches for duplicate CSS and JS files, or CSS positioning in a page it does have several features regarding AJAX: – make AJAX cacheable;
  11. 11. A study on client-side web applications performance 11 – use GET or POST for AJAX requests; – number of DOM elements in a page. Aside from these features, ”Y Slow” can call several applications that show JavaScript or CSS in readable or minimized format. Also it offers a performance graph for the visited page: Fig. 5. Performance graph offered by Y Slow The last thing we should mention about this great profiler is the fact that it also shows the components used in the page (images, iframes, files, scripts etc.). 9 Conclusions After going over several ways to profile and optimize the client-side technolo- gies, we can clearly state the obvious: ”we should only optimize when needed”. Some of the tips or techniques presented in this paper could be considered best practices since they should be used in any application even before considering optimizations. On the other hand, client-side technologies have evolved a lot in the last few years making browsers better and faster thus making sure that performance is- sues like tables for layout or CSS at the end of page are masked. When talking about CSS, HTML or to some extent about HTTP Request we can say that performance is actually decreased only in very few situations thus making opti- mization unnecessary most of the times. The only optimizations that really make a difference seem to be those made to JavaScript and to AJAX, since they might slow down the application. Avoiding large DOM changes and looping through large pages are some of the best ways to get rid of performance problems. Regardless of the technologies we want to optimize, using a profiler or another test tools seems to be a very good practice. Some application may analyze your code while other may analyze the performance of the application. As we have seen some applications may even point out other problems related to server side, requests or even configurations.
  12. 12. 12 Ungureanu Vlad-Costel and Honciuc Irina References 1. Huck, J.: Server Side Techniques for Client Side Optimization 2. 3. 4. 5. 6. 7. 8. _optimization_speed_web_site#HowtooptimizeCSS 9. 10. 11. _your_javascript_slow.php 12. 13. 14. 15. 16. 17. 18. 19. 20.