Why Limit Media

Website Performance: What To Know and What You Can Do

Web­site per­for­mance is a hugely impor­tant topic, so much so that the big com­pa­nies of the Web are obsessed with it. For the Googles, Yahoos, Ama­zons and eBays, slow web­sites mean fewer users and less happy users and thus lost rev­enue and reputation.

In your case, annoy­ing a few users wouldn’t be much of a prob­lem, but if mil­lions of peo­ple are using your prod­uct, you’d bet­ter be snappy in deliv­er­ing it. For years, Hol­ly­wood movies showed us how fast the Inter­net was: time to make that a reality.

Even if you don’t have mil­lions of users (yet), con­sider one very impor­tant thing: peo­ple are con­sum­ing the Web nowa­days less with fat con­nec­tions and mas­sive com­put­ers and more with mobile phones over slow wire­less and 3G con­nec­tions, but they still expect the same per­for­mance. Wait­ing for a slow web­site to load on a mobile phone is dou­bly annoy­ing because the user is usu­ally already in a hurry and is pay­ing by the byte or sec­ond. It’s 1997 all over again.

Per­for­mance is an expert’s game… to an extent. You can do innu­mer­able things to make a web­site per­form well, and much of it requires in-​​depth knowl­edge and bor­ing test­ing and research. I am sure a poten­tial mar­ket exists for web­site per­for­mance opti­miza­tion, much like there is one now for search engine opti­miza­tion. Inter­est­ingly, Google recently announced that it will fac­tor per­for­mance into its search rank­ings, so this is already hap­pen­ing. That said, you can do a lot of things with­out hav­ing to pay some­one to point out the obvious.

Know Your Per­for­mance Blockers

Per­for­mance can be mea­sured in var­i­ous ways. One way is tech­ni­cal: see­ing how fast a page loads and how many bytes are trans­ferred. Another is per­ceived per­for­mance, which ties into usabil­ity test­ing. This can only be mea­sured by test­ing with users and see­ing how sat­is­fied they are with the speed of your inter­face (e.g. do they start click­ing on your JavaScript carousel before it is ready?).

The good news (and hard truth) about per­for­mance is that 80 to 90% of poor per­for­mance hap­pens in the front end. Once the browser gets the HTML, the server is done and the back-​​end devel­oper can do noth­ing more. The browser then starts doing things to our HTML, and we are at its mercy. This means that to achieve peak per­for­mance, we have to opti­mize our JavaScript, images, CSS and HTML, as well as the back end.

So here are the things that slow down your page the most.

Exter­nal Resources (Images, Scripts, Style Sheets)

Every time you load some­thing from another server, the fol­low­ing happens:

1. The browser opens up the Internet’s address book and looks up the num­ber asso­ci­ated with the name of the server that’s hold­ing the things you want (i.e. its DNS entry).
2. It then nego­ti­ates a delivery.
3. It receives the deliv­ery (wait­ing for all the bytes to come in).
4. It tries to under­stand what was sent through and dis­plays it.

Every request is costly and slows down the load­ing of the page. This is also caused by browsers load­ing things in chunks (usu­ally four at a time) rather than all at the same time. This is akin to order­ing a prod­uct from a web­site, choos­ing the cheap­est deliv­ery option and not being at home between 9:00 am and 5:00 pm. If you include sev­eral JavaScript libraries because you like a cer­tain wid­get in each, then you’ll dou­ble, triple or even quadru­ple the time that your page takes to load and display.

Scripts

JavaScript makes our web­sites awe­some and fun to use, but it can also make for an annoy­ing experience.

The first thing to know about scripts that you include in a doc­u­ment is that they are not HTML or CSS; the browser has to call in an expert to do some­thing with them. Here is what happens:

1. When­ever the browser encoun­ters a <script> block in the doc­u­ment, it calls up the JavaScript engine, sits back and has a coffee.
2. The script engine then looks at the con­tent in the script block (which may have been deliv­ered ear­lier), sighs, com­plains about the poor code, scratches its head and then does what the script tells it to do.
3. Once the script engine is done, it reports back to the browser, which puts down its cof­fee, says good-​​bye to the script engine and looks at the rest of the doc­u­ment (which might have been changed, because the script may have altered the HTML).

