Client-side Website Optimization

Client-side Website Optimization

Realizati un studiu privind performanta aplicatiilor Web la nivel de client. Se
vor lua in consideratie optimizarea codului -sursa, performanta programelor
JavaScript, instrumentele de monitorizare si de testare la nivel de client (e.g.,
extensii Firefox precum Firebug, Selenium, Y! Slow).

Motivation
Did you know that 80% to 90% of the user's page-load time comes from components
outside the firewall? Optimizing performance on the front end (e.g. from the client
side) can enhance the user experience by reducing the response times of your web
pages and making them load and render much faster.

Why you might need it: Although your site's response time may appear quick when it
is accessed via an internet connection from a location close to the data center, you
should also consider the experience for other users:

Any mobile users accessing your site have to rely on relatively slow connections with
high latency.

Other people may be traveling, frustrated while they're waiting for the site to load
because of an overcrowded wireless connection in the airport or a slow mobile phone
connection.

People accessing web site from more remote locations throughout the world
inevitably suffer from increased connection latency and often high packet loss.

In addition, render time can be very long even on a fast network connection. The page
design and the way you use CSS, JavaScript and other technologies can delay
rendering much longer than necessary. The result is a poor user experience. Extensive
testing has confirmed the relationship between this and the site's financial
performance.

By examining log files, we can identify what the user experience is for your site.

Front end optimization can help reduce the amount of traffic required; and thus,
reduce hosting charges. An optimized system also means you can use less hardware
for serving the traffic both on front end/cache servers as well as back end servers.

1|Page


Tools
2.1 Firebug - Firebug integrates with Firefox to put a wealth of web development tools at your
fingertips while you browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any
web page.

Evaluating download speed
The Net tab graphs the request times for all http requests that make up a page. Network monitoring
must be turned on for the Net Tab to work, but it’s on by default (the options drop down on the right
hand side of the firebug panel allows you to toggle this feature off and on). This is a handy way to
test (and prove) that putting your javascript files at the bottom of your files, especially for javascript
heavy pages, improves perceived download time. Total download time will be the same, but since
browsers stop loading pages when they hit scripts until the scripts have been downloaded, the page
will appear to download faster, which is a better user experience.

By left clicking on the plus sign to the left of the file name, Firebug displays the HTTP headers of each
file that was downloaded.

In the 1.0..5 version of Firebug you can see how long it takes for HTML files only to be downloaded,
CSS files only, images only, etc., or all files. YSlow, Yahoo!s performance tool, should be available as a
plug in for Firefox by the end of the summer. In the meantime, Firebug’s Net tab is the next best
thing.

AJAX
As mentioned above, Firebug captures dynamic content and other DOM changes made to your
webpage. If you view the source via Firebug, Firebug reflects changes made to the DOM, and
includes the “Hello World” content. This is one of the core strengths of Firebug: without Firebug,
AJAX requests and responses are invisible. With it, you can view the sent and received text as well as
the headers that went along with it. You can also monitor how long it took for each request/response
with the Net tab.

You can see XHR response by clicking on the Net tab, and then the XHR tab in the sub navigation that
opens up when you are in the Net view. While the All Net tab is like yslow, the XHR focuses on the
AJAX only. If you click on the plus sign to the left of the response file, you can see both the headers
and the content of the response.

2|Page


2.2 Yahoo! Yslow - YSlow analyzes web pages and suggests ways to improve their performance
based on a set of rules for high performance web pages. YSlow is a Firefox add-on integrated with
the Firebug web development tool. YSlow grades web page based on one of three predefined ruleset
or a user-defined ruleset. It offers suggestions for improving the page's performance, summarizes the
page's components, displays statistics about the page, and provides tools for performance analysis,
including Smush.it™ and JSLint.

3|Page


2.3 Uitest.com - UITest.com: Web Development Tools
Uitest.com is a site which gathers several tools for website optimization. You can check multiple
aspects of your website with only a click. Among the tools there are links to markup validation,
website anatomy and load times on different connection speeds.

