Chrome 57 for Mac throttles background tabs for better CPU use & battery life
The desktop versions of Chrome -- including the Mac edition -- now throttle the performance of background tabs, according to Google, reducing CPU demand and hence the browser's power consumption on MacBooks.
In particular the Chrome 57 update limits the timer fire rate of background tabs deemed to be consuming too much power, the official Chromium blog explains. The tactic is intended to limit average CPU load to 1 percent of a core.
The change should result in 25 percent fewer "busy" background tabs. Crucially, tabs with audio or real-time connections are immune to throttling.
Google notes that through a later update, Chrome will eventually be able to suspend background tabs completely. New APIs will handle tasks that need to continue operating.
The Mac version of Chrome has often faced criticism for being CPU- and RAM-intensive. The browser took a significant step forward with Chrome 55, which drastically improved memory usage.
The iOS version of Chrome has mostly continued along a different development track, since Apple's mobile policies force the browser to use the same WebKit engine found in Safari. Most recently it picked up the Reading List, copying a feature in Safari.
In particular the Chrome 57 update limits the timer fire rate of background tabs deemed to be consuming too much power, the official Chromium blog explains. The tactic is intended to limit average CPU load to 1 percent of a core.
The change should result in 25 percent fewer "busy" background tabs. Crucially, tabs with audio or real-time connections are immune to throttling.
Google notes that through a later update, Chrome will eventually be able to suspend background tabs completely. New APIs will handle tasks that need to continue operating.
The Mac version of Chrome has often faced criticism for being CPU- and RAM-intensive. The browser took a significant step forward with Chrome 55, which drastically improved memory usage.
The iOS version of Chrome has mostly continued along a different development track, since Apple's mobile policies force the browser to use the same WebKit engine found in Safari. Most recently it picked up the Reading List, copying a feature in Safari.
Comments
I hope this fashion will die when people mature.
https://chrome.google.com/webstore/detail/the-great-suspender/klbibkeccnjlkjkiokjodocebajanakg?hl=en
I have rarely worked in machine code but I have come up with some programs and routines in COBOL and some weird stuff that are 100x as efficient as some of the garbage I have run across today. Most coders don't come near assembler but should be able to come up with much better C#, Java, Swift, etc. than they do right now.
Then I have Safari open with four windows - 14 tabs, 1 tab, 5 tabs and 12 tabs respectively.
Sometimes my wife needs Chrome open for her three work logins so there's tons of windows and tabs open there too.
I don't work so this is not a workflow thing. It's just how I use my computer.
I think tabs are pretty convenient. For example, I open up all the stories I haven't read on AI on multiple tabs.
When it comes to Finder tabs though, I prefer multiple windows for some reason. Maybe I still haven't gotten used to them.
Google now tries to belatedly fix the problem? No thanks. Even on Windows Chrome OS provides a terrible experience. IE is much better even if it is a poor experience also. My work allows only the use of IE or Chrome. If I have to use Chrome due to compatibility issues, I will close it immediately once the task is finished. Chrome can bring an 8 core Xeon machine with 32 GB of RAM to its knees after only a few hours. There's no excuse for that.
https://www.openhub.net/p/chrome/analyses/latest/languages_summary
https://www.openhub.net/p/firefox/analyses/latest/languages_summary
That's 5-10x the amount of code over the last few years. The memory tools on the Mac give some idea what's going on. In Activity Monitor, get the browser/tab process id (pid) and in terminal type:
heap -showSizes -guessNonObjects -sumObjectFields process_id_number
where process_id_number would be replaced with the number. They have all sorts of allocations going on. Modern websites have more media content than before, the tabs are split out and don't all share resources for stability, they have HTML5 content, fonts, CSS, Javascript, higher resolution images, heavy ad content, color profiles.
This doesn't excuse not putting in effort to be more efficient but that's a lot of code to manage. The browser codebases are the same size as Linux. Their priorities would be functionality and stability. Suspending and perhaps even compressing background tabs would be a good idea but sometimes that wouldn't be the desired action if the user is playing audio from Youtube/SoundCloud so they'd need overrides per tab.
I'm just glad to be away from Safari's old forced tab reloading by having separate tabs as well as session resuming makes browsing much more stable. It's surprising to see applications having so much code vs an entire OS but it must be using all of it or it wouldn't be in there. It seems like it should be a lot simpler when it's just rendering a page of text, images and video. Here's the Chrome code:
https://chromium.googlesource.com/chromium/src.git/+/master/chrome/browser/
They have 3000 lines of code just for the bookmarks bar:
https://chromium.googlesource.com/chromium/src.git/+/master/chrome/browser/ui/cocoa/bookmarks/bookmark_bar_controller.mm