Performance Testing

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.

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.

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.

We have a number of benchmarks that we use to measure performance. You can find the benchmarks WebKit uses for performance testing at browserbench.org.

Get Involved!

How can you help improve WebKit’s performance?

Test for Regressions

If you have your own performance tests, run WebKit through them daily. Make sure that the performance of the sites you care about does not regress. Test the above benchmarks on your hardware to help double-check that there have not been any regressions. Remember, the best way to stay fast is to never let your code become slower.

Open Source Benchmark

We have discussed with Mozilla and Opera the idea of an open-source cross-browser benchmark. The stumbling block to the construction of such a test suite is that we need to get buy-in from high profile sites like Google, Amazon or Yahoo to use snapshots of their front pages in the benchmark. The benefits of having your site in such a benchmark are obvious, since browser vendors will make your sites faster as they optimize for the content of the benchmark.

If you work for one of these high profile sites we encourage you to contact us if you are interested in having your company contribute content to such a benchmark.