Chrome vs Safari on an Old Mac: What Nobody Tells You About RAM and Disk

While diagnosing my slow 2015 MacBook, something stood out in every Activity Monitor screenshot: Chrome, with just 6 or 8 tabs open, showed up more than a dozen times in the process list, each instance using its own slice of memory. Safari, with a similar number of tabs, showed up only two or three times.

The popular explanation is "Chrome is slow because of extensions". It's partly true, but it isn't the main reason — and stopping there leads to fixes that don't solve the underlying problem (uninstall two extensions and stay just as slow).

The real reason: a multi-process architecture

Since 2008, Chrome has used an architecture where every tab, every extension and several internal components run as separate operating-system processes, instead of sharing a single process as older browsers did. The advantage is real: if one tab freezes or crashes, the whole browser doesn't go down. So is the downside: every separate process reserves its own slice of memory, and that multiplication is why Chrome with 10 tabs can use several times more RAM than Safari with the same number.

Add a less visible pattern: Chrome writes to disk constantly — per-site cache, profile data, extension sync. On a modern SSD those writes are almost imperceptible. On a slower SSD, or on a Mac with RAM at its limit (where the system starts using swap, which is also disk reads and writes), that pattern piles up with the rest of the system's activity and contributes directly to the kind of I/O saturation I documented in the previous article in this series.

Why it feels worse on limited hardware

On a MacBook with 16GB of RAM or more, the difference between Chrome and Safari is noticeable but manageable. On a Mac with 8GB — which in 2026 is little for development work with several tools open — Chrome can push the system into swap fairly easily, and that's where the slowness becomes obvious: it isn't that Chrome "is slow", it's that the combination of limited RAM and a browser that reserves memory aggressively pushes the system into saturation.

What you lose (and don't) by switching to Safari

For everyday office work, browsing and consuming content, moving to Safari is practically seamless. What you need to sort out before switching:

• Bookmarks and passwords — Chrome lets you export both from its settings; Safari imports them directly
• Equivalent extensions — most popular ad blockers and password managers have a native Safari version
• Sync across devices — Safari syncs through iCloud if you already use the Apple ecosystem, with no extra account
• DevTools — Safari has its own developer tools, but they aren't interchangeable with Chrome's if your workflow depends on specific Chrome DevTools extensions

When it's worth keeping Chrome

For those of us who build websites, Chrome is still necessary — not as the browser that runs in the background all day, but specifically for cross-browser testing and debugging. The practical recommendation I applied to my own workflow: Safari as the main browser for daily work, and Chrome open only when testing requires it. The result shows immediately in the system's load average.