MacOS – Does Safari and Google Chrome for macOS use the same rendering engine

Battery Life is different than Battery Duration. Battery life will be tied to the maintenance and usage you give to a battery. To put it simply, if your battery is designed to be charged 100 times before it dies (cycles), then using the 100 charges in one month will be the same as using them in 1 year. (or almost the same, since there will be a small loss of power when the battery is idle).

What I mean is, the battery life shouldn't be greatly affected by any application's usage pattern. But…

The truth is that battery duration is definitely affected by the power consumption. In other words: the more the power your computer uses, the less the batter will last with charge, before it requires to be recharged.

With that logic in mind, Chrome is a moderately CPU intensive application on its own (a tradeoff that is inherited by its One Process Per Tab design). It taxes your hardware a little bit more when creating new tabs and it uses slightly more RAM in order to keep things smooth. In exchange, you have a very solid -hard to crash- browser that will be able to keep working even if some of its tabs are literally dead.

Despite that, however, Chrome has Flash (as an extension you can disable). It uses the "same" Flash, but bundled internally. If chrome uses some more battery (something that I have yet to see in real life), Flash uses probably all the battery you can throw at it, but not because Flash needs battery, it's because it needs CPU power, a lot, all the time. CPU power needs electricity. Batteries have Electricity. In the absence of a power outlet, guess who's there to provide juicy power to that hungry CPU? Yes, mamma battery.

So Flash will definitely decrease your battery charge duration (and in turn, it will force you to cycle charge your battery more often, therefore decreasing its life), but this will also happen on Safari, Camino, Firefox and possibly other applications or browsers that use Flash.

The difference is the rendering engines for the browser windows.

We know Safari renders the character set differently than Chrome. But the Window UI elements (the tabs in Chrome) are okay. That's our biggest clue.

The window UI elements are likely (emphasis on likely, I may not be correct here) all being rendered by the OS. So they get the full OS-level emoji-expansion treatment.

But what happens inside a web browser window is all very browser dependent. The rendering engines are a big part of each browser's secret sauce.

Both Safari and Chrome use WebKit, but the similarities between the WebKit instances they use stop somewhere around the name of the engine. They're both forks from the main version and they're both heavily customized to improve the performance in ways that each browser development team thinks is meaningful for their end users.

@JasonSalaz found a great bug in the Chrome bug database that gives us the final clue that it's down to WebKit forks: http://code.google.com/p/chromium/issues/detail?id=90177 -- that bug is talking about the differences between the fork in Chrome and the mainline of WebKit from the open source project. There are rendering differences in the mainline that have yet to make it in to the version Chrome is using. And it looks like they intend to merge the changes in at some point.

Update: Paul Irish has a great blog post on how WebKit differs for all these browsers that currently use it. If you really want to understand just how diverse the WebKit environment is, this is a great read.