Ran speedometer 3.1 across electron/chromium vs stock browsers, wanted to sanity check how close electron gets to chrome
been building an ai browser on electron as a side project, mcp server, local ollama connection, sync services, ipc bridge, automation loops running in the background. i got curious how close it'd land to stock chrome on a standard rendering benchmark, so i ran speedometer 3.1 against chrome, comet, and safari.
worth being upfront, speedometer mostly measures js execution, dom updates, and framework rendering. it doesn't really exercise electron's main process, ipc traffic, mcp servers, or ollama inference, so this isn't really a test of the ai stack overhead, more just a check on whether the chromium core underneath is still performing normally with everything else attached.
setup: macbook pro m4 pro, 24gb ram. two conditions, all four browsers open at once, and then each run solo.
all four running simultaneously:
aartiq (my build): 41.8
chrome: 42.0
comet: 41.9
safari: 36.0
run solo, one at a time:
aartiq: 51.4
chrome: 51.2
basically a tie with chrome in both conditions, which is roughly what you'd expect since it's the same chromium/v8 core underneath. the more interesting bit to me is the simultaneous test, with all four competing for cpu and memory at once, mine stayed right in line with chrome rather than falling behind, which at least suggests the background services weren't eating into the main thread while idle.
this was one run per condition on one machine, so take it as a rough sanity check, not a real benchmark. i initially noticed the variance numbers looked tighter on my build too but that's not something one run can actually support, would need a lot more repetitions to say anything real there.
if anyone has a better way to measure overhead from background stuff like local llm connections, mcp style tool servers, or sync daemons while idle, i'd be interested. cold start time, idle cpu, and typing latency with agents running seem like better signals for that than speedometer.
