One of the biggest obstacles to tackle in web site and web application design is the initial response time of the product. There is a common feeling among web users that things just don’t happen fast enough.
Why is this such an issue? Perhaps people who’ve been using the web for years remember the times when we had to pay by the minute (in the way that hotel or airport users do even now), or there could be just a general feeling of being let down by the promised information superhighway. I think in part it’s Hollywood’s fault: in every action flick there are high-resolution, data dense animated web interfaces that show up at the touch of a button, and encyclopaedic data gets loaded and displayed in a matter of milliseconds.
In real life it is simply not the case, because no matter how much you try to streamline your pages, there are always delays. In the case of a web site, apart from the general lag, it is often a cosmetic issue - especially when there are flashes of unwanted content. With web applications it can be more problematic as you have to make sure that visitors cannot activate interaction elements prematurely and break the app.
What makes web sites slow?
Whenever talk comes to the speed of web sites the biggest trick usually advertised is to cut down on the file size of everything (this also leads to endless - and fruitless - discussions about the size of JavaScript libraries [*edit]). In reality, there are many more factors that play a part in the initial response time of a web page:
- The file size of the HTML document
- The file size of the dependencies in the document (scripts, images, multimedia elements)
- The complexity of the HTML (simpler pages are easier to render for the browser)
- The speed of the connection of the user
- The speed of third party servers as content may be pulled and included from them
- The response time of the DNS servers resolving the domains and pointing you to these other servers
- The responsiveness and speed of the visitors’ computer (how busy is the machine with other tasks - as that impedes on the rendering time of the browser)
- The responsiveness of the server
These are the technical parts of the equation. Then there is also the human factor. Web pages are considered to be not fully loaded until they show up and don’t “jump around” or “have no loading images”.
Things to do to make web sites faster
There are some well-known general best practices you can follow to overcome some of these technical and human factors and ensure a quick response web site:
- Optimize all the HTML and dependencies as much as you can without losing quality (this can include stripping the HTML documents of any comments and superfluous linebreaks, which should be part of the publication process. In order to keep sites maintainable you still need those in the source documents)
- Reduce dependencies by using the least amount of file includes (collate several scripts into one include, use CSS sprite techniques to load all images at once)
- Make sure that you don’t include third-party content from their servers: set up a script that caches RSS feeds locally and use that one instead. The benefit is not only that you don’t have to deal with the DNS server delays but you are also independent of the other server should it go down.
- If possible, define dimensions for images and their container elements. This will ensure that the first rendering of the page will be correct and there won’t be any “jumping around” when the images are loading.
- Include large dependencies such as massive scripts at the end of the document, as this means that the rest of the page gets shown before the browser loads them. Large JavaScript includes in the head of the document mean that the browser waits with rendering until they are loaded.
Best practices vs. special speed requirements
Unfortunately some of these tricks clash with what we consider best practices in web development. Cutting down on the number of included files for example impedes maintainability of the product. In order to make it as easy as possible to maintain the look and feel of a site with different pages (home, articles, archive…) it does make sense to keep the different styles in own includes and only add them to the pages that really use them. You could have one base CSS include and then one for the homepage, one for articles and so on.
The same applies to scripting - keeping methods that do the same job in their own JavaScript includes makes maintenance a lot easier, as you know immediately where to find a certain method without having to scan the whole script. Furthermore, adding scripts inside the body of the document is dirty as it mixes the web development layers structure and behaviour.
Luckily there are technical solutions for most of these problems.
Using single includes for several style sheets or scripts
One solution, written by Edward Eliot, is a PHP script that does the job of collating several scripts or CSS style sheets into a single file. In the case of JavaScript it even cuts down on the size of the script using Douglas Crockford’s JSmin. The script is dead easy to use and will cache the collated file for you until you change one of the files included in it. This means that your files are automatically packed, cached and the include file updated when you change them. You get the best of both maintenance and speed without having to change anything by hand.
Mission almost possible: tackling the onload problem
One other really big issue is that unless you embed your scripts in the body of a document you’ll have to start them when the document has finished loading. This results in a slight delay, and can cause problems.
The delay is caused by the way browsers load, parse and render documents. If you call your scripts with the onload event on the window, all of these following steps will have to be finished:
- HTML is parsed
- External scripts/style sheets are loaded
- Scripts are executed as they are parsed in the document
- HTML DOM is fully constructed
- Images and external content are loaded
- The page is finished loading
In a lot of cases, this takes far too long and needs to happen a lot earlier. Many clever web developers are tackling this issue and every so often a new answer to end the quest for a solution gets released. Most JavaScript libraries have an onAvailable or onDocumentReady event handler that starts the script as soon as parts of the document are loaded rather than the whole lot including images. In practical and admittedly hard-core testing with older browser and operating systems none of them really turn out to be bullet proof though. However, we are all on the case and with luck we’ll get there eventually.
For web applications where a premature activation of elements can result in a failure of the app this is absolutely vital. If your problem is of a cosmetic nature, there might be a workaround.
Avoiding the on-load problem with on-demand pulling of content
Most cosmetic on-load issues are caused by overloading the document with far too much content. This could be massive amounts of text displayed in a tabbed interface or a navigation that is four levels deep. With JavaScript enabled and executed without a glitch, this content can be navigated and displayed in a dynamic fashion and easily digestible chunks. When you turn off JavaScript and see the whole document unstyled it can become a real pain to find your way through it and that is never a good plan. This extra content also adds unnecessarily to the page weight of the initial load.
The solution is to use JavaScript to load the content only when the clever interface can be offered to the user. Users without JavaScript would get a plain vanilla version that only has the most necessary elements and content.
Which techniques you use to pull this extra content will depend on what you try to include. The easiest option is to use a dynamically generated script tag. This is an old trick that was used to pull in large JavaScript data sets or scripts on the fly when the page was loading:
function pull(){
var s = document.createElement('script');
s.type = 'text/javascript';
s.src = 'largeJavaScriptBlock.js';
document.getElementsByTagName('head')[0].appendChild(s);
}
window.onload = pull;
This trick can also be used to include output of APIs that support JSON, for example del.icio.us. As a JSON object is nothing but a chunk of JavaScript you can include this with a generated script tag when the document has already loaded and is displayed to replace an element with this content. The wrapper object Dishy allows you to do this easily. Another example is the unbobtrusive Flickr badge that uses the JSON output of Flickr to show your latest photo when JavaScript is available but only a link to them when it is turned off.
In order to include non-JavaScript content you can use Ajax or AHAH or Hijax or whatever you want to call Ajax without the XML part! An example for this would be the optional Ajax navigation which goes even further as it only loads the more complex interface when the visitor wants it.
Imaging trickery
The last idea stems from a time that may just have been before you even started developing for the web! Netscape, the ill-fated (but IMHO at that time better) competitor to Internet Explorer during the browser wars had a custom HTML attribute for images called ‘lowsrc’ which enabled you to define an image that was of much smaller file size than the real one and was loaded first and then covered by the real one while it was loading. This allowed you to give even users on ridiculously slow connections a preview of what there is to come.
You can re-use that idea and not embed large mood imagery in the page when it is loading initially but use more stylized, lighter images that get replaced with the others once the page has been loaded. Or you could go even further and only use background colours at first. You then use JavaScript and the DOM to load the real image when the document has finished loading and cover the preview with it.
This trick can also be immensely effective when you include lots and lots of smaller images from several servers (like gravatars for example) as these are not likely to be cached. Simply use a placeholder graphic initially and replace them with dynamically created images when the page has loaded.
Summary
This is of course only an overview of what is possible, but I hope some of the suggestions make sense and will help you change your site or app to make it more responsive. If you have more tricks, don’t be shy - comment about them.
Like this article? Digg it!
Great article with a lot of good tips (and good links). Also enjoyed your recent Event-Driven Web Application Design article over on the YUIBlog.
Little surprised that Edward Eliot didn’t mention some gzipping javascript techniques but a good reference nonetheless.
Looking forward to more. Cheers.
I am sorry, but there has been a misunderstanding. I originally linked the sentence about fruitless discussions comparing the size of JavaScript libraries to an article on the YUI blog explaining the size of the YUI library.
This gave the impression that I considered this article a fruitless effort, which is completely not what I tried to convey. The article was necessary because of several comparisons of the YUI to other libraries and claims that it is too big. The original discussions only took file size as the only means of comparison, and this well-researched and written article proved both the claims and the methodology of comparison wrong.
I haven’t played with the idea of putting scripts before the end of the page, but it makes perfect sense. Caching the CSS and putting them into one file is a great way to keep things tidy for the end user, without messing up your development platform. I use @import for stylesheets, and it brings in 4 other stylesheets (normalize, typography, layout, and color). This helps during development - but can be a bear for the end user and the multiple requests. I wrote a script similar to the one you mentioned in the article, that combines the CSS into one file - strips comments and unnecessary whitespace, and then caches that file for use. I am going to implement this on several other sites as well to help with page load.
I think another important aspect is not including everything under the sun if you don’t need it. I like the JS libraries, but do you really need to include 50k+ of libraries to get that pretty bind up/down effect? Not saying they are bad - but make sure you use what you need.
When it comes to the actual HTML - I like to keep the semantic structure and use the Cascade as it should be used. This eliminated unnecessary classes/IDs/divs/spans, etc - and lets me use them for things like Microformats (Reviews, XFN, cards, and calendars) - where they actually give meaning to the content.
I think there are many things at the server level you could do as well to tidy things up. I think the biggest barrier to minimizing everything is time. We need things pretty for our development, but when it’s being sent to the user - it just needs to work as quick as possible. Looking at your server, caching options, requests, etc is a good start to reducing load and requests.
Im rambling now….excellent article!
[…] Good idea Jordan; in fact I found a CSS merging script by Edward Eliot (thanks to Vitamin for the link from the article Enhance your (page) performance!) that I’m going to have to look into … […]
Very interesting article, definately a good read.
However, I do not entirely agree with the methods Christian recommends.
First, recent research has proven without a doubt, that reducing the amount of requests to the server will have very significant impact on the rendering speed in modern browsers, yet the author still recommends adding scripts to a page dynamically and when the onload event fires. This goes against the advice to reduce the amount of requests to the server.
Second, do consider that when you’re “optimising” your output from the server by stripping whitespace and optimizing your scripts with tools as JSMin, that you are in fact not getting the exact same output that you get from your development servers. You can get some nice improvements from doing so, but you will also have to have some very nice tests in place to ensure that everything is still as you expect them to be. Before taking such measures, I’d rather be recommending that you use gzip + caching, to deliver content to the clients faster. Once that’s in place, you then can start looking at the more “expensive” optimisations.
Third, as Chris and I have discussed elsewhere, there are different views on putting script tags within the body elements. My view is that scripts have no place in the body element, as you’re mixing content with behaviour. Techniques to overcome the load problems are plentiful, and if you combine them with decent caching and content compression, you will see speed improvements across your site, and not just on the single page you’re burdening with script in the body tag.
Fourth, using low bandwidth images and then replacing them with higher resolution images …. hmm… that would add more scripting, double the amount of requests to the server, and use more bandwidth. Not really much of an improvement, neither for the server, the carrier or the user.
The client optimisation debate has been going on for years now, and it’s always nice to see some fresh perspectives on it.
Or offload images to a fast server like cod systems like Askimet
[…] If you work on large sites like I do, you may find the recent article from Christian Heilmann helpful over on Vitamin. Christian lists some useful techniques to optimize your site’s performance. For instance (emphasis added): Include large dependencies such as massive scripts at the end of the document, as this means that the rest of the page gets shown before the browser loads them. Large JavaScript includes in the head of the document mean that the browser waits with rendering until they are loaded. […]
Congratulations Chris for this well-written article about a topic that became hot mostly because of Yahoo’s research and sharing their knowledge. I really appreciate that attitude. There is a slight overlap with my recent article about performance that could make interesting complemental reading.
[…] Web sayfalarımızı daha hızlı ve hafif yapmanın yollarını anlatan makale. Link […]
yo I tried this on my website and it works well
http://rarara77.googlepages.com/
[…] Enhance your (page) performance! […]
an interesting read!
how does this affect conditional statements for browser specific, or media specific style sheets? I don’t really understand php, so I don’t really know. A good article none the less, all the kids should read it.
I still think the most efficent technique is to reduce number dependencies and avoid too many javascript widgets.
What I don’t like is doing the optimisation in the web development. It should be something for the “sysadmin” to worry about so to say. It’s hard enough as it is.
I’ve blogged about a solution where I’ve combined Squid caching proxy + gzip + whitespace stripping all in O(1) here: http://www.peterbe.com/plog/gzip-and-slimmer-optimization
The end result was that I was able to transform my 15Kb screen.css at 242 requests/sec down to 2.7Kb at 2680 requests/sec without changing ANYTHING for the poor guy (me actually) maintaining this file.
[…] Enhance your (page) performance! Page loading is probably the single biggest turnoff for first time visitors. Here are some tips for web developers. (tags: optimization pageloading) […]
Some interesting issues discussed here. Although the article primarily focuses on client-side issues, I think it is worth mentioning that slow sites can also often be a result of poor database optimization, sites that “outgrow” their infrastructure and poorly written server side code. No amount of client-side optimization will be much help in these cases!
The response time of the DNS servers resolving the domains and pointing you to these other servers.
What is the range of a good response time?
[…] Enhance your (page) performance! Sluggish internet speeds may be a thing of the past, but instant page loads are still the stuff of the future. Christian Heilmann has some tips for delivering faster, smoother pages to your visitors today. […]
The article is rather interesting Christian. As you said at the end of it, you aimed to provide an overview of what is possible and to that end the article has served it’s purpose. In my opinion I see the issue of enhancing page (load) performance (on the client-side) as being tied to the following:
The size of the actual HTML/XHTML pages being served. With modern browsers providing relatively mature implementations of the recommended W3C standards, we (developers) should aim to develop pages that are as lightweight and semantic as we can make ‘em. The smaller the size of the HTML/XHTML the faster it loads.
The total size of all media files (images, video, flash movies, etc.). Aside from the obvious point of optimizing your images for the web, basic CSS techniques can be a great help. These include specifying background colours when styling background images or, as you touched on Christian, using background colours at first then using JavaScript and the DOM to load the real image when the document has finished loading. I really don’t like the idea of using low bandwidth images and then replacing them with higher resolution images (I’m with Morgan on that one) since in my opinion that adds unnecessarily to the overall load and increases bandwidth usage.
The total size of script libraries. You touched on some good options for lowering the impact of large JavaScript libraries on load performance. I also agree with Nate that you shouldn’t include everything under the sun if you don’t need it! The YUI for example has taken quite a beating from a number of developers
who claim it to be “bloated”. But the highly modularised framework architecture of the YUI promotes a “use what is needed” approach, at least in my opinion.
The point at which JavaScript is parsed. In Martin’s article he makes a very important point that parsing JavaScript in the head of the document will slow down the speed of the initial page load because web browsers “freeze” when they parse JavaScript, that is, they do not render any more of the page until the parsing is finished. I’m not sure how many developers realise the significance of this but the speed at which content becomes visible when loading a page can be given a significant boost in some cases by simply parsing JavaScript libraries at the end of the body rather than in the head.
The total size of external and inline CSS. Collating, caching and delivering multiple external CSS files as one “server ouput” can help improve performance as you pointed out Chris. Compressing or “packing” the output can indeed take it a step further.
Like I said these are what I see as the issues to be considered on the client-side of the web site / web application. I’ll leave someone else to talk about the server-side techniques (other than the ones already mentioned of course :-) ).
Great article and really good to see stuff getting published about efficiency and optimisation.
A couple of people have been down of the “lowsrc” image concept due to increase in server requests and extra scripting. A couple of quick thoughts:
1. This doesn’t necessary require scripting. A simple technique is to load the placeholder as a background of the main image via CSS (this assumes the image you’re replacing isn’t itself a background - for that you would need scripting?). The high-res version then progressively ‘draws’ over it. The additional CSS is minimal.
2. In terms of extra server requests, obviously this is a solution which isn’t always applicable. Used inappropriately it could slow things down yet more. It’s mostly relevant to large, high-res images, e.g. photos. Christian’s example of a page which loads multiple gravatars is also a good one. You could use a single , simple placeholder image for all the gravatars while they load. This way you’ve added only a single extra request, and one extra small file, but gained a perception that your page is ‘done’ long before all the gravatars have loaded.
Which leads me to…
3. Although using this is going to add some extra code and server requests, the advantage is in the perception of load speed by the visitor. Sometimes people’s perception of how fast a page loads is different from how long it actually takes if you put a stopwatch on it. You can employ techniques - like delaying script loading until the rest of the page has rendered - to give the visitor quick access to content and functionality, while other processes to continue in the background. The perception is that the page has loaded faster than it really has.
[…] Enhance your (page) performance! […]
[…] I’m still in awe how fast one of my own websites became! Thanks to the guys at Yahoo! for the inspiration and for most of the research this article is based upon. Even JSMin was written by an employee of Yahoo! Speaking about Yahoo! employees: Chris, I hope there are still enough topics for your Vitamin article. I wanted to write about performance anyway, and to my surprise I read yesterday that you have similar plans. See ya in Paris. […]
[…] Es ist unsinnig, sein Markup mit leeren Elementen vollzupflastern. Lies: Vorsprung durch Webstandards | Retro-Coding: Semantischer Code ist der Anfang von gutem Design Und wenn du glaubst Traffic sparen zu mssen, dann lies: Vitamin Features Enhance your (page) performance! Lass das Geschnipsel bleiben. […]
People I wander if anybody tried to use YUI trees with contextmenu.If yes please tell why I have problem with contextmenu event when I add a node to tree.I didn’t see the right click menu’s on the other nodes but when I tried to add menu to it It didn’t work properly,like has already such an event on that node.
Thank you very much.
One of the things that i’ve done in my sites(PHP) is this:
Short list of tasks
1. Use a framework. Attach all JS and CSS files you want for this particular page to the framework.
2. When rendering the page: Combine the array into a hash. Check to see if this hash file was allready build. If so, loop the array to see if any of these files have been changed.
3. Combine all files (JS or CSS) into 1 file.
4. In case of JS; use Dean Edwards Packer to compress that one, large combined file and stream it to disk.
5. In case of CSS; clean it up (remove comments and newlines) and also write this to the disk.
6. Inject the contents of these 2 files into the of the resulting file.
Result:
This resulted in a 300kb page (including css and js files) with approx. 18 includes to shrink to a 37kb (gzipped) page with no includes. Page load dropped from 3 seconds to 1 second. (Almost instantly).
Another advantage is that the CSS and JS files are re-build when something changes. So i can keep my comments and edibillity!
[…] Link […]
Good site! kabababrubarta
[…] Read Enhance your (Page) Performance […]
[…] Listan viimeinen sija on jaettu. Christian Heilmannin artikkeli Enhance your (page) performance! (Vitamin Features) antaa hyviä, joskin aika teknispainotteisia vinkkejä sivuston latausajan pienentämiseksi. Toisaalla Scientific American kirjoittaa lyhyesti italialaisesta sosiaalisiin kirjanmerkkeihin perehtyneestä tutkimuksesta: Tag, You’re It: Scientists Describe Collaborative Tagging Sites like Del.icio.us. […]
[…] Zitat von andir Meiner Erfahrung nach reicht es z.B. meistens aus, wenn jpegs nicht mit 100% Qualitt ( = unverndert), sondern mit 55% bis 65% (Qualittsrate nach Komprimierung) ausgegeben werden. Teilweise gehe ich bis auf 30% runter; je nach Bildgre und Bildinhalt reicht selbst das noch frs Web. Mir ber "Farbtreue" bei Webgrafiken Gedanken zu machen, habe ich aufgegeben, seit ich an mehr als 3 verschiedenen Monitoren teste Noch eine Anmerkung zu Ladezeiten: Chris Heilmann empfiehlt in einem Vitamin-Artikel die Verwendung von Techniken wie CSS-Sprites, statt vieler Einzelbilder, um die Zahl der Anfragen zu reduzieren. Zitat: […]
One of the sites i manage has thousands of pages, what i done was create a very simple cache system which increased speeds by an enormous amount, also reduced database requests, bandwidth and generally is an essential tool on pages that do not need to change all of the time.
[…] Re pour la route, je vous recommande à nouveau la lecture de l’article “Enhance your page performance” sur Thinkvtitamin.com : c’est là-dessus que j’ai piqué toutes mes idées […]
[…] Follow any comments here with the RSS feed for this post. Post a comment or leave a trackback: Trackback URL. «ศัพท์ภาษาอังกฤษ […]
Manual semi-trackback: Load time, the UX factor: Facts and measures.
hello all,
I am making a site. I want that my graphics and menubar remain unloaded and the contain on middle
part of page should change. I want to do it without using frames.Can anyone suggest any idea or tips ?
Thanks for you consideration
bye
[…] http://www.glazkov.com/blog/client-side-performance-tip/ http://www.vandelaydesign.com/blog/design/designing-pages-to-load-quickly/ http://paulstamatiou.com/2007/07/25/how-to-optimize-your-site-with-image-sprites/ http://www.thinkvitamin.com/features/dev/enhance-your-page-performance http://learningtheworld.eu/2007/performance/ http://meiert.com/en/blog/20070621/load-time-the-ux-factor-facts-and-measures/ http://immike.net/blog/2007/07/24/css-redundancy-checker/ PreviousTags: Web HostingCategory: Internet, Technology Get RSS Feed Email This Post […]
[…] you mean just before </body> right?? there was a presentation done at @media by someone which i now can’t find, but this will get you started if you’re interested why i’ve just said that. Vitamin Features Enhance your (page) performance! __________________ Are we there yet? […]
[…] read more | digg story […]
[…] This is a good read after the article from Christian Heilmann’s article: Enhance your page performance. […]
[…] This is a good read after the article from Christian Heilmann’s article: Enhance your page performance. […]