4|Page


5|Page


Results
Using the metioned tools we could summary up some of the best practices for front-end (client)
optimization and group them by category.

Minimizing HTTP Requests
80% of the end-user response time is spent on the front-end. Most of this time is tied up in
downloading all the components in the page: images, stylesheets, scripts, Flash, etc. Reducing the
number of components in turn reduces the number of HTTP requests required to render the page.
This is the key to faster pages.

One way to reduce the number of components in the page is to simplify the page's design. But is
there a way to build pages with richer content while also achieving fast response times? Here are
some techniques for reducing the number of HTTP requests, while still supporting rich page designs.

Combinined files are a way to reduce the number of HTTP requests. This way we could combine
multilple CSS files in only one file, we could use CSS sprites (using only one image for multiple
pictures and then splitting them by using CSS background-image and background-position
properties) or we could combine multiple javascript files in one.

Image maps is another technique for merging multiple images in one but is recommended only for
navigation bars as defining the coordinates of image maps can be tedious and error prone.

6|Page


Using a Content Delivery Network
The user's proximity to your web server has an impact on response times. Deploying your content
across multiple, geographically dispersed servers will make your pages load faster from the user's
perspective. But where should you start?

Remember that 80-90% of the end-user response time is spent downloading all the components in
the page: images, stylesheets, scripts, Flash, etc. This is the Performance Golden Rule. Rather than
starting with the difficult task of redesigning your application architecture, it's better to first disperse
your static content. This not only achieves a bigger reduction in response times, but it's easier thanks
to content delivery networks.

Add an Expires or a Cache-Control Header
There are two things in this rule:

 For static components: implement "Never expire" policy by setting far future Expires
header
 For dynamic components: use an appropriate Cache-Control header to help the browser
with conditional requests

Web page designs are getting richer and richer, which means more scripts, stylesheets, images, and
Flash in the page. A first-time visitor to your page may have to make several HTTP requests, but by
using the Expires header you make those components cacheable. This avoids unnecessary HTTP
requests on subsequent page views. Expires headers are most often used with images, but they
should be used on all components including scripts, stylesheets, and Flash components.

Gzip Components
The time it takes to transfer an HTTP request and response across the network can be significantly
reduced by decisions made by front-end engineers. It's true that the end-user's bandwidth speed,
Internet service provider, proximity to peering exchange points, etc. are beyond the control of the
development team. But there are other variables that affect response times. Compression reduces
response times by reducing the size of the HTTP response.

Starting with HTTP/1.1, web clients indicate support for compression with the Accept-Encoding
header in the HTTP request.

 Accept-Encoding: gzip, deflate

If the web server sees this header in the request, it may compress the response using one of the
methods listed by the client. The web server notifies the web client of this via the Content-Encoding
header in the response.

 Content-Encoding: gzip

Gzip is the most popular and effective compression method at this time. It was developed by the
GNU project and standardized by RFC 1952. The only other compression format you're likely to see is
deflate, but it's less effective and less popular.

7|Page


Put Stylesheets at the Top
While researching performance at Yahoo!, we discovered that moving stylesheets 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.

Front-end engineers that care about performance want a page to load progressively; that is, we want
the browser to display whatever content it has as soon as possible. This is especially important for
pages with a lot of content and for users on slower Internet connections. The importance of giving
users visual feedback, such as progress indicators, has been well researched and documented. 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 improves the overall user experience.

Put Scripts at the Bottom
The problem caused by scripts is that they block parallel downloads. 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.

In some situations it's not easy to move scripts to the bottom. If, for example, the script uses
document.write to insert part of the page's content, it can't be moved lower in the page. There
might also be scoping issues. In many cases, there are ways to workaround these situations.

Make JavaScript and CSS External
Many of these performance rules deal with how external components are managed. However,
before these considerations arise you should ask a more basic question: Should JavaScript and CSS be
contained in external files, or inlined in the page itself?

