Website Performance: What To Know and What You Can Do

Advertisement

Website performance is a hugely important topic, so much so that the big companies of the Web are obsessed with it. For the Googles, Yahoos, Amazons and eBays, slow websites mean fewer users and less happy users and thus lost revenue and reputation.

In your case, annoying a few users wouldn’t be much of a problem, but if millions of people are using your product, you’d better be snappy in delivering it. For years, Hollywood movies showed us how fast the Internet was: time to make that a reality.

Even if you don’t have millions of users (yet), consider one very important thing: people are consuming the Web nowadays less with fat connections and massive computers and more with mobile phones over slow wireless and 3G connections, but they still expect the same performance. Waiting for a slow website to load on a mobile phone is doubly annoying because the user is usually already in a hurry and is paying by the byte or second. It’s 1997 all over again.

Screenshot

Performance is an expert’s game… to an extent. You can do innumerable things to make a website perform well, and much of it requires in-depth knowledge and boring testing and researceh. I am sure a potential market exists for website performance optimization, much like there is one now for search engine optimization. Interestingly, Google recently announced that it will factor performance into its search rankings1, so this is already happening. That said, you can do a lot of things without having to pay someone to point out the obvious.

Know Your Performance Blockers Link

Performance can be measured in various ways. One way is technical: seeing how fast a page loads and how many bytes are transferred. Another is perceived performance, which ties into usability testing. This can only be measured by testing with users and seeing how satisfied they are with the speed of your interface (e.g. do they start clicking on your JavaScript carousel before it is ready?).

The good news (and hard truth) about performance is that 80 to 90% of poor performance happens in the front end. Once the browser gets the HTML, the server is done and the back-end developer can do nothing more. The browser then starts doing things to our HTML, and we are at its mercy. This means that to achieve peak performance, we have to optimize our JavaScript, images, CSS and HTML, as well as the back end.

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

External Resources (Images, Scripts, Style Sheets) Link

Every time you load something from another server, the following happens:

  1. The browser opens up the Internet’s address book and looks up the number associated with the name of the server that’s holding the things you want (i.e. its DNS2 entry).
  2. It then negotiates a delivery.
  3. It receives the delivery (waiting for all the bytes to come in).
  4. It tries to understand what was sent through and displays it.

Every request is costly and slows down the loading of the page. This is also caused by browsers loading things in chunks (usually four at a time) rather than all at the same time. This is akin to ordering a product from a website, choosing the cheapest delivery option and not being at home between 9:00 am and 5:00 pm. If you include several JavaScript libraries because you like a certain widget in each, then you’ll double, triple or even quadruple the time that your page takes to load and display.

Scripts Link

