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 oer 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.

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 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. 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 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. 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 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. 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 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. 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 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. 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 Ungureanu Vlad-Costel and Honciuc Irina
References
1. Huck, J.: Server Side Techniques for Client Side Optimization
2. http://www.javascriptkit.com/javatutors/efficientjs.shtml
3. http://blogs.msdn.com/ie/archive/2006/08/28/728654.aspx
4. http://www.fasterj.com/articles/javascript.shtml
5. http://ejohn.org/blog/javascript-performance-rundown/
6. http://www.bloggingpro.com/archives/2006/08/17/css-optimization/
7. http://www.sohtanaka.com/web-design/optimizing-css-tutorial
8. http://nadeausoftware.com/articles/2008/06/dont_bother_using_css
_optimization_speed_web_site#HowtooptimizeCSS
9. http://www.communitymx.com/content/article.cfm?cid=90F55
10. http://www.queness.com/post/588/15-ways-to-optimize-css-and-reduce-css-file-size
11. http://www.ajaxlines.com/ajax/stuff/article/css_performance_making
_your_javascript_slow.php
12. http://www.websiteoptimization.com/speed/3/
13. http://www.webreference.com/authoring/languages/html/optimize/5.html
14. http://davespicks.com/essays/notables.html
15. http://getfirebug.com/
16. http://www.cssoptimiser.com/optimize.php
17. http://www.cleancss.com/
18. http://jigsaw.w3.org/css-validator/validator
19. http://www.razorspeed.com/
20. http://developer.yahoo.com/yslow/