The moral of the story is to use as few script blocks as pos­si­ble and to put them as far down the doc­u­ment as pos­si­ble. You could also use clever and lazy JavaScript, but more on that later.

Images

Here is where things get inter­est­ing. Opti­miz­ing images has always been the bane of every visual designer. We build our beau­ti­ful images in Illus­tra­tor, Pho­to­shop or Fire­works and then have to save them as JPG, GIF or PNG, which changes the col­ors and dete­ri­o­rates the qual­ity; and if we use PNG, then IE6 arrives as the party-​​pooper, not let­ting us take advan­tage of PNG’s cool features.

Opti­miz­ing your images is absolutely nec­es­sary because most of the time they are the biggest files on page. I’ve seen peo­ple jump through hoops to cut their JavaScript down from 50 KB to 12 KB and then hap­pily use a 300 KB logo or “hero shot” in the same doc­u­ment. Per­for­mance needs you!

Find­ing the right bal­ance between visual loss and file size can be daunt­ing, but be grate­ful for the Web pre­view tool, because we didn’t always have it. I recall using Pho­to­shop 4 and then Pho­to­shop with the Ulead Smart­Saver, for example.

The inter­est­ing thing about images, though, is that after you have opti­mized them you can still save many more bytes by strip­ping unnec­es­sary data from the files and run­ning the files through tools that fur­ther com­press the images but are non-​​lossy. The bad news is that many of them are out there, and you’ll need dif­fer­ent ones for dif­fer­ent image for­mats. The good news is that tools exist that do all that work for you, and we will come back to this later. For more advanced opti­mizaition tech­niques feel free to take a closer look at the Smash­ing Magazine’s arti­cles Clever JPEG Opti­miza­tion Tech­niques, PNG Opti­miza­tion Guide and Clever PNG Opti­miza­tion Tech­niques.

Sim­ple Tools You Can Use Now To Improve Performance

All of those com­pa­nies that obsess about page per­for­mance offer tools that allow you to check your own web­site auto­mat­i­cally and make it easy to work around problems.

Test Your Performance

The first thing to do is find out how your web­site can be opti­mized. Here are three great tools (among oth­ers that crop up all the time) to use and combine.

Yahoo’s YSlow

YSlow is a Fire­bug add-​​on from Yahoo that allows you to auto­mat­i­cally check your web­site for per­for­mance issues. The results are ranked like Amer­i­can school grades, with A being the best and F being the worst. The grades are cross-​​linked to best prac­tice doc­u­men­ta­tion on the Yahoo per­for­mance pages. You can test sev­eral set­tings: “clas­sic YSlow,” which is tar­geted to Yahoo-​​sized web­sites, “YSlow 2″ and “small site or blog.” Results are listed clearly and let you click through to learn.

In the com­po­nents view, YSlow lists all of the issues it has found on your web­site and how seri­ous they are:

The sta­tis­tics view in YSlow gives you all infor­ma­tion in pie charts:

The tools sec­tion in YSlow offers a lot of goodies:

• JSLint
  Checks the qual­ity and secu­rity of your JavaScripts by run­ning them through JSLint.
• All JS
  Shows all JavaScript code in a document.
• All JS Beau­ti­fied
  Shows all JavaScript code in a doc­u­ment in an easy-​​to-​​read format
• All JS Mini­fied
  Shows all JavaScript code in a doc­u­ment in a mini­fied for­mat (i.e. no com­ments or white space)
• All CSS
  Show all CSS code in a document
• All Smush​.it
  Auto­mat­i­cally com­presses all of your images (more on this later).
• Print­able View
  Cre­ates a print­able doc­u­ment of all of YSlow’s results (great for show­ing to a client after you’ve opti­mized the page!)

Google’s Page Speed

Like YSlow, Page Speed by Google is also an add-​​on for Fire­bug. Its main dif­fer­ence is that it does a lot of the opti­miza­tion for you and pro­vides the mod­i­fied code and images immediately.