JavaScript makes our websites awesome and fun to use, but it can also make for an annoying experience.

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

  1. Whenever the browser encounters a <script> block in the document, it calls up the JavaScript engine, sits back and has a coffee.
  2. The script engine then looks at the content in the script block (which may have been delivered earlier), sighs, complains 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 coffee, says good-bye to the script engine and looks at the rest of the document (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 possible and to put them as far down the document as possible. You could also use clever and lazy JavaScript, but more on that later.

Images Link

Here is where things get interesting. Optimizing images has always been the bane of every visual designer. We build our beautiful images in Illustrator, Photoshop or Fireworks and then have to save them as JPG, GIF or PNG, which changes the colors and deteriorates the quality; and if we use PNG, then IE6 arrives as the party-pooper, not letting us take advantage of PNG’s cool features.

Optimizing your images is absolutely necessary because most of the time they are the biggest files on page. I’ve seen people jump through hoops to cut their JavaScript down from 50 KB to 12 KB and then happily use a 300 KB logo or “hero shot” in the same document. Performance needs you!

Finding the right balance between visual loss and file size can be daunting, but be grateful for the Web preview tool, because we didn’t always have it. I recall using Photoshop 4 and then Photoshop with the Ulead SmartSaver, for example.

The interesting thing about images, though, is that after you have optimized them you can still save many more bytes by stripping unnecessary data from the files and running the files through tools that further compress the images but are non-lossy. The bad news is that many of them are out there, and you’ll need different ones for different image formats. 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 optimizaition techniques feel free to take a closer look at the Smashing Magazine’s articles Clever JPEG Optimization Techniques3, PNG Optimization Guide4 and Clever PNG Optimization Techniques5.

Simple Tools You Can Use Now To Improve Performance Link

All of those companies that obsess about page performance offer tools that allow you to check your own website automatically and make it easy to work around problems.

Test Your Performance Link

The first thing to do is find out how your website can be optimized. Here are three great tools (among others that crop up all the time) to use and combine.

Yahoo’s YSlow Link

YSlow6 is a Firebug add-on from Yahoo that allows you to automatically check your website for performance issues. The results are ranked like American school grades, with A being the best and F being the worst. The grades are cross-linked to best practice documentation on the Yahoo performance pages7. You can test several settings: “classic YSlow,” which is targeted to Yahoo-sized websites, “YSlow 2” and “small site or blog.” Results are listed clearly and let you click through to learn.

YSlow Smashing mag overall grade.8

In the components view, YSlow lists all of the issues it has found on your website and how serious they are:

Smashing Magazine on YSlow components view.9

The statistics view in YSlow gives you all information in pie charts:

Smashing Magazine in YSlow - statistics.10

The tools section in YSlow offers a lot of goodies:

  • JSLint11
    Checks the quality and security of your JavaScripts by running them through JSLint.
  • All JS
    Shows all JavaScript code in a document.
  • All JS Beautified
    Shows all JavaScript code in a document in an easy-to-read format
  • All JS Minified
    Shows all JavaScript code in a document in a minified format (i.e. no comments or white space)
  • All CSS
    Show all CSS code in a document
  • All Smush.it
    Automatically compresses all of your images (more on this later).
  • Printable View
    Creates a printable document of all of YSlow’s results (great for showing to a client after you’ve optimized the page!)

YSlow tools.12

Google’s Page Speed Link

Like YSlow, Page Speed by Google13 is also an add-on for Firebug. Its main difference is that it does a lot of the optimization for you and provides the modified code and images immediately.

Smashing Magazine on Google Page Speed.14

Page Speed’s other extra is that it monitors the overall activity of your page, allowing you to see when a document loads other resources after it has been loaded and to see what happens when a user rolls over elements or opens tabs and menus that load content via AJAX.

Smashing Magazine Page Speed Activity.15

Be careful with this feature, though: it hammers your browser quite hard.

AOL’s WebPageTest Link

Rather late to the game, AOL’s WebPageTest16 is an application with some very neat features. (It is also available as a desktop application, in case you want to check Intranets or websites that require authentication.)

WebPageTest 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 parameters, such as speed and what to check for:

Pagetest web page performance test.17

Once you have defined your parameters and the testing is completed, you will get in-depth advice on what you can do to optimize. You’ll get:

  • A summary,
  • Detailed results,
  • A performance review,
  • An optimization report,
  • The content breakdown,
  • The domain breakdown,
  • A screenshot.

Web page performance test results.18

One very cool feature of WebPageTest is the visual recording you get of how long it takes for page elements to show up on screen for users. The following screenshot compares the results of this blog, Ajaxian and Nettuts+:

Web page visual comparison by  you.19

You can even create a video of the rendering, 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 Link

Image Sprites20 were first discussed in an article published by Dave Shea and based on the work of Petr Stanicek21. They have been covered extensively here before22, but understanding their full benefit is important before you start using them:

  • All of your images will be available as soon as the main image has loaded (no flickering on roll-overs or other annoyances).
  • One HTTP request is made, instead of dozens (or hundreds, in some cases).
  • Images have a much higher chance of staying cached on the user’s machine because they are contained in a single file.

Shea’s article points out a lot of cool resources for creating CSS Sprites but misses one that was released not long ago. Sprite Me23 was produced by Google (under the supervision of Steve Souders) and allows you to create Sprites automatically from any website, even via a bookmarklet. It analyzes the images on a page and offers you various options before generating the Sprite and CSS for you.

Here’s a video of Steve showing Sprite Me in action24:

Sprite Me on ebay by  you.25

Optimize Your Images Link

You know now that Page Speed can automatically optimize your images. Another way to do this is with Yahoo’s Smush It, which is a set of image optimization tools that analyze your images, create the smallest possible versions and sends you a ZIP file of them all.

You can use Smush.it26 directly in the browser or automatically from YSlow. The website tells you how many bytes you can save by optimizing your images. This is yet another cool thing to show potential clients when pitching for a job.

Yahoo! Smush.it™27

Smush.it optimization results.28

Collate Scripts and Load Scripts on Demand Link

As noted, try not to spread your <script> nodes all over the document, because the browser stops whenever it encounters one. Instead, insert them as far down in the document as possible.

You could even collate your scripts automatically in one single include using back-end scripts. Edward Eliot wrote one of these in PHP a while ago29. It lets you create a single JavaScript include for all of your scripts and one for your CSS files, and it even versions them for you.

JavaScript can be added dynamically to the page after the page has loaded. This technique is called “lazy loading,” and several tools are available to do it. Jan Jarfalk has one to lazy load jQuery plug-ins30.

Some JavaScript libraries let you import only what you really need, instead of bringing in the whole singing-and-dancing library. YUI, for example, has a configurator31 that allows you to pick and choose what you need from the library and either gives you a single URL where you can get the different scripts or creates a JavaScript that loads them on demand:

The YUI Configurator32

Notice that a tab tells you what the overall size of the library will be.

The main trick in lazy loading is to dynamically create script nodes with JavaScript after the page has loaded and only when they are needed. I wrote about that two years ago on 24ways33, and it has been a best practice for displaying badges and widgets for a long time now.

Use Network Distributed Hosting Link

If you use a library or CSS provided by a library, make sure to use the hosted versions of the files. In the case of YUI, this is done for you if you use the configurator. And you can pick from Yahoo or Google’s network.

For other libraries, there is a Google code repository of AJAX libraries34. This is useful for a few reasons:

  • Visitors to your website will get the JavaScript and CSS from the server that is as geographically close to them as possible and won’t have to wait for your server to send the information from around the globe.
  • There is a high probability that these servers are faster than yours.
  • Visitors who have visited other websites that use the same includes will already have them on their computers and won’t need to load them again.
  • You save on bandwidth and can easily upgrade the library by changing the version number of the include.

While you probably wouldn’t be able to afford distributed hosting for your own files, Coral35 makes an interesting offer to distribute your data onto a network of servers for an affordable $50 a month.

Watch Some Videos Link

If you want to see how some of this work, check out the following videos, especially Nicole Sullivan’s, which shows some very cool CSS tricks:

Follow The Leaders Link

To learn more about website performance, here are some resources and people to follow. (Be warned: some of the content is technically tough.)

(al)

Footnotes Link

  1. 1 http://www.downloadsquad.com/2009/11/14/google-to-use-page-load-speed-as-a-search-result-ranking-factor/
  2. 2 http://en.wikipedia.org/wiki/Domain_Name_System
  3. 3 http://www.smashingmagazine.com/2009/07/01/clever-jpeg-optimization-techniques/
  4. 4 http://www.smashingmagazine.com/2009/07/25/png-optimization-guide-more-clever-techniques/
  5. 5 http://www.smashingmagazine.com/2009/07/15/clever-png-optimization-techniques/
  6. 6 http://developer.yahoo.com/yslow/
  7. 7 http://developer.yahoo.com/performance/
  8. 8 http://www.flickr.com/photos/codepo8/4198617150/sizes/o/
  9. 9 http://www.flickr.com/photos/codepo8/4197863687/sizes/o/
  10. 10 http://www.flickr.com/photos/codepo8/4198630210/sizes/o/
  11. 11 http://www.jslint.com/
  12. 12 http://www.flickr.com/photos/codepo8/4197872303/sizes/o/
  13. 13 http://code.google.com/speed/page-speed/
  14. 14 http://www.flickr.com/photos/codepo8/4198657574/sizes/o/
  15. 15 http://www.flickr.com/photos/codepo8/4198689498/sizes/o/
  16. 16 http://www.webpagetest.org/
  17. 17 http://www.flickr.com/photos/codepo8/4198701698/sizes/o/
  18. 18 http://www.flickr.com/photos/codepo8/4198726620/sizes/l/
  19. 19 http://www.flickr.com/photos/codepo8/4198697096/sizes/o/
  20. 20 http://www.alistapart.com/articles/sprites/
  21. 21 http://wellstyled.com/css-nopreload-rollovers.html
  22. 22 http://www.smashingmagazine.com/2009/04/27/the-mystery-of-css-sprites-techniques-tools-and-tutorials/
  23. 23 http://spriteme.org/
  24. 24 http://www.youtube.com/watch?v=pNfRL-TwzZY#t=27m21s
  25. 25 http://www.youtube.com/watch?v=pNfRL-TwzZY#t=27m21s
  26. 26 http://www.smushit.com/ysmush.it/
  27. 27 http://www.flickr.com/photos/codepo8/4197963651/sizes/o/
  28. 28 http://www.flickr.com/photos/codepo8/4197968099/sizes/o/
  29. 29 http://www.ejeliot.com/blog/72
  30. 30 http://www.unwrongest.com/projects/lazy/
  31. 31 http://developer.yahoo.com/yui/3/configurator/
  32. 32 http://developer.yahoo.com/yui/3/configurator/
  33. 33 http://24ways.org/2007/keeping-javascript-dependencies-at-bay
  34. 34 http://code.google.com/apis/ajaxlibs/
  35. 35 http://www.coralcdn.org/
  36. 36 http://developer.yahoo.net/blogs/theater/archives/2009/04/yslow_update_screencast.html
  37. 37 http://www.youtube.com/watch?v=a-9pCfyYPdQ
  38. 38 http://yuiblog.com/blog/2008/12/23/video-sullivan/
  39. 39 http://www.youtube.com/watch?v=pNfRL-TwzZY#t=27m21s
  40. 40 http://www.yuiblog.com/blog/2008/12/23/video-crockford-performance/
  41. 41 http://developer.yahoo.com/performance/
  42. 42 http://www.perfplanet.com/
  43. 43 http://www.stevesouders.com/
  44. 44 http://www.twitter.com/souders
  45. 45 http://stubbornella.org/content/
  46. 46 http://www.twitter.com/stubbornella
  47. 47 http://phpied.com/
  48. 48 http://www.twitter.com/stoyanstefanov
  49. 49 http://www.phpied.com/performance-advent-calendar-2009/
  50. 50 http://website-performance.org/
  51. 51 http://spritegen.website-performance.org/
  52. 52 http://www.jakearchibald.com/
  53. 53 http://www.twitter.com/jaffathecake
  54. 54 http://www.jakearchibald.com/jsperformance/
  55. 55 http://bluesmoon.info/
  56. 56 http://twitter.com/bluesmoon
  57. 57 http://wait-till-i.com/
  58. 58 http://www.twitter.com/codepo8

↑ Back to top Tweet itShare on Facebook

An international Developer Evangelist working for Mozilla in the lovely town of London, England.

Advertisement
  1. 1

    I like the SpriteMe thingy, this always was a shitty job.

    0
  2. 2

    Not wishing to state the obvious, but surely the simplest solution is to add a mobile stylesheet stripping out all the extraneous crap that people with tiny screens don’t need to see.

    0
  3. 3

    I have been using smush.it on images for a while now, and find it saves loads on file size. Does using valid html/xhtml with properly nested tags etc. help a page to load and render faster? I have heard this rumoured but never read any solid proof of it.

    0
  4. 4

    @mike for those mobiles that support them (which are not many), yes. But you still load the main document…

    0
  5. 5

    Great article!
    I’ll make sure to consider most of the optimization methods mentioned.
    I could imagine that performance optimization will loose even more importance on the long run…the internet (as well as the mobile internet techniques) will become faster and faster anyway.

    0
  6. 6

    I tried using a ‘media=mobile’ stylesheet for my website, and tested in opera mini on my mobile, but that browser by default uses the ‘ media=screen’ one. It only uses the mobile style sheet if you switch it to ‘mobile’ browsing in the advanced settings. It seems that for the time being it is best not to rely on ‘media=mobile’ to give mobile users a better experience, but rather try and optimise your ‘screen’ style sheet as best you can to support all major browsers and screen sizes.

    0
  7. 7

    Adding a mobile stylesheet is only one part to the larger goal of increase the performance of the site. I agree that mobile stylesheets should have been mentioned in the article, but the focus was increasing the performance of the site for all users.

    0
  8. 8

    Great Post. Read these books “High Performance Web Sites” and “Even Faster Websites” written by Steve Souders. Amazing read and thorough insight into website optimisation techniques and methods.

    0
  9. 9

    I highly recommend Aptimize WAX (http://www.aptimize.com/how-it-works ).

    0
  10. 10

    @Grant – I can’t imagine using invalid html/xhtml/css NOT making things slower, to be honest … not only would the browser need to load the html/css and figure out how to render it, it would ALSO have to guess and assume a lot of extras because of things like missing end tags and whatnot … granted, if you left off quotes on attribute values, maybe that wouldn’t, but missing end tags would certainly make the browser take longer to render, since it has to assume where you wanted the end tag to be

    besides, it’s just good practice anyway ;) …

    another thing to add to the CSS section is: instead of using nasty CSS hacks to get things to work in real browsers AND IE, use a separate stylesheet for IE and put it inside conditional statements in your ‘head’ element. This way, other browsers won’t even see or bother to download the IE-specific CSS and they won’t have to deal with possibly invalid (or at least very confusing) CSS! Personally, on some sites, I’ve even had two IE stylesheets. One I name ie6.css and one I name ie+.css … though it’s been a while since I’ve cared about IE6 working perfectly ;) … and don’t forget to minify both your JavaScript and CSS! Yahoo has a great tool for that!

    0
  11. 11

    @DesignLovr – Ironically, I’ve personally noticed a lot more articles online here semi-recently about optimizing websites … more than I remember seeing in the days of dial-up … and I just got a letter from Cox the other day saying they’re upping their speeds again :) …

    granted, it’s still important! it’s kinda like microsoft adding more and more bells and whistles to Windows since machines are getting faster and faster … just because you have more resources doesn’t mean they need to be wasted! ;) … just imagine how fast sites will be if optimization plays an important role in the development of a site AND internet speeds keep increasing!!! :D

    0
  12. 12

    Nice post. YSlow and PageSpeed are good tools. The CSS and JS are a challenge because of plugins in WP.

    0
  13. 13

    Thanks for this excellent treatment on the various tools available for analysis. I’ve been writing a series on web performance on my blog as well: http://luke.ehresman.org/blog/series/313/web-performance

    0
  14. 14

    Good article Chris!

    You’re right that there are some obvious website performance optimization techniques. Turning on Gzip compression for example is a no-brainer, and can have a significant impact. But even some of the well-known techniques are not easily applied, and involve considerations and choices to be made.

    If you run a high-traffic site and are serious about ux/conversion optimization, you need an expert. Someone who has all the knowledge and knows how to apply that knowledge to that particular site. You need a solid analysis to find the problems and understand how problems are related to eachother. For example, JavaScript optimization is not trivial. Where to place the JS in the document, which technique to load the external JS without breaking the site’s functionality and hurting the user experience, …
    Solving the load time problems, implementing the *best* solutions, needs to be done carefully, step-by-step.

    So, yeah, I agree that there is often some low hanging fruit, but hiring an expert to lead the optimization every step of the way is definitely a wise decision for large e-commerce and media sites.

    0
  15. 15

    love the article. SpriteMe is really interesting nice job. thanx

    0
  16. 16

    Chris Heilmann on Smashing! Glad to see you write here… =]

    0
  17. 17

    excellent article…cheers to SM

    0
  18. 18

    very useful information, thank you dude!

    0
  19. 19

    Great stuff. I needed an overview :-)

    0
  20. 20

    I thinkone of the most important things is the thing with the requests! We are at a time where some request headover takes more time than the ressource to be loaded!

    And this is something the internet itself can not resolve with its speed ;).

    Like it when I got all those green points in PageSpeed and YSlow :).

    0
  21. 21

    I haven’t tried it myself yet, but “Web Optimizer” seems to do many of the tweaks you suggest fully automated. I will definitely have a look at it for my next project.
    http://www.web-optimizer.us/

    0
  22. 22

    It ‘burns my cookies’ that your news feed still puts all your ads up front and I have to wade through them to get to your article. Will you ever change this or should I just discontinue subscribing??? I subscribe to dozens of other feeds and yours is the only one doing this. Please be more considerate.

    thx, Art

    0
  23. 23

    With a mobile stylesheet, mobile users still need to download all the content and then get it stripped out. This is not good for performance anyway, and bad for users who pay per byte. In terms of performance, it’s less about visual clarity, and more about getting the bytes out there as fast as possible.

    0
  24. 24

    Great post, thanks!

    What I’d really like to know is at which point Google will consider the page loaded for the sake of it’s rankings. Will that be HTML only? Or HTML+CSS? Or HTML and all files referenced in the document? Will it follow @import directives in CSS or run JavaScript that inserts more script tags to load further scripts?

    You could potentially cheat the system by using small ‘loader’ files for larger CSS and JS files if it didn’t check that.

    0
  25. 25

    The Sprite article link (“extensively here before”) points to the wrong website. I guess it should be:
    http://www.smashingmagazine.com/2009/04/27/the-mystery-of-css-sprites-techniques-tools-and-tutorials/

    Excellent article, thanks!

    0
  26. 26

    Yes, image sprites are helpful and I use them regularly.

    HOWEVER (and this is a big one)

    All of that extra space used by your image sprites can and will send your browser’s memory usage through the roof if you aren’t careful. If you are working on a memory-sensitive site/application, keep this trade-off in mind!

    0
  27. 27

    No word about automated tools for website performance optimization like Aptimize or WEBO Site SpeedUp – http://www.web-optimizer.us/

    0
  28. 28

    Thiago A. Villa Menezes

    January 6, 2010 8:19 am

    What… A… Wonderful… USEFUL POST!

    0
  29. 29

    Nice resources!
    Thanks for sharing..

    0
  30. 30

    For my bachelor thesis, I’ve written File Conveyor.

    File Conveyor is a daemon written in Python to detect, process and sync files. In particular, it’s designed to sync files to CDNs. Amazon S3 and Rackspace Cloud Files, as well as any Origin Pull or FTP Push CDN, are supported.

    Check it out! :)

    Also as part of my bachelor thesis, I wrote the Drupal CDN Integration module, which will come in handy if your site is running Drupal.

    0
  31. 31

    Awesome collection!!-
    Thanks for Sharing ..

    0
  32. 32

    Vaibhav | Programming Kid

    January 6, 2010 9:14 am

    Great post. I use a combination of Firebug, Yahoo-Y!Slow, Google PageSpeed to rectify page load times and performance issues. I feel they are very strict and at times the solutions are a bit too much. If you want an A from Y!Slow, the page would consits of nothing but text or a replica of Google!

    0
  33. 33

    That is so not true with YSlow2. My own portfolio: http://icant.co.uk/ gets an A!

    1
  34. 34

    Great article showcasing some awesome tools – thanks for this. I use YSlow for all of my projects as it gives great information on everything. I’ve used sprites on one or two projects but always find that different browsers parse the code for sprites slightly different and I get cut off images/etc. It’s a pain to optimize your website, but you’re right – when you have millions of users coming to your website, that’s when you should REALLY worry.

    Until then don’t have a billion animated gifs on your website – take it easy on the people still visiting your website, but you don’t necessarily have to take all these extra steps in fully optimizing it because the server load won’t be as huge a part of the equation.

    0
  35. 35

    Thierry Koblentz

    January 6, 2010 9:43 am

    In the “Use Network Distributed Hosting” section, I’d add that the maximum of simultaneous requests is per server, so hosting assets on different servers should increase parallelize downloads.
    And what about hosting static assets on cookieless domains?
    The Google tool mentions both techniques (http://code.google.com/speed/page-speed/docs/request.html)

    @gLaNDix: using Conditional Comments with external styles sheets for IE increases the number of HTTP requests so I don’t see how that would help…

    0
  36. 36

    “80 to 90% of poor performance happens in the front end”

    As a software engineer who started on the front end and then moved heavily into server side technologies, I can tell you this is simply not true. Although server side technologies are used primarily to cache content like HTML, CSS, JavaScript and images, the bottlenecks I see are mostly related to third-party services, and too many XHRs tied into a slow back end. Buffering, caching and optimizing DB queries, and optimizing programming patterns are much more efficient at speeding up your Web application then trying to optimize the front end. You’ll get a greater gain in performance, which doesn’t excuse lazy client-side scripting and markup, but I would focus more energy on letting creatives/devs do what they do best, and let technologies like Memcached (or a service like Akamai) do the heavy lifting when it comes to performance boosts.

    1
  37. 37

    My brain just exploded. This article is one of the most useful I’ve seen. Thank!

    0
  38. 38

    The sad part is that in some cases it doesn’t matter how fast the broadband gets, that isn’t the bottleneck. More often than not it is the latency in the round trips to the servers that is making the pages slow (which is why several js files is slower than a single one with all of it merged). This makes things like sprites all the more important (though you’ll be able to get away with larger and larger files).

    The latency can’t get any better in a lot of cases as it is constrained by the speed of light over fiber and the only way to reduce it is to move the content closer to the user (aka CDN) or to reduce the impact by eliminating as many round trips as possible.

    0
  39. 39

    If you go into the webmaster tools section they have exposed some information about performance which may provide some hints. That data looks to be collected from users with the Google toolbar and appears to up to the onLoad event firing (full page loaded including html, css, js and images and from real users so no cheating for a Googlebot).

    0
  40. 40

    Oh really? Well that’s clever but now that leaves me thinking about sites where their users are more likely to be on slower connections. I dunno… sites about modem troubleshooting or something. Will they be adversely affected in their pagerank, even if their server is blisteringly fast to a broadband user?

    0
  41. 41

    Heya Chris…

    Great article!

    I am kinda surprised you didn’t mention Data: URI in this post. Data URI is a great way to make all your images into one http request, since the images are encrypted into the css file.

    I have found that it reduces http requests drastically and works great with modern browsers. (unfortunately doesn’t work with IE6 etc..)

    0
  42. 42

    yes,useful article indeed

    it’s funny because just this morning I was reading the final chapter of the Smashing Book, where it says you 2 guys never compromised on the quality and size of the images in the SM articles, and funny enough just few hours later I see (myself) for the first time images with bad quality :)

    However, content is important and your content is always good

    0
  43. 43

    And there you answered it yourself – the IE forking is a pain with data URIs (you can send mhtml to IE to get the same for the whole document – explained here: http://www.phpied.com/data-uris-mhtml-ie7-win7-vista-blues/). I am not a big fan of forking for browsers so I did not add it yet. This may not be the last performance article here, so we can come back to that :)

    0
  44. 44

    Smashing Editorial

    January 6, 2010 11:18 am

    Please understand that we actually need these ads to keep this magazine alive. To make the publication of this article possible and make it available for free, we need resources and financial support. This is why we have ads – actually, we would love to get rid of them, but we can’t, because otherwise Smashing Magazine won’t be viable.

    0
  45. 45

    Times change, load times get shorter :)

    0
  46. 46

    Smashing Editorial

    January 6, 2010 11:21 am

    Thank you, the link was updated!

    0
  47. 47

    @Mark, with all of the Ph.Ds at Google i bet they considered that people with slower connections will download slower. And rather than taking only the download time from the user they would take the file sizes and response times from the server as well to make educated estimated speed rankings…. at least i would hope so…

    1
  48. 48

    I am a hacker, I didn’t even know automated tools exist :) In Yahoo we train engineers to do the right thing from the start, saves time and money in the long run.

    0
  49. 49

    State.The.Obvious???

    January 6, 2010 1:46 pm

    What a crapload… lets put all the obvious here then… use a css reset, don’t use images, don’t use flash, don’t use gif, don’t think, don’t learn, don’t be creative…

    0
  50. 50

    Another option for the script “lazy loading” (aka, “on-demand loading”) is LABjs.

    In fact, LABjs is specifically designed to replace your script tags and load your scripts in parallel in a more efficient fashion while your page loads (though it can also be used to grab scripts on-demand at a later time as well). LABjs loads all scripts in parallel (as much as the browser will allow), but uses some “tricks” to make sure that it executes them in the proper order if you specify that there are execution-order dependencies.

    For instance:

    $LAB
    .script(“framework.js”).wait()
    .script(“plugin1.js”)
    .script(“plugin2.js”,”plugin3.js”)
    .wait(function(){
    // initialize framework and plugins
    });

    0

↑ Back to top