Speedometer 3 is a benchmark for web browsers that measures Web application responsiveness by timing simulated user interactions on various workloads.
It's developed as an open source project, with decisions being made under a multistakeholder governance model between the three widely distributed web browser engine projects.
The following high level user journeys are implemented in the current version. Each of these journeys has one or more workloads which test important aspects of it — for example commonly used patterns, frameworks, or technologies.
- Working with a todo list
- Measures the time to add, complete, and remove 100 todo items in a basic list.
- Each example implements the same todo application (TodoMVC) using different techniques and frameworks.
- Workloads: TodoMVC-JavaScript-ES5, TodoMVC-JavaScript-ES6-Webpack-Complex-DOM, TodoMVC-WebComponents, TodoMVC-React-Complex-DOM, TodoMVC-React-Redux, TodoMVC-Backbone, TodoMVC-Angular-Complex-DOM, TodoMVC-Vue, TodoMVC-jQuery, TodoMVC-Preact-Complex-DOM, TodoMVC-Svelte-Complex-DOM, TodoMVC-Lit-Complex-DOM
- Editing rich text
- Loading and styling text inside WYSIWYG and code editors.
- Workloads: Editor-CodeMirror, Editor-TipTap
- Rendering charts
- Loading and interacting with SVG and canvas charts.
- Workloads: Charts-observable-plot, Charts-chartjs, React-Stockcharts-SVG, Perf-Dashboard
- Reading a news site
- Navigating across pages and interacting with a typical looking news site.
- Workloads: NewsSite-Next, NewsSite-Nuxt
Notes about methodology
- Although user-driven actions like mouse movements and keyboard input cannot be fully emulated in JavaScript, Speedometer does its best to faithfully replay a typical workload within the demo applications.
- To make the run time long enough to measure with the limited precision, we synchronously execute a large number of the operations, such as adding one hundred to-do items.
- Modern browser engines execute some work asynchronously as an optimization strategy to reduce the run time of synchronous operations. While returning control back to JavaScript execution as soon as possible is worth pursuing, the run time cost of such an asynchronous work should still be taken into a holistic measurement of web application performance. In addition, some JavaScript frameworks call into DOM APIs asynchronously as an optimization technique. Speedometer approximates the run time of this asynchronous work in the UI thread with a zero-second timer that is scheduled immediately after each execution of synchronous operations.
- Speedometer does not attempt to measure concurrent asynchronous work (e.g. in Web Workers).
- Speedometer should not be used as a way to compare the performance of different JavaScript frameworks.
- The goal of all workloads is to represent a scenario that could be found on the Web. Although all workloads strive to use patterns that are commonly used, some implementation details are Speedometer specific and should not be used as a guideline on how to implement and deploy a standalone app. For example, due to constraints within the test harness, workloads must not depend on a server infrastructure to function properly and are built as static files ahead of time.