Using external files in the real world generally produces faster pages because the JavaScript and CSS
files are cached by the browser. JavaScript and CSS that are inlined in HTML documents get
downloaded every time the HTML document is requested. This reduces the number of HTTP requests
that are needed, but increases the size of the HTML document. On the other hand, if the JavaScript

8|Page


and CSS are in external files cached by the browser, the size of the HTML document is reduced
without increasing the number of HTTP requests.

Minify JavaScript and CSS
Minification is the practice of removing unnecessary characters from code to reduce its size thereby
improving load times. When code is minified all comments are removed, as well as unneeded white
space characters (space, newline, and tab). In the case of JavaScript, this improves response time
performance because the size of the downloaded file is reduced. Two popular tools for minifying
JavaScript code are JSMin and YUI Compressor. The YUI compressor can also minify CSS.

Obfuscation is an alternative optimization that can be applied to source code. It's more complex than
minification and thus more likely to generate bugs as a result of the obfuscation step itself. In a
survey of ten top U.S. web sites, minification achieved a 21% size reduction versus 25% for
obfuscation. Although obfuscation has a higher size reduction, minifying JavaScript is less risky.

Optimize Images
After a designer is done with creating the images for your web page, there are still some things you
can try before you FTP those images to your web server.

 You can check the GIFs and see if they are using a palette size corresponding to the
number of colors in the image. Using imagemagick it's easy to check using
identify -verbose image.gif
When you see an image useing 4 colors and a 256 color "slots" in the palette, there is
room for improvement.
 Try converting GIFs to PNGs and see if there is a saving. More often than not, there is.
Developers often hesitate to use PNGs due to the limited support in browsers, but this is
now a thing of the past. The only real problem is alpha-transparency in true color PNGs,
but then again, GIFs are not true color and don't support variable transparency either. So
anything a GIF can do, a palette PNG (PNG8) can do too (except for animations). This
simple imagemagick command results in totally safe-to-use PNGs:
convert image.gif image.png
"All we are saying is: Give PiNG a Chance!"
 Run pngcrush (or any other PNG optimizer tool) on all your PNGs. Example:
pngcrush image.png -rem alla -reduce -brute result.png
 Run jpegtran on all your JPEGs. This tool does lossless JPEG operations such as rotation
and can also be used to optimize and remove comments and other useless information
(such as EXIF information) from your images.
jpegtran -copy none -optimize -perfect src.jpg dest.jpg

Optimize CSS Sprites
 Arranging the images in the sprite horizontally as opposed to vertically usually results in a
smaller file size.
 Combining similar colors in a sprite helps you keep the color count low, ideally under 256
colors so to fit in a PNG8.
 "Be mobile-friendly" and don't leave big gaps between the images in a sprite. This doesn't
affect the file size as much but requires less memory for the user agent to decompress the

9|Page


image into a pixel map. 100x100 image is 10 thousand pixels, where 1000x1000 is 1 million
pixels

Browser Benchmarks
JavaScript continues to grow in importance as a browser benchmark, because it's the backbone of
no-reload interfaces like Gmail, Facebook, and lots of other webapps. Once again I used Sean Patrick
Kane's revised JavaScript speed tests and averaged out three results to measure the browsers:

10 | P a g e


Firefox bests Chrome in this test by a handy lead, while IE 8 takes nearly twice as long (in
milliseconds, of course) to perform all the actions Sean runs it through.

In the CSS test, as you can see, Chrome takes a commanding lead, Firefox doesn't lag too far
behind, and IE 8 actually stalled and froze on just about one of every two loads I ran. When it came
out of memory freeze, it did report consistent times, though—consistently behind. One could hand
the Dynamic Web Performance title to Firefox for the probably weightier JavaScript test, but Chrome
also shows a notable grace in running down the type frequently found on blogs. Let's call this a tie.

11 | P a g e


There sure are a lot of browsers to choose from these days. Peacekeeper is a free service that lets
you quickly and easily find out which one works best on your PC. If you're interested in how
Peacekeeper works read our FAQ for more information, or to get started, click on the "Benchmark
your Browser" button now. The test only takes a few minutes but if you're an impatient type you can
see the average results from thousands of users here.

What is the best browser?
Well that depends on how you define best? We can’t tell you which browser has the best features for
example. Most of the internet would disagree with us on principle, so we’re not even going to try.
You should though. You should try all the browsers. They all have something unique and interesting
to offer that could enhance your web experience.

At Futuremark, we like measuring and comparing things so our Peacekeeper service is designed to
measure a browser’s JavaScript performance. This is important because many modern dynamic
websites make extensive use of JavaScript to provide navigation, forms and other features. Changing
browsers to one with a high Peacekeeper score could make these sites faster and more responsive.

Peacekeeper measures your browser's performance by testing its JavaScript functionality. JavaScript
is a widely used programming language used in the creation of modern websites to provide features
such as animation, navigation, forms and other common requirements. By measuring a browser’s
ability to handle commonly used JavaScript functions Peacekeeper can evaluate its performance.

To create the tests we used a profiler to analyze JavaScript usage while browsing popular websites
such as YouTube, Facebook, GMail and Meebo. The profiler collected data on the frequency in which
different JavaScript functions were called on these sites and we used this data to create specific
weighted tests for each function. In some situations the profiler is not able to collect accurate data

12 | P a g e


and for these, we implemented the tests using common techniques and components to simulate the
requirements of a typical webpage.

13 | P a g e


References
http://www.percona.com/services/front-end-performance-optimization.html - Motivation

http://www.slideshare.net/craigwalker/client-side-performance-xero - Client-side Performance
comparison

http://www.die.net/musings/page_load_time/ - Page Load Optimization

http://www.cssdrive.com/index.php/main/csscompressor/ - CSS Compressor

http://getfirebug.com/docs.html - Firebug documentation

http://www.crockford.com/javascript/jsmin.html - javascript minifier

14 | P a g e


http://developer.yahoo.com/yslow/ - yahoo yslow extension

http://uitest.com/en/specials/ - website special tools

http://uitest.com/en/analysis/ - website analysis tools

http://uitest.com/en/check/results/?uri=http%3A%2F%2Fwww.infoiasi.ro – infoiasi.ro on uitest.com

http://validator.w3.org/checklink/checklink?uri=http%3A%2F%2Fwww.infoiasi.ro&summary=on&hid
e_redirects=on&hide_type=all&recursive=on&depth=500&check=Check – infoiasi.ro w3c validation

http://wave.webaim.org/report?url=http%3A%2F%2Fwww.infoiasi.ro – infoiasi.ro accessibility

http://analyze.websiteoptimization.com/wso - website optimization tips

http://tools.pingdom.com/fpt/?url=http%3A%2F%2Fwww.infoiasi.ro&treeview=0&column=objectID
&order=1&type=0&save=true – infoiasi.ro component load times

http://www.sitonomy.com/?url=www.infoiasi.ro – infoiasi.ro Anatomy

http://www.evotech.net/blog/2007/06/introduction-to-firebug/ - firebug Introduction

http://www.infoiasi.ro/bin/Main/ - Website chosen for tests

http://encosia.com/2007/03/06/debug-and-explore-aspnet-ajax-with-firebug/ - firebug AJAX
debugging

http://developer.yahoo.com/performance/rules.html - Yahoo Best Practices for Speeding Up Your Web Site

http://www.webpagetest.org/result/091018_2J3S/ - Webpagetest.org on infoiasi.ro

http://service.futuremark.com/peacekeeper/faq.action - Peacekeeper FAQ

Mazilu Liviu-Andrei, Pintilie Radu-Stefan - ISS

15 | P a g e

Client-side Website Optimization

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Client-side Website Optimization

Similaire à Client-side Website Optimization (20)

Dernier

Dernier (20)

Client-side Website Optimization