Your Mac is not slow. Something on it is.
That spinning beach ball is not your Mac giving up. It is one process doing something it should not, and it is hiding from the tools you would normally use to find it.
Every few months someone posts in r/macapps or on X asking why their two-year-old MacBook feels like it is dying. The replies are always the same: reinstall macOS, reset the SMC, buy more RAM. None of that is the answer, because none of it addresses what is actually happening.
What is actually happening, in almost every case, is that one process has quietly consumed most of the machine's memory, and the Mac is now spending more time managing swap than doing your work. The process does not show up as the problem because macOS reports memory in a way that hides it.
The memory number you see is not the memory being used
Open Activity Monitor, sort by memory, and look at the top processes. The number in the Memory column is the resident set size: the amount of physical RAM currently mapped to that process. It is not how much memory the process has asked for, and it is not how much it is costing you.
A process can hold 14 GB of allocated memory while showing 200 MB in Activity Monitor. This is not a bug. The operating system has paged the rest out to swap, so technically the process is not using that physical RAM right now. It is using your SSD instead, which is why everything is slow.
The command-line tool ps has the same problem. ps aux shows RSS, not total allocation. The number is accurate for what it measures. It just does not measure what you need to know.
How to actually find the culprit
Activity Monitor can show you, but you have to change what it displays. Add the "Memory" column from View > Columns (it might already be there) and then also add "Compressed Mem" and look at the "VM Size" column. The real cost is the sum of resident memory, compressed memory, and what has been paged out.
Or from Terminal:
top -o mem
This sorts by real memory footprint, not RSS. It is the single most useful command on a slow Mac, and it takes two seconds.
If one process is holding several gigabytes more than everything else, you have found your problem. The usual suspects:
- A browser with too many tabs. Chrome and its siblings can hold 8 to 12 GB across dozens of helper processes. The total is never shown in one line.
- A language server or build watcher. TypeScript's
tsserver, Webpack's dev server, and VS Code's extension host are all notorious for leaking over time. They start small and grow until you restart them. - A creative app you left open. Lightroom, Photoshop and Final Cut all keep working data in memory. Leave Lightroom open on a large catalogue for three days and it will quietly own your machine.
- Docker. The Docker VM has a default memory limit of 8 GB. On a 16 GB Mac, that is half the machine spoken for before you open anything else.
- Electron apps. Slack, Discord, Notion, Figma, Spotify. Each one is a browser. Five of them is five browsers. People who complain their Mac is slow often have six browser-shaped applications running and do not think of them that way.
Why swap makes everything feel broken
Your Mac has a limited amount of physical RAM. When processes ask for more than that, macOS compresses what it can and writes the rest to your SSD as swap. Reading from an SSD is roughly 100 times slower than reading from RAM. So when the Mac needs a piece of memory that was swapped out, it stalls for a moment.
One stall is invisible. A thousand stalls per second is the beach ball.
The insidious part is that swap usage alone does not tell you anything. Swap can be 90% full and the Mac can feel fine, because what is in swap is not being read. The metric that matters is memory pressure: whether the system is actively paging right now. A swap file that sits idle is just a file. A swap file that the kernel is reading and writing to constantly is the reason your Mac feels like it is running through mud.
You can see memory pressure in Activity Monitor's Memory tab: the graph at the bottom. Green is fine. Yellow means compression is working hard. Red means the system is actively paging and you are losing real performance.
What not to do
Do not buy a RAM cleaner. Apps that promise to "free up RAM" or "optimise memory" do one of two things: they call purge, which evicts the file cache and makes the next few operations slower, not faster, or they do nothing. The operating system is better at managing memory than any third-party tool that works by asking the operating system to manage memory differently.
Do not restart your Mac every day. A restart clears everything, including the problem, but it also clears the file cache, which makes the next hour slower. If you find yourself restarting daily to keep performance up, you have a leak somewhere and a restart is hiding it.
Do not blame macOS. macOS 27, macOS 26, macOS 15, even macOS 12 all handle memory the same way under pressure. The version is almost never the problem. The process holding 14 GB is the problem.
What to do instead
Find the process. Decide whether you need it. If you do, restart it. If you do not, quit it.
Most memory leaks in development tools clear when you restart the tool, not the machine. Restarting VS Code takes five seconds. Restarting your Mac takes two minutes and loses your window positions, your terminal state, and your train of thought.
If you want something that watches for this automatically, that is what GuardMac does. It sits in your menu bar, measures real memory pressure (not just usage), and catches runaway processes before they get to the beach ball stage. The free version shows you what is wrong. Voice adds dictation with smart formatting if you want it. The paid tier handles things automatically so you never have to open Activity Monitor at all.
But the tool matters less than the understanding. Your Mac is almost certainly fine. Something on it is not. Find that something, and the beach ball goes away.
Keep reading
- Memory pressure and swap, explained: the full technical breakdown.
- Why is my Mac slow all of a sudden?: the checklist version.
- What is kernel_task and why is it using so much CPU?