A new speed milestone for Chrome(blog.chromium.org)
blog.chromium.org
A new speed milestone for Chrome
https://blog.chromium.org/2022/03/a-new-speed-milestone-for-chrome.html
160 comments
> I think that browser developers are optimizing the wrong thing.
> You might ask, what about modern websites [...] I am not using such sites so I don't care.
They might be optimizing the wrong thing for you, but the majority do use "modern sites"
> You might ask, what about modern websites [...] I am not using such sites so I don't care.
They might be optimizing the wrong thing for you, but the majority do use "modern sites"
> You might ask, what about modern websites, built with D*t compiled to webassembly, GPU acceleration, reactive frameworks, material design and capable to load the multi-core CPU at 100%? I am not using such sites so I don't care.
Does this just mean that browser developers are optimizing for the right thing, just not something that benefits you? Tons of people use these sites.
> If the system starts swapping, it becomes orders of magnitude slower.
Not really. Browsers try to keep stuff in swap that they probably won't need. Swapping doesn't become a problem until you're almost out of memory as well, and then you might get thrashing. But there's a wide range where CPU optimizations make sense. And such a large fraction of people have SSDs that even swap access can be pretty fast.
Does this just mean that browser developers are optimizing for the right thing, just not something that benefits you? Tons of people use these sites.
> If the system starts swapping, it becomes orders of magnitude slower.
Not really. Browsers try to keep stuff in swap that they probably won't need. Swapping doesn't become a problem until you're almost out of memory as well, and then you might get thrashing. But there's a wide range where CPU optimizations make sense. And such a large fraction of people have SSDs that even swap access can be pretty fast.
There are over 3B devices using Chrome as browser. 2.5B of them are either on Laptop, Smartphone or Tablet. Average Opened Tabs is still under 5.
As much as I want them to optimise for memory usage. Taking less CPU time for rendering is extremely important for battery.
Not to mention faster site is noticeable. And that is what sells. Chrome was faster than everything else when it launched. ( May be apart from Opera )
As much as I want them to optimise for memory usage. Taking less CPU time for rendering is extremely important for battery.
Not to mention faster site is noticeable. And that is what sells. Chrome was faster than everything else when it launched. ( May be apart from Opera )
How do you know that isn't just measuring that most people keep to 5 tabs because otherwise everything grind to a halt. That's about how many tabs my wife's old Chromebook can handle before she has to start closing old tabs.
I am assuming it grind to a halt because it is CPU bound and not Memory bound? In that case the premises of CPU optimisations are not important would be, inaccurate?
In reality it is complicated when we have extra CPU cycle to burn developers tends to put fancy new things. Which is basically what andy giveth bill taketh away.
In reality it is complicated when we have extra CPU cycle to burn developers tends to put fancy new things. Which is basically what andy giveth bill taketh away.
Probably "everything stops" because tabs consume too much memory and OS starts swapping data to disk.
It's because she runs out of memory and it starts swapping, I check the task monitor or whatever it is called in chrome. Some of the AdBlock extensions are taking up ram as well.
Well all know what the "solution" here is: to have multiple browser vendors, each optimising for something else. Imagine having a lightweight browser ran a bit slower but could run on a potato with 512MB or RAM. Or one that optimises for viewing static documents (you know - websites) and so uses barely any CPU when idle, but might not support all the crazy JS features.
Of course, having turned browsers into virtual machines, there isn't much specialisation that can be done without breaking things. Might it be time to create a subset of features that sites could limit themselves to and allow browsers to use a simpler and faster render pipeline? You know, like what we thought AMP was going to be before it turned out to have Google's monopolistic shit smeared all over it.
Of course, having turned browsers into virtual machines, there isn't much specialisation that can be done without breaking things. Might it be time to create a subset of features that sites could limit themselves to and allow browsers to use a simpler and faster render pipeline? You know, like what we thought AMP was going to be before it turned out to have Google's monopolistic shit smeared all over it.
Of course, having turned browsers into virtual machines
The laptops with 2 or 4 Gb of RAM (e.g. Chromebooks) are also likely to have Celeron or MediaTek CPUs which might struggle much more than that, also unless you have multiple tabs open 4GB of RAM might not be that bad.
And given a choice between being able to open several tabs all of which are barely functional and being stuck on a single website at at time which runs smoothly I'd definitely choose the later (of course the tradeoff is probably not as straightforward, then again it's not completely obvious to me that optimizing for speed would necessarily result in higher memory consumption).
IMO even if they are optimizing for Macs, I'm not sure this approach would make sense (assuming the tradeoff between CPU performance and RAM usage exists) since they are much more likely to have less memory and better CPUs than PC laptops (e.g. you can probably easily get a Windows laptops with 32GB for $1000 or less).
And given a choice between being able to open several tabs all of which are barely functional and being stuck on a single website at at time which runs smoothly I'd definitely choose the later (of course the tradeoff is probably not as straightforward, then again it's not completely obvious to me that optimizing for speed would necessarily result in higher memory consumption).
IMO even if they are optimizing for Macs, I'm not sure this approach would make sense (assuming the tradeoff between CPU performance and RAM usage exists) since they are much more likely to have less memory and better CPUs than PC laptops (e.g. you can probably easily get a Windows laptops with 32GB for $1000 or less).
The reason for the focus on CPU time is that it has the larger impact on battery life.
You'd be surprised (I was), but high memory usage is also a power drain.
So is the screen, keyboard, WiFi/ethernet adapter...
Do you have any graphs/charts/tables to substantiate the claim that high memory usage is power hungry enough to be optimized for vs CPU?
Do you have any graphs/charts/tables to substantiate the claim that high memory usage is power hungry enough to be optimized for vs CPU?
That sounds unlikely since DRAM is all refreshed constantly regardless of whether or not it is being used.
Perhaps you meant storing and fetching from memory lots impacts battery life?
Perhaps you meant storing and fetching from memory lots impacts battery life?
With higher memory usage you have less free memory for caching so you hit the disk/SSD more often. If it gets too high you start swapping which is really bad.
It isn't a surprise when you consider indirect power costs: CPU use filling that memory and reading it back later, extra IO because the memory consumed is not available for caching purposes (or worse because paging out to more power-expensive storage is happening), and so forth.
It is like when people say page fragmentation in SQL Server isn't important any more because random access is so fast due to SSDs and other IO subsystem improvements – pages are held in RAM in the storage format so if they are only ⅔ filled you are wasting ⅓ of the allocated memory which can have significant performance effects if your common working set is not smaller than the memory available. Though in fairness, I would agree that this issue is usually quite far down the list of things that need addressing in poorly performing database & applications.
It is like when people say page fragmentation in SQL Server isn't important any more because random access is so fast due to SSDs and other IO subsystem improvements – pages are held in RAM in the storage format so if they are only ⅔ filled you are wasting ⅓ of the allocated memory which can have significant performance effects if your common working set is not smaller than the memory available. Though in fairness, I would agree that this issue is usually quite far down the list of things that need addressing in poorly performing database & applications.
If you improve CPU performance, you can compress memory with the leftover cycles. This is what I do on my RPi which allows me to run quite a few memory hungry processes at the cost of some CPU (which is fine, because those processes are mostly idle).
> Optimizing for speed usually causes increased memory consumption,
Lol, no?
If your benchmark is memory bound, reducing memory usage is probably the simplest way to make it faster.
Lol, no?
If your benchmark is memory bound, reducing memory usage is probably the simplest way to make it faster.
There are some truly memory-bound problems, but I believe the parent comment is correct on average. A lot of common speed issues can be helped by: adding a cache, adding an extra lookup index, memoising calculated values, adding a new denormalised data projection, etc. I think "usually" was a fair description.
I agree 100% -- and, as a front-end developer for more than half the time I've been writing code for web applications since 1995, I think my opinion should matter. I've seen the trends and can relate to exactly this point. Well-stated and, frankly, late to the public eye (but, that's my fault since I should've written something similar years ago).
Man, that math did not make any sense at all. A program can't use 10% of the CPU. It either uses the CPU or it doesn't. If a page renders with "5% CPU" measured over some interval that means it rendered twice as quickly, which is a substantial improvement.
They optimised mostly for startup time, not execution speed.
Java for example uses runtime VM information before it starts compiling classes to machine code. That means it's faster in the long run, but requires a 'warm up time'. Obviously a bit better for server side.
Java for example uses runtime VM information before it starts compiling classes to machine code. That means it's faster in the long run, but requires a 'warm up time'. Obviously a bit better for server side.
Use tabsuspender for that. It saves memory by suspending the tabs which is not used for quite some time.
... and some of us disable swap to prolong laptop-motherboard-soldered-SSD lifetime, and Windows 10 regularly bluescreens when memory is exhausted and swap is disabled.
I disagree. Memory is cheap. Battery life isn't.
DDR5 prices would disagree with you.
Plus, most laptop manufacturers rip you off for every RAM spec bump. $400 - $500 to go from 16GB to 32GB?! They can f--k right off!
Not everyone is making six figure SV salaries to not flinch at these prices. That's why I love the framework laptop.
Plus, most laptop manufacturers rip you off for every RAM spec bump. $400 - $500 to go from 16GB to 32GB?! They can f--k right off!
Not everyone is making six figure SV salaries to not flinch at these prices. That's why I love the framework laptop.
> $400 to go from 16GB to 32GB?! They can f--k right off!
That'd be 90-150€ for upgrading average Thinkpad for me, depending on starting configuration.
That'd be 90-150€ for upgrading average Thinkpad for me, depending on starting configuration.
[deleted]
You cannot install "cheap" memory into older laptops. Battery life doesn't matter for laptops as they are mostly used at home.
High memory consumption eats battery life too
Given that only one of those components tends to have active cooling as a requirement, I'll assume that the difference in energy consumption is at least an order of magnitude. Happy to be proven wrong though.
Even in the lowest power consuming of sleep modes volatile RAM still needs to be constantly refreshed, so considering a device with a duty cycle like that of a phone or tablet you might find the power being used for memory is more significant than you think. But that refresh is essentially a fixed cost from a software PoV, if the memory is not used it'll still be refreshed, where chunks of modern CPUs can be almost completely turned off when not needed. There are secondary costs of extra memory use though (CPU to populate & later read, IO subsystem activity as there is less free memory for cache, etc.).
Actually memory isn't that much cheap, at least not in a third world country. As browsers are going to be used by everyone, memory optimization is necessary.
I have two identical laptops, one with 8 GiB and the other with 32 GiB of RAM.
The former lasts over 2 weeks in S3, the latter not even a week.
The former lasts over 2 weeks in S3, the latter not even a week.
Identical as in model, hw and configrations except memory?
Don't forget age. Battery age is gonna have much more of an effect than subtle hw configuration differences.
There are certainly lots of situations where one browser beats another
For example in this microbenchmark, Chrome is 10x slower than both FF and Safari at one method.
https://jsbenchit.org/?src=cfcb916dd03df45952183e6484a14344
Here's another where in one case Firefox is 54x faster than Chrome
https://jsbenchit.org/?src=beb26575ad78caa99a2a8c45ce2b780f
For example in this microbenchmark, Chrome is 10x slower than both FF and Safari at one method.
https://jsbenchit.org/?src=cfcb916dd03df45952183e6484a14344
Here's another where in one case Firefox is 54x faster than Chrome
https://jsbenchit.org/?src=beb26575ad78caa99a2a8c45ce2b780f
Here's a conundrum. Fabrice Bellard's QuickJS engine takes 3 minutes to run the test262 ECMAScript conformance suite. d8 takes 37 minutes to run test262 according to https://medium.com/compilers/testing-the-v8-javascript-engin... and it crashes for me in Chrome https://v8.github.io/test262/website/default.html Has anyone else observed this performance disparity? Could it really be possible that a JavaScript engine written by one guy is 10x faster for everyday code than the flagship product of a flagship company? Because if that's the case it'd make Fabrice Bellard the Han Solo of programmers.
I think Fabrice Bellard (ffmpeg, qemu, Bellard's formula, quickjs, tinygl, tinycc), could _already_ be considered the Han Solo of programmers.
Fabrice shot first!
I wrote a small lisp in Rust. I try to not do obviously stupid things, but it's just a basic parser + AST interpreter; its execution speed is slow compared to even a basic bytecode interpreter, and it's absurdly slow compared to a JIT. Yet it runs hello world in a fraction of a millisecond, whereas V8 needs tens of milliseconds.
In executing one computationally intensive program, V8 would be many orders of magnitude faster than my program. But in a test which largely consists of running tens of thousands of small, uninteresting test case programs, my silly interpreter would outperform V8 by orders of magnitude.
Essentially, performance is complicated, and improving throughput often has costs in other areas.
In executing one computationally intensive program, V8 would be many orders of magnitude faster than my program. But in a test which largely consists of running tens of thousands of small, uninteresting test case programs, my silly interpreter would outperform V8 by orders of magnitude.
Essentially, performance is complicated, and improving throughput often has costs in other areas.
[deleted]
test262 is a conformance test and as such mostly runs small test-snippets once to verify, what counts here is setup, parsing and first-run execution.
While V8 has added a fast first-stage interpreter there are probably a ton of other overheads when starting a V8 context as well as "inefficiencies" related to preparing code for later JIT optimizations.
So for more CPU intensive code written in JS where the JIT activates the tables shifts radically, compare QuickJS with V8 (JIT-less) and V8 (JIT) on benchmarks, particularly Raytrace, Crypto and NavierStokes that should be pushing the computation performance. https://bellard.org/quickjs/bench.html
While V8 has added a fast first-stage interpreter there are probably a ton of other overheads when starting a V8 context as well as "inefficiencies" related to preparing code for later JIT optimizations.
So for more CPU intensive code written in JS where the JIT activates the tables shifts radically, compare QuickJS with V8 (JIT-less) and V8 (JIT) on benchmarks, particularly Raytrace, Crypto and NavierStokes that should be pushing the computation performance. https://bellard.org/quickjs/bench.html
[deleted]
There's more chuck norris jokes about Fabrice than chuck norris. And in this case they are not jokes.
Fabrice Bellard’s tears solve P vs. NP. Too bad he's never cried.
Fabrice Bellard once failed a Turing test when he correctly identified the 203rd digit of pi in less than a second.
Fabrice Bellard once shifted a bit so hard, it ended up on another computer.
> Fabrice Bellard once shifted a bit so hard, it ended up on another computer.
And that, my friends, is essentially what networking is :)
And that, my friends, is essentially what networking is :)
Are you sure they're running the same set of tests? There's over 10000 tests in the full set that webpage runs, but there are subsets and fabrice might be running one of the subsets.
FWIW test262 falls over partway through in Firefox and I have to kill the tab, though it doesn't crash. There are a bunch of test failures as well for things that are probably not implemented by anyone (I'm curious how many of the tests QuickJS actually passes)
My guess for any performance gap would be that the browser runner probably sets up an entirely separate execution context (iframe?) to run each test cleanly so they don't interfere with each other.
FWIW test262 falls over partway through in Firefox and I have to kill the tab, though it doesn't crash. There are a bunch of test failures as well for things that are probably not implemented by anyone (I'm curious how many of the tests QuickJS actually passes)
My guess for any performance gap would be that the browser runner probably sets up an entirely separate execution context (iframe?) to run each test cleanly so they don't interfere with each other.
V8 has 89% coverage and QuickJS has 86%. https://test262.report/?date=2022-02-28
To add, QuickJS is almost completely comparable in test coverage, except for internationalization (which makes sense it wasn't a priority, since it's not used in a browser).
[deleted]
https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc
Look at DOM performance. Chrome has a ceiling of about 45m ops/s where FF max speed is dependent upon your ram and bus speed reaching beyond 4-5b ops/s. In both though querySelectors perform at about the same speeds as slow as 25000 ops/s.
I have written an OS GUI that executes in the browser. It loads, including full state restoration in about 120ms. I was recently interviewing with a search engine company, one of the big ones, where I could demonstrate that JavaScript tool can execute file system search much faster than the OS and produce better results. They seemed really impressed.
Despite all of this my biggest learning about performance is that mentioning performance during job interviews shows that you are incompatible with other JavaScript developers and will not be hired.
Look at DOM performance. Chrome has a ceiling of about 45m ops/s where FF max speed is dependent upon your ram and bus speed reaching beyond 4-5b ops/s. In both though querySelectors perform at about the same speeds as slow as 25000 ops/s.
I have written an OS GUI that executes in the browser. It loads, including full state restoration in about 120ms. I was recently interviewing with a search engine company, one of the big ones, where I could demonstrate that JavaScript tool can execute file system search much faster than the OS and produce better results. They seemed really impressed.
Despite all of this my biggest learning about performance is that mentioning performance during job interviews shows that you are incompatible with other JavaScript developers and will not be hired.
> Despite all of this my biggest learning about performance is that mentioning performance during job interviews shows that you are incompatible with other JavaScript developers and will not be hired.
As someone who done plenty of JS, cares about performance and also has handled hiring for JS positions in the past, I can tell you that this is generally not true. Caring about performance is not a reason to not get hired.
But it is possible to be "technically superior" in every conceivable way, but still not be a good hire. Why? Because the candidate might be missing vital soft skills or even not be very good at describing their thoughts, something that can slow down an entire team.
"Learning the wrong lesson" when things go wrong would also be something I'd consider high up for reasons to reject a candidate.
As someone who done plenty of JS, cares about performance and also has handled hiring for JS positions in the past, I can tell you that this is generally not true. Caring about performance is not a reason to not get hired.
But it is possible to be "technically superior" in every conceivable way, but still not be a good hire. Why? Because the candidate might be missing vital soft skills or even not be very good at describing their thoughts, something that can slow down an entire team.
"Learning the wrong lesson" when things go wrong would also be something I'd consider high up for reasons to reject a candidate.
I have been doing web work for over 20 years. Everybody claims to care about performance, training, security, and so forth. The only thing that really matters in practice is comfort. Until developers are willing to abandon certain areas of comfort things like performance are only given lip service. In doesn’t matter what they want if they are actively working in opposition. This is performance is a massive incompatibility to hiring.
> In doesn’t matter what they want if they are actively working in opposition. This is performance is a massive incompatibility to hiring.
No one is working towards degrading performance on purpose, and caring about performance is not "a massive incompatibility to hiring". But the fact that you keep stating this makes it clear that there seems to be plenty of other reasons organizations are not hiring you.
No one is working towards degrading performance on purpose, and caring about performance is not "a massive incompatibility to hiring". But the fact that you keep stating this makes it clear that there seems to be plenty of other reasons organizations are not hiring you.
> No one is working towards degrading performance on purpose
You are not participating in the same interviews that I am then. Most developers know querySelectors, for example, are super slow. They will fight to death to retain them and anybody who suggests any alternative is not compatible for hiring. If they know its slow and deliberately choose to avoid faster alternatives how is that not degrading performance on purpose? How is that not common?
You are not participating in the same interviews that I am then. Most developers know querySelectors, for example, are super slow. They will fight to death to retain them and anybody who suggests any alternative is not compatible for hiring. If they know its slow and deliberately choose to avoid faster alternatives how is that not degrading performance on purpose? How is that not common?
> "I was recently interviewing with a search engine company, one of the big ones, where I could demonstrate that JavaScript tool can execute file system search much faster than the OS and produce better results. They seemed really impressed."
No, its a common misunderstanding of search and tree models. The OS is faster, by a tiny bit, at traversing the file system than my JavaScript application. It is only search that is slower, and dramatically so. I don't have visibility of the OS code so I cannot be certain why that is. I speculate its because the OS is doing too much.
With the DOM querySelectors are dramatically slower than using static methods with arbitrary strings as arguments. This is likely because a query string must be parsed against each child node to determine if the child node is a match to the supplied query. Likewise, modern OSs use ancient conventions to search the file system, such as wildcards, along with more modern advanced search syntax. These are rules that must be parsed against each child artifact from a tree segment. My application deliberately doesn't do that.
To compound matters Windows, don't know about OSX, caches search results so that subsequent searches are a little less slow, which incurs a greater performance penalty on first search. My application doesn't do that either. Each search triggers tree traversal, so its always as fast reading from the file system.
Mentioning any of this during a job interview makes for intriguing conversation with the interviewer. I do detect genuine interest and curiosity from the interviewer. At the same time they know their team will fight to the death at many mention of alternatives to querySelectors and/or JSX, so you have just effectively terminated the interview. Anything there after is purely for the interviewer's personal interests.
With the DOM querySelectors are dramatically slower than using static methods with arbitrary strings as arguments. This is likely because a query string must be parsed against each child node to determine if the child node is a match to the supplied query. Likewise, modern OSs use ancient conventions to search the file system, such as wildcards, along with more modern advanced search syntax. These are rules that must be parsed against each child artifact from a tree segment. My application deliberately doesn't do that.
To compound matters Windows, don't know about OSX, caches search results so that subsequent searches are a little less slow, which incurs a greater performance penalty on first search. My application doesn't do that either. Each search triggers tree traversal, so its always as fast reading from the file system.
Mentioning any of this during a job interview makes for intriguing conversation with the interviewer. I do detect genuine interest and curiosity from the interviewer. At the same time they know their team will fight to the death at many mention of alternatives to querySelectors and/or JSX, so you have just effectively terminated the interview. Anything there after is purely for the interviewer's personal interests.
No app I've ever written needs querySelector to be fast. I'm not saying I can't imagine such an app. But, I would never reach for some optimized but very uncommon solution unless the app really needed it.
>I could demonstrate that JavaScript tool can execute file system search much faster than the OS
What do you mean? How do you search the file system without calling into the OS?
What do you mean? How do you search the file system without calling into the OS?
A micro service to a localhost node application. There is a file system API in the browser now but it isn’t mature and is highly restricted compared to the terminal.
??? So JIT code + IPC + more JIT code + native code + kernel code is faster than native code + kernel code? How does that work?
I suspect that isn't why you weren't hired.
Why would you suspect that? Are you a JavaScript developer? If so have you seen the terrifying horror on people’s faces when you mention alternatives to querySelectors or that you can write/execute code faster by not using vDOM? Mentioning performance is the fastest way to exit a job interview.
Isn’t this comment behaving in a sensitive way? Your bio says sensitive people make you sad. Unfortunately quoting an [out of touch] billionaire, though that’s not the point :p.
the color palette on the site is really weird. it took me 5 minutes to see the browser names :D
[deleted]
Be curious to try Chrome again, but for a long time it’s felt bloated and slow. Been very happy with Safari, and particularly love the 2FA integration.
My biggest gripe is the lack of shared bookmarks and passwords between browsers. There are 3rd party extensions and what not to do some of this (eg 1password), but nothing beats the UX of true browser integration. I wish there was a single standard with pluggable backends so I had no switching costs. Quite frankly I’m surprised Firefox doesn’t just use the Mac keychain and share bookmarks with Safari in order to gain market share.
My biggest gripe is the lack of shared bookmarks and passwords between browsers. There are 3rd party extensions and what not to do some of this (eg 1password), but nothing beats the UX of true browser integration. I wish there was a single standard with pluggable backends so I had no switching costs. Quite frankly I’m surprised Firefox doesn’t just use the Mac keychain and share bookmarks with Safari in order to gain market share.
My Speedometer results on an M1 Mac are:
- Chrome v99: 204
- Safari: 266
How come I fall so far short of the post's advertised fastest-of-any-browser 300?
Edit: Running in incognito got me a 251, so some of the slowdown must be from extensions.
Edit 2: Seems like 1password and uBlock Origin decrease the score by around 30 each, I got a 276 with both disabled.
- Chrome v99: 204
- Safari: 266
How come I fall so far short of the post's advertised fastest-of-any-browser 300?
Edit: Running in incognito got me a 251, so some of the slowdown must be from extensions.
Edit 2: Seems like 1password and uBlock Origin decrease the score by around 30 each, I got a 276 with both disabled.
Chrome starts with different options for different users to try out new features. They state which features they ran the benchmarks with in the fine print below the article:
"Data source for Mac statistics: Speedometer 2.0 comparing Chrome 99.0.4812.0 --enable-features=CanvasOopRasterization --use-cmd-decoder=passthrough "
"Data source for Mac statistics: Speedometer 2.0 comparing Chrome 99.0.4812.0 --enable-features=CanvasOopRasterization --use-cmd-decoder=passthrough "
M1Pro
Chrome v98: 290 Chrome v99: 316 Safari : 278
All were with incognito/private browsing to remove the effect of extensions
Chrome v98: 290 Chrome v99: 316 Safari : 278
All were with incognito/private browsing to remove the effect of extensions
Can you maybe also do a test for Firefox on your machine? I'm very interested in seeing how it holds up.
I get 240 with Firefox nightly (no addons) on a Mac Air M1.
I get sub-150 on an M1 Pro in Firefox.
Do you know why you're Mac getting low results? Other users are getting 200+
I'm sure it has something to do with using ad blockers and other extensions. I don't use Firefox for its cutting edge speed so I didn't really think too much of it.
207 on my M1 Max, v98.0 stable.
Hmm on my m1 air (16GB) I get a score of 300 ± 15 in incognito.
I get ~304 (all extensions disabled) but that's on an M1 Max. Other differences might be the amount of background apps/tasks - I usually keep mine pretty slim.
Maybe because Safari runs exclusively on MacOS and so can have a lot of OS specific optimizations ?
[deleted]
On my old fx8350 (overclocked) I get 60 in windows but 70 on linux with the same browser, Vivaldi. I wonder what the difference is.
On my i9 2.4GHz 8-core, 64GB RAM, 2019 Mac, and with no extensions:
- Chrome v99: 168
- Firefox v97: 132
- Safari v15: 139
Of course I forgot to benchmark Chrome _before_ I updated it. :(
- Chrome v99: 168
- Firefox v97: 132
- Safari v15: 139
Of course I forgot to benchmark Chrome _before_ I updated it. :(
Not directly comparable, but on my Ryzen 2600X 32GB desktop that I built in early 2019 update didn't do anything.
- Chrome 98: 157
- Chrome 99: 157
- Firefox 97: 104
- Edge 99: 146
Oh well.
- Chrome 98: 157
- Chrome 99: 157
- Firefox 97: 104
- Edge 99: 146
Oh well.
Call me immature but the version numbers are making me wonder if there's going to be a Firefox ME or Chrome 2000 released soon..
I got Chrome v99: 290, Safari v15.3: 279 on M1Max MPB I suspect it might go faster if I turn off scaling.
Saw about the same impact of 1p and uBO in Firefox.
I have a friend who says: "when you invent more efficient lightbulbs, people do not consume less energy, they just get more light"
Every time we did a milestone performance improvement in our infrastructure, e.g. search used to take few seconds, we reduced it to few milliseconds. One year later our colleagues were doing machinegun-like queries and the search was back to take 1 second, and it is just a matter of time to go back to few seconds.
One thing that helped a lot was hard limits, e.g. InternetExplorer9 having hard cap on css size was literally the only thing that forced people not to push megabytes of css.
I wish Chrome does something similar, like 'you cant have more than 500kb of js code evaluated per page' or 'no more than 200kb css', it will do miracles in just one year, and I am willing to bet that we will have the same features we would without the limit.
EDIT: I did not mean to undervalue Chrome's 49% improvement in one year, which is just extraordinary work!
Every time we did a milestone performance improvement in our infrastructure, e.g. search used to take few seconds, we reduced it to few milliseconds. One year later our colleagues were doing machinegun-like queries and the search was back to take 1 second, and it is just a matter of time to go back to few seconds.
One thing that helped a lot was hard limits, e.g. InternetExplorer9 having hard cap on css size was literally the only thing that forced people not to push megabytes of css.
I wish Chrome does something similar, like 'you cant have more than 500kb of js code evaluated per page' or 'no more than 200kb css', it will do miracles in just one year, and I am willing to bet that we will have the same features we would without the limit.
EDIT: I did not mean to undervalue Chrome's 49% improvement in one year, which is just extraordinary work!
Relevantly, here's the HTTP Archive's chart of page weights over time: https://httparchive.org/reports/page-weight#bytesTotal
The median is around 2MB, up from 1.5MB 5 years ago.
The median is around 2MB, up from 1.5MB 5 years ago.
Does it include multimedia content or page itself
Cool to hear that Chrome is faster than Safari, but that's not why I'm going to stick with Safari.
I use Safari because of Chrome's memory bloat, Safari's text message MFA auto-fill features, and Safari's cross-platform (iOS/macOS) password manager.
I use Safari because of Chrome's memory bloat, Safari's text message MFA auto-fill features, and Safari's cross-platform (iOS/macOS) password manager.
I'd probably use Safari more if it wasn't for me being used to Chrome's dev tools. Safari is a lot less resource hungry, artificial benchmarks aside.
> I use Safari because of Chrome's memory bloat, Safari's text message MFA auto-fill features, and Safari's cross-platform (iOS/macOS) password manager.
What do you think of Firefox? :)
What do you think of Firefox? :)
Not OP but I have exclusively used Safari since the first version and recently switched to Firefox, and the password manager not being able to use iCloud Keychain is really a major bummer.
For such a long time Firefox didn't take being a native Mac OS citizen seriously, with scrolling not being natively implemented, form fields feeling "off" and in general just feeling like a Windows app in a Cocoa window.
Luckily those days are long gone now, and Firefox now feels much more like a native app, save for a couple of dialog boxes here and there. But having used iCloud Keychain for such a long time, and there being no option to import my 500+ passwords, it really has been a pain in the ass to switch browsers.
For such a long time Firefox didn't take being a native Mac OS citizen seriously, with scrolling not being natively implemented, form fields feeling "off" and in general just feeling like a Windows app in a Cocoa window.
Luckily those days are long gone now, and Firefox now feels much more like a native app, save for a couple of dialog boxes here and there. But having used iCloud Keychain for such a long time, and there being no option to import my 500+ passwords, it really has been a pain in the ass to switch browsers.
Also, I think it's the only browser with Apple Pay on macOS.
Also Chrome is the worst, most pervasive spyware ever developed.
In the case of the MotionMark benchmark (more graphics/rendering focused), I have Safari beating Chrome's score by more than double (2703 vs 1152) on my M1 Max machine. Now I don't think Safari is 2x as fast as Chrome per se but it does explain how these speedometer tests can be so "close" yet Safari still feels faster.
EDIT: Firefox gets a 1336
EDIT: Firefox gets a 1336
I'm a little confused as to what the actual milestone is here? "We got 13% faster vs our last build" is just... well.. every day. I thought there was going to be some specific metric that they beat. It's good that browsers get faster at specific benchmarks, but what we basically always see is that the web gets more complex whilst browsers get faster (this is just an extension of the effect where software gets more complex as hardware gets faster and therefore the software you're using at any given time basically stays the same speed).
However, and I think this is important to bring up, browsers are basically the same speed and the reason to use one over the other is largely down to ergonomics and larger concerns. On the "larger concerns" side, Chrome is a failure. Chrome exists so the advertising company Google can track you and sell you targetted ads. It can do this in reasonable ways and it can do this in unreasonable ways, and with attacks on privacy like FLoC. Chrome is doing exactly what Internet Explorer was doing for microsoft in the 2000s and I think it's appropriate to call out that fact.
However, and I think this is important to bring up, browsers are basically the same speed and the reason to use one over the other is largely down to ergonomics and larger concerns. On the "larger concerns" side, Chrome is a failure. Chrome exists so the advertising company Google can track you and sell you targetted ads. It can do this in reasonable ways and it can do this in unreasonable ways, and with attacks on privacy like FLoC. Chrome is doing exactly what Internet Explorer was doing for microsoft in the 2000s and I think it's appropriate to call out that fact.
It’s more subtle and monumental than that. Before this JS was already executing at the same speed as Java except for in arithmetic. At this rate of improvement eventually JS will execute much faster than Java in all areas except arithmetic where it will achieve near parity.
I am not seeing any other programming language continuously improve their execution speed this much.
I am not seeing any other programming language continuously improve their execution speed this much.
I’m glad perf is still a focus for the Chrome team. That said…
> We know that benchmarks are just one of many ways of measuring the speed of a browser.
This is very true, and with a few notable exceptions my experience is that Safari feels faster across the board even where it has consistently benched slower. This likely has less to do with runtime performance and more to do with process isolation models. I feel confident about that because Safari tends to be more liberal with spawning new processes, and that’s where I experience its pathological edge cases.
(Chrome starts to pool processes by domain sooner than Safari, which puts less pressure on the OS but more on operations within a given domain; Safari creates processes per tab more consistently but ultimately degrades overall app performance and eventually system performance too.)
> We know that benchmarks are just one of many ways of measuring the speed of a browser.
This is very true, and with a few notable exceptions my experience is that Safari feels faster across the board even where it has consistently benched slower. This likely has less to do with runtime performance and more to do with process isolation models. I feel confident about that because Safari tends to be more liberal with spawning new processes, and that’s where I experience its pathological edge cases.
(Chrome starts to pool processes by domain sooner than Safari, which puts less pressure on the OS but more on operations within a given domain; Safari creates processes per tab more consistently but ultimately degrades overall app performance and eventually system performance too.)
Can you explain why the process isolation model would matter here? It seems at best uncorrelated and my experience has been that aggressive process pooling improves, rather than degrades, system performance.
Chrome's pooling model seems to improve system performance as you say (and as I was trying to express), at high pressure. Safari’s model seems to optimize for low system pressure by favoring spawning more processes. Individually they perform better, but overall it degrades as process count increases.
Lowering system pressure is basically the same as improving system performance, so I guess I'm still not understanding what you're trying to say.
I believe pressure here is referring to the workload being asked of the machine, rather than the result of how it is processing that workload.
Basically: More Tabs = Pooling is more performant, less tabs individual process is more performant.
I don't know how true that is, but I'm fairly certain that is what GP is trying to get across.
Basically: More Tabs = Pooling is more performant, less tabs individual process is more performant.
I don't know how true that is, but I'm fairly certain that is what GP is trying to get across.
> Nothing is more frustrating than having a slow experience while browsing the web.
Really?
I think many people "around the world" have more pressing issues than saving a couple of milliseconds while "shopping for a new pair of headphones".
Especially when everyone knows the real speed bump across all browsers, devices and OSes is to aggressively filter out ads, something Chrome is actively fighting with Manifest V3.
Really?
I think many people "around the world" have more pressing issues than saving a couple of milliseconds while "shopping for a new pair of headphones".
Especially when everyone knows the real speed bump across all browsers, devices and OSes is to aggressively filter out ads, something Chrome is actively fighting with Manifest V3.
It would be interesting to hear from somebody in the Chrome group how they deal with this conflict of interest.
Former champion Safari has been dog slow since v15. My benchmark https://youtu.be/5yCXPCVvUBY
apple's long defended their anti-choice stance under the pretense that they have the best, fastest, lowest resource usage browser. it's long been a tiring, self-aggrandizing, & dominionist perspective- of fantastically limited consideration given how constrained & limited the platform support Safari opts for. now that even that braggadocio is crumbling, i'm wondering what's left for Apple's pompous claims about rejecting alternatives.
i confess, i don't think it matters a lot for most users how fast the system is. safari, chrome, whatever, they're close. but it's still pretty revolting that apple insists on their own reality distortion field, that they cannot engage in a healthy & honest discussion about how and why they block off choice.
i confess, i don't think it matters a lot for most users how fast the system is. safari, chrome, whatever, they're close. but it's still pretty revolting that apple insists on their own reality distortion field, that they cannot engage in a healthy & honest discussion about how and why they block off choice.
> i don't think it matters a lot for most users how fast the system is
This is why we had months of people raving about M1, of course.
This is why we had months of people raving about M1, of course.
techies arent people. :p i kid... but there is a vocal group which doesn't necessarily reflect the common experience.
i joke. but also, i think where we're hearing these reports from are only semi-important. even with far far far far far superior hardware- 200/400GBps memory- a vast gain- plus other architectural wins- my temptation would still be to call this an incremental (but sizable) win, not revolutionary.
i joke. but also, i think where we're hearing these reports from are only semi-important. even with far far far far far superior hardware- 200/400GBps memory- a vast gain- plus other architectural wins- my temptation would still be to call this an incremental (but sizable) win, not revolutionary.
I'm guessing there was renewed urgency for responsiveness due to 120fps displays on M1 mac's - which made lower frame rates compared to Safari more noticeable.
Seems like an unlikely driver in it's own, especially considering those didn't show up until near the end of this time period. Meanwhile Chrome has been needing to run more power efficiently at similar refresh rates and pixel counts on Android devices all the same. Of course ARM Android devices don't have Safari to compare to nor are they a new platform ripe with as many low hanging fruit optimizations so it's not going to be the lead topic here.
The truth is this is the same kind of stuff Chrome (and any browser) has been working on since the software launched. Regardless of which devices come out nobody has ever said "I like that this browser is slower and less efficient than the other".
The truth is this is the same kind of stuff Chrome (and any browser) has been working on since the software launched. Regardless of which devices come out nobody has ever said "I like that this browser is slower and less efficient than the other".
"Nothing is more frustrating than having a slow experience while browsing the web"
^ I stopped reading at this point, because I realised that this is something that only someone on a marketing team would write. A perfect combination of incorrect and disingenuous.
^ I stopped reading at this point, because I realised that this is something that only someone on a marketing team would write. A perfect combination of incorrect and disingenuous.
Why? I find slow and janky websites insufferable.
Having an account banned and not being able to restore it or having to watch countless of ads slowing down my computer or not searching what I am looking for because of new ranking algorithms seems worse that a little bit of loading time :)
Use adblockers, Use different search engine if you don't like it.
Can't comment about account being banned.
Can't comment about account being banned.
> Use adblockers
To be fair, this is the same company pushing Manifest V3, which might kill adblocking as we know it
To be fair, this is the same company pushing Manifest V3, which might kill adblocking as we know it
Chrome needs to fix the Mac Keystone WindowServer lag issue:
Details here: Chromeisbad.com
Keystone globally slows down UI and drains battery life, especially notable on older machines. Completely uninstalling chrome felt like upgrading to a new CPU on my 2013 MacBook.
Details here: Chromeisbad.com
Keystone globally slows down UI and drains battery life, especially notable on older machines. Completely uninstalling chrome felt like upgrading to a new CPU on my 2013 MacBook.
Does anyone else find that they can't ever tell a difference in browser speed in day to day use?
I switched to FireFox for my personal use a few years before the "Quanutm" update when it was theoretically much worse than Chrome and didn't notice a difference. For the last few years, I've been using Chrome and FireFox side by side with Chrome for work and FireFox for my own stuff and switching back and forth feels pretty seamless. (With the exception of Gmail which is abysmal on FireFox, but I somehow doubt that's Mozilla's fault)
I switched to FireFox for my personal use a few years before the "Quanutm" update when it was theoretically much worse than Chrome and didn't notice a difference. For the last few years, I've been using Chrome and FireFox side by side with Chrome for work and FireFox for my own stuff and switching back and forth feels pretty seamless. (With the exception of Gmail which is abysmal on FireFox, but I somehow doubt that's Mozilla's fault)
Chrome feels a little faster to me, but I stick with Firefox because it doesn’t give me the same creepy big brother feeling as chrome and I can spare a few milliseconds per page load.
Come to think of it, I primarily use chrome to double check UI changes on a page served from my local computer. That’s probably the main reason it feels faster.
Come to think of it, I primarily use chrome to double check UI changes on a page served from my local computer. That’s probably the main reason it feels faster.
I think the takeaway from this article is that LTO is very difficult to use, if a company with dozens of full-time language platform engineers was not able to use it until the project's 15th year.
Off Topic: Chrome is likely a very good benchmark for comparing between Intel x86 chip and Apple M1. Where Google spend enough time to optimise on both platform.
I wonder if they could work on Memory usage next.
Compared to Safari, getting jank from Address bar, bookmark, history, show all tabs, SafariBookMarkSyncAgent is leaking memory. It seems every release Safari added more features and bug fix for compatibility while performance has been in steady decline.
I wonder if they could work on Memory usage next.
Compared to Safari, getting jank from Address bar, bookmark, history, show all tabs, SafariBookMarkSyncAgent is leaking memory. It seems every release Safari added more features and bug fix for compatibility while performance has been in steady decline.
V8 is an absolute marvel of engineering. The performance gains are very impressive.
But Chrome still has some work to do on rendering performance. The switch to hardware acceleration was actually a deceleration for quite a few cases. For example rendering very large concave SVG paths is probably 10x faster on Firefox compared to Chrome. I hope to see some effort in future to improve this, too.
But Chrome still has some work to do on rendering performance. The switch to hardware acceleration was actually a deceleration for quite a few cases. For example rendering very large concave SVG paths is probably 10x faster on Firefox compared to Chrome. I hope to see some effort in future to improve this, too.
Why is it so difficut to find the average page load time for the most popular websites AKA wpt6 ??
Enough of those asbtract synthetic benchmarks..
Congrats to Chrome team, this is impressive.
IMO Chrome desperately needs to minimize its memory usage.
Memory is like $3-4/GB (decently fast DDR4). And you've been fine with 16GB for a decade without upgrading.
If you're stuck on some un-upgradable old budget device, it's unlikely the memory holding you back either.
If you're stuck on some un-upgradable old budget device, it's unlikely the memory holding you back either.
OTOH - new, entry level Macbook M1s come with 8Gb RAM. Those are the ones I could afford (= full monthly salary) but I'm reluctant to buy because of Chrome.
Chrome with only about a dozen tabs open can take up to 16GB of memory. There is no defense for this. It only gets worse as time goes on and as more tabs are opened.
I have 64GB of memory total and about 16-32 of it is in use for virtual machines, which is reasonable.
How much total memory do you expect the average computer to have?
I have 64GB of memory total and about 16-32 of it is in use for virtual machines, which is reasonable.
How much total memory do you expect the average computer to have?
> Nothing is more frustrating than having a slow experience while browsing the web.
This seems a bit tone deaf with a war going on?
This seems a bit tone deaf with a war going on?
I'm not sure...
1) "while browsing the web", not "in life";
2) This is an article about a web browser and the article isn't trying to compare browsers to real life scenarios, let alone wars...
1) "while browsing the web", not "in life";
2) This is an article about a web browser and the article isn't trying to compare browsers to real life scenarios, let alone wars...
Lighthouse now deducts best practices score if you don't show adds,
truly a milestone.
Nice try, Chrome, but I'll stay on Firefox.
Oh goodie, more headroom for inducing advertiser demands.
Harvesting my data at unprecedented speeds.
Unfortunately, doesn't really matter what browser you use. The JS APIs to harvest data are part of all major browsers now.
To which API are you referring? Mozilla, so far as I know, tries to protect the user.
Almost all web APIs can be used to fingerprint user (but Mozilla is reluctant to add new ones indeed when the ratio benefit/risk is too low). https://amiunique.org/
Lots of APIs are used to track users, but for example the Canvas API. Firefox also enables quite a few telemetry options by default.
The Chromium blog shouldn't refer to Chrome. There are many browsers based on Chromium and all would have the benefit from any changes to the core. If this is really just Chrome only then what is it doing on this blog in the first place?
Am I so wrong to stop reading after a grammatical error on the very first word in the article?
https://www.google.com/search?q=everyday+two+words+or+one
https://www.google.com/search?q=everyday+two+words+or+one
Let's say I am visiting a properly made website and it takes 10% of CPU to render. Even if browser devs make their browser twice faster, it will only save 5% of CPU time - and that would be completely unnoticeable. You might ask, what about modern websites, built with D*t compiled to webassembly, GPU acceleration, reactive frameworks, material design and capable to load the multi-core CPU at 100%? I am not using such sites so I don't care.
Now let's look at memory usage. Optimizing for speed usually causes increased memory consumption, and this increases the chance of invoking swapping. If the system starts swapping, it becomes orders of magnitude slower. No speed optimizations will matter in this case.
Therefore if you are targeting wide audience, and not only mac users, then you should be optimizing for memory usage. If the browser could use two times less memory while using twice amount of CPU time that would be perfect. Just think how many laptops with 2 or 4 Gb of RAM would become usable again.