Some of the benchmarks listed below are also referenced in the WebKit Blog "Surfin' Safari":

• i-Bench JavaScript Processing: The primary benchmark that Apple marketing has used is the JavaScript i-Bench. It’s a bit of a pain to set up. Most of the other benchmarks listed below are easier to run yourself, but are not as realistic and comprehensive in their coverage.

• Sunspider 0.9: This benchmark from the webkit project is based on real code. Very few of the tests could be classed as microbenchmarks. It’s balanced between different aspects of the JavaScript language.

• Dromaeo is Mozilla’s JavaScript Performance Test Suite. More information can be found on the project's homepage at the Mozilla wiki.

• Celtic Kane Javascript Speed Test 2007: This popular benchmark is easy to try in the browser and covers a variety of JavaScript and DOM processing tasks.

• The Computer Language Shootout Benchmarks: Possibility to compare numerous programming languages, including different JavaScript engines (SpiderMonkey, WebKit, Rhino). Unfortunately, results do not seem to be up-to-date as they are often based on very old, outdated engines.

• pentestmonkey MD5 test: This test times various cryptographic checksums coded in pure JavaScript.

• JavaScript Raytracer: The full mode of this JavaScript Ray Tracer is a test of many parts of the browser including JavaScript, DOM and layout.

• JavaScript speed test

• innerHTML / replaceHtml speed test

• Browser speed comparisons

• innerHTML speedups for Firefox 3 beta4
• Firefox supports individual builds with Profile-Guided Optimization (PGO)

WebKit development is based on a strict performance policy :

“Performance is a top priority for WebKit. We adhere to a simple directive for all work we do on WebKit.

The way to make a program faster is to never let it get slower.

We have a zero-tolerance policy for performance regressions. If a patch lands that regresses performance according to our benchmarks, then the person responsible must either back the patch out of the tree or drop everything immediately and fix the regression.
Common excuses people give when they regress performance are, “But the new way is cleaner!” or “The new way is more correct.” We don’t care. No performance regressions are allowed, regardless of the reason. There is no justification for regressing performance. None.”.
Pretty cool, eh?

• Performance Tests for Opera 9.5 (Kestrel)

Caution: information presented here may not always be correct for all the different browsers!

• Efficient JavaScript
• Gopal Venkatesan: "Writing Efficient JavaScript"
• Julien Lecomte: "High Performance Ajax Applications"
• JavaScript Best Practises
• JavaScript Debugging Tools

• Using the Skeletons
• The Build Process
• Profiling Applications

• Caching Tutorial for Web Authors and Webmasters

• Best Practices for Speeding Up Your Web Site
• High Performance Web Sites: The Importance of Front-End Performance
• Rule 1 - Make Fewer HTTP Requests
• Rule 2 - Use a Content Delivery Network
• Rule 3 - Add an Expires Header
• Rule 4 - Gzip Components

• Part 1: What the 80/20 Rule Tells Us about Reducing HTTP Requests
• Part 2: Browser Cache Usage - Exposed!
• Part 3: When the Cookie Crumbles
• Part 4: Maximizing Parallel Downloads in the Carpool Lane

• Presentation: High Performance Web Sites
• Book: High Performance Web Sites, by Steve Souders
• Companion website for Book: High Performance Web Sites

• (German only) Die ganze Wahrheit über Client-Caches