Page Speed’s other extra is that it mon­i­tors the over­all activ­ity of your page, allow­ing you to see when a doc­u­ment loads other resources after it has been loaded and to see what hap­pens when a user rolls over ele­ments or opens tabs and menus that load con­tent via AJAX.

Be care­ful with this fea­ture, though: it ham­mers your browser quite hard.

AOL’s Web­PageTest

Rather late to the game, AOL’s Web­PageTest is an appli­ca­tion with some very neat fea­tures. (It is also avail­able as a desk­top appli­ca­tion, in case you want to check Intranets or web­sites that require authentication.)

Web­PageTest allows you to run tests using either IE8 or IE7 from a server in the US or the UK, and it allows you to set all kinds of para­me­ters, such as speed and what to check for:

Once you have defined your para­me­ters and the test­ing is com­pleted, you will get in-​​depth advice on what you can do to opti­mize. You’ll get:

• A sum­mary,
• Detailed results,
• A per­for­mance review,
• An opti­miza­tion report,
• The con­tent breakdown,
• The domain breakdown,
• A screen­shot.

One very cool fea­ture of Web­PageTest is the visual record­ing you get of how long it takes for page ele­ments to show up on screen for users. The fol­low­ing screen­shot com­pares the results of this blog, Ajax­ian and Nettuts+:

You can even cre­ate a video of the ren­der­ing, which is another very cool thing to show clients.

Once you get the test results, it is time to fix any problems.

Use Image Sprites

Image Sprites were first dis­cussed in an arti­cle pub­lished by Dave Shea and based on the work of Petr Stan­icek. They have been cov­ered exten­sively here before, but under­stand­ing their full ben­e­fit is impor­tant before you start using them:

• All of your images will be avail­able as soon as the main image has loaded (no flick­er­ing on roll-​​overs or other annoyances).
• One HTTP request is made, instead of dozens (or hun­dreds, in some cases).
• Images have a much higher chance of stay­ing cached on the user’s machine because they are con­tained in a sin­gle file.

Shea’s arti­cle points out a lot of cool resources for cre­at­ing CSS Sprites but misses one that was released not long ago. Sprite Me was pro­duced by Google (under the super­vi­sion of Steve Soud­ers) and allows you to cre­ate Sprites auto­mat­i­cally from any web­site, even via a book­marklet. It ana­lyzes the images on a page and offers you var­i­ous options before gen­er­at­ing the Sprite and CSS for you.

Here’s a video of Steve show­ing Sprite Me in action:

Opti­mize Your Images

You know now that Page Speed can auto­mat­i­cally opti­mize your images. Another way to do this is with Yahoo’s Smush It, which is a set of image opti­miza­tion tools that ana­lyze your images, cre­ate the small­est pos­si­ble ver­sions and sends you a ZIP file of them all.

You can use Smush​.it directly in the browser or auto­mat­i­cally from YSlow. The web­site tells you how many bytes you can save by opti­miz­ing your images. This is yet another cool thing to show poten­tial clients when pitch­ing for a job.

Col­late Scripts and Load Scripts on Demand

As noted, try not to spread your <script> nodes all over the doc­u­ment, because the browser stops when­ever it encoun­ters one. Instead, insert them as far down in the doc­u­ment as possible.

You could even col­late your scripts auto­mat­i­cally in one sin­gle include using back-​​end scripts. Edward Eliot wrote one of these in PHP a while ago. It lets you cre­ate a sin­gle JavaScript include for all of your scripts and one for your CSS files, and it even ver­sions them for you.

JavaScript can be added dynam­i­cally to the page after the page has loaded. This tech­nique is called “lazy load­ing,” and sev­eral tools are avail­able to do it. Jan Jar­falk has one to lazy load jQuery plug-​​ins.

Some JavaScript libraries let you import only what you really need, instead of bring­ing in the whole singing-​​and-​​dancing library. YUI, for exam­ple, has a con­fig­u­ra­tor that allows you to pick and choose what you need from the library and either gives you a sin­gle URL where you can get the dif­fer­ent scripts or cre­ates a JavaScript that loads them on demand:

Notice that a tab tells you what the over­all size of the library will be.

The main trick in lazy load­ing is to dynam­i­cally cre­ate script nodes with JavaScript after the page has loaded and only when they are needed. I wrote about that two years ago on 24ways, and it has been a best prac­tice for dis­play­ing badges and wid­gets for a long time now.

Use Net­work Dis­trib­uted Hosting

If you use a library or CSS pro­vided by a library, make sure to use the hosted ver­sions of the files. In the case of YUI, this is done for you if you use the con­fig­u­ra­tor. And you can pick from Yahoo or Google’s network.

For other libraries, there is a Google code repos­i­tory of AJAX libraries. This is use­ful for a few reasons:

• Vis­i­tors to your web­site will get the JavaScript and CSS from the server that is as geo­graph­i­cally close to them as pos­si­ble and won’t have to wait for your server to send the infor­ma­tion from around the globe.
• There is a high prob­a­bil­ity that these servers are faster than yours.
• Vis­i­tors who have vis­ited other web­sites that use the same includes will already have them on their com­put­ers and won’t need to load them again.
• You save on band­width and can eas­ily upgrade the library by chang­ing the ver­sion num­ber of the include.

While you prob­a­bly wouldn’t be able to afford dis­trib­uted host­ing for your own files, Coral makes an inter­est­ing offer to dis­trib­ute your data onto a net­work of servers for an afford­able $50 a month.

Watch Some Videos

If you want to see how some of this work, check out the fol­low­ing videos, espe­cially Nicole Sullivan’s, which shows some very cool CSS tricks:

• Using YSLow 2.0
• Using Google Page Speed
• Nicole Sul­li­van tells you not to blame the rounded cor­ners but to design for fast websites
• Steve Soud­ers show­ing Sprite Me
• Dou­glas Crock­ford on AJAX per­for­mance.

Fol­low The Leaders

To learn more about web­site per­for­mance, here are some resources and peo­ple to fol­low. (Be warned: some of the con­tent is tech­ni­cally tough.)

• The Yahoo Devel­oper Net­work Per­for­mance Sec­tion
  Home of YSLow and prob­a­bly the first offi­cial per­for­mance research website.
• Per­for­mance Planet
  A col­la­tion of all per­for­mance blogs and posts in one RSS feed.
• Steve Soud­ers (@souders)
  Ex-​​maintainer of the per­for­mance sec­tion of Yahoo, now at Google. Author of the biggest per­for­mance books. And orga­nizer of the Veloc­ity conference.
• Nicole Sul­li­van (@stubbornella)
  Ex-​​team mem­ber of the per­for­mance group at Yahoo and co-​​creator of Smush​.it. Also CSS per­for­mance god­dess with great tips for design­ers. Cur­rently work­ing on mak­ing Face­book per­form better.
• Stoyan Ste­fanov (@stoyanstefanov)
  Coder of Smush​.it and mem­ber of the per­for­mance team at Yahoo. Cre­ated his own advent cal­en­dar of per­for­mance tips this year, and runs Per­for­mance Planet, as men­tioned above.
• Ed Eliot and Stu­art Colville
  Builders of the CSS Sprite Gen­er­a­tor.
• Jake Archibald (@jaffathecake)
  Lead devel­oper of the BBC’s Glow library. Deliv­ered a great talk on per­for­mance at this year’s Full Frontal conference.
• Phillip Tel­lis (@bluesmoon)
  Per­for­mance junkie at Yahoo.
• And me, their fan­boy and per­son ask­ing for fea­tures: Chris Heil­mann (@codepo8).

(al)

© Chris­t­ian Heil­mann for Smash­ing Mag­a­zine, 2010. | Perma­link | Be the first to com­ment | Add to del​.icio​.us | Digg this | Stum­ble on Stum­ble­Upon! | Tweet it! | Sub­mit to Red­dit | Forum Smash­ing Mag­a­zine
Post tags: opti­miza­tion, per­for­mance