5 ms·
A good browser benchmark would also measure: 1. Browser boot time. 2. Browser shutdown time (on clicking Close). 3. Tab boot time. 4. Tab shutdown time. 5.
by jorangreef 16y ago
A good browser benchmark would also measure:
1. Browser boot time.
2. Browser shutdown time (on clicking Close).
3. Tab boot time.
4. Tab shutdown time.
5. LocalStorage boot time (on first call to LocalStorage API, some browsers load LocalStorage into memory at this point, blocking the UI).
6. IO performance of LocalStorage, WebSQLDatabase, IndexedDB for massive get/set operations (bandwidth) and many get/set operations (latency).
7. ApplicationCache update time (and update time after an interrupted update cycle).
8. Smoothness of moving a DOM element across the screen by adjusting absolute position (some browsers are choppy with this).
9. Javascript parse time.
10. Minimum setTimeout frequency (is it 1ms or 5ms?).
11. Hash change event propagation time.
12. Stack size limit.
13. Speed of Array.shift on massive arrays.
14. Vertical height of browser chrome at top of the window in pixels (less is better).
15. Vertical height of browser chrome at bottom of the window in pixels (less is better).
16. Number of colors used in browser chrome, including favicons in location and bookmark bars etc. (less is better).
17. Fullscreen support and switch to fullscreen time.
18. Developer Console boot and shutdown time.
19. Number of words, tabs, nested interfaces used across all Preferences pages (less is better).
20. Number of user actions (clicks, keypresses, mouse movement distances) required to clear LocalStorage, History, WebSQLDatabase, IndexedDB, Cache, ApplicationCache (less is better).
21. Default storage limits for LocalStorage etc. (higher is better).
22. Data-URI size limits (higher is better).
- fliph 16y agoAgreed that most of these would be good components of an overall browser benchmark, but the linked benchmarks are JavaScript benchmarks only, so things like browser start-up time and chrome dimensions wouldn't apply.
- jorangreef 16y agoWhen users think "fast", they think "fast" as in "fast", not "JM fast" or "TM fast". It would be better for "arewefastyet.com" to address "fast" from the point of view of the user rather than from the point of view of the Javascript engine developer.
- fliph 16y agoAs I understand it, arewefastyet.com was created as more of an internal/community dashboard specifically for the JIT team at Mozilla rather than to reflect on the browser as a whole to the userbase.
- benologist 16y agoI think 1 - 4 were what really kickstarted Chrome. Everyone else was focused on how many milliseconds difference between their rendering and js vs. the next guys, when Google shaved whole seconds off something that really matters.
- ootachi 16y agoMozilla measures many of these at http://graphs.mozilla.org/ http://graphs.mozilla.org/. "Ts" is startup time; "Tshutdown" is shutdown time; "GFX" includes 8 I believe.
- jchonphoenix 16y agoAccording to my friends that work at Mozilla, this site is purely for javascript speed and is what Mozilla uses as an internal motivator to motivate employees. Its a line everyone works to hit. Its not really a "benchmark" to show the world that they're doing better. It's a public site because everything that happens in mozilla is open, but it's not really for us to see and judge. Its for the guys on the inside to see and cheer or see, then haul ass to catch up.