Why Is My Mac So Slow All of a Sudden: Tracing What Changed

Yesterday the machine was fine. Today the cursor stutters, switching applications takes a beat too long, and typing into a text field shows the characters a fraction of a second after the keystroke. Nothing was installed, no hardware was added, and the same work is open as always. Most advice for this situation is a list of general cleanup steps, which is the wrong shape of answer. A machine that was fast last week and slow this week has changed, and the change is findable. The list of things that change on a Mac without anyone deciding to change them is short.

The word suddenly is doing real work in that sentence

There is a difference between a Mac that has always been slow for the work being asked of it and a Mac that was adequate until Tuesday. The first is a capacity problem and the honest answer involves either less work or a different machine. The second is an event, and events leave traces.

This matters because the two problems attract the same advice and only one of them responds to it. Clearing caches, removing old files, and reinstalling applications are reasonable maintenance and they will not restore a machine that is slow because something started running last Thursday and never stopped. Chasing general tidiness first means the actual cause gets weeks of cover.

So the first question is not what to clean. It is what changed. Four categories cover nearly all of it: the system updated itself, a sync or index started, the startup disk filled up, or the working session crossed a threshold. Each has a distinct signature, and all four are visible in Activity Monitor within a few minutes.

Different kinds of slow point at different layers

Before opening any tool, it is worth being precise about what slow means in this case, because the four causes above produce different sensations and the sensation narrows the search.

Input lag, where typed characters appear late and the pointer moves in steps, means the system is not getting scheduled promptly. That points at the processor being saturated or at memory pressure forcing constant compression. It is rarely a disk problem, since typing does not touch the disk.

A spinning beachball in one application while everything else stays responsive means that application is stuck, usually waiting on something outside itself such as a network call or a file that is being synced. The rest of the machine being fine is the important half of that observation, and it takes the whole system off the suspect list.

Slow launches, where applications take many seconds to open but run normally once they are up, point at the disk. Launching reads a lot and computes very little. The same is true of the first save of a large file and of switching to an application that has been idle for hours, which has to be read back from swap.

Slow web pages with everything else crisp is a network or browser finding rather than a machine finding. Testing the same page in a second browser separates the two in under a minute, and if both are slow the answer is upstream of the Mac entirely.

Describing the symptom accurately eliminates at least two of the four causes before any measurement starts. A machine with input lag and fast launches is not suffering from a full disk, whatever the storage bar says.

Read three gauges, in this order

Open Activity Monitor and look at the CPU pane first, then Memory, then Disk. The order matters because a high reading in an earlier pane explains readings in the later ones, and the reverse is not true.

In the CPU pane, the three figures at the bottom are the ones to read.

System: The percentage of CPU capability that's being used by processes that belong to macOS. User: The percentage of CPU capability that's being used by apps you opened, or by the processes opened by those apps. Idle: The percentage of CPU capability that's not being used. Source: support.apple.com

A high System figure with low User points at macOS doing work of its own, which is the signature of indexing, a sync, or post-update housekeeping. A high User figure points at something that was opened, even if it was opened three days ago and forgotten. Sorting the process list by percentage in each case gives a name.

In the Memory pane, ignore the memory used figure and read the pressure graph. Apple is blunt about why.

When you have free or unused memory, your computer performance does not necessarily improve. macOS obtains the best performance by efficiently using and managing all of your computer's memory. Source: support.apple.com

Green pressure with most of the RAM reported as in use is normal. Yellow that persists, and a Swap Used figure that keeps climbing, is a real finding and a different problem from a busy processor.

The Disk pane comes last and answers one question: whether the machine is reading and writing constantly. Sustained disk activity with nothing being copied is almost always an index, a backup, or swapping.

The four things that change without anyone deciding

A system update that has not finished its work

An update installs in minutes and then keeps working for hours. Search indexes get rebuilt, media libraries get re-analysed, and caches get warmed again from empty. In the process list this appears as macOS-owned processes near the top with names that are not applications, and the System percentage stays elevated while the User percentage stays low.

The distinguishing feature is that it ends. Post-update work on a machine with a large photo library or a large mail archive can run for a day or more, in bursts, usually while the machine is plugged in and idle. Leaving the machine awake on power overnight is the correct treatment. Reinstalling things or clearing caches during this window makes the work start over.

A sync that started and never caught up

File sync clients are the most common single cause of a machine that turned slow on a specific day. A shared folder got large, a colleague moved ten thousand files, a media library got pointed at a synced directory. From then on the client reads, hashes, uploads and watches the filesystem continuously.

The signature is sustained disk activity plus one named process holding a steady share of the processor, often with heavy network activity alongside. It does not resolve on its own, because the folder is not going to get smaller. Pausing the client for twenty minutes is the cleanest test available: if the machine becomes responsive within a minute or two, the cause is confirmed.

A startup disk that crossed a line

Free space on the startup disk is not just about storing files. The swap file lives there, which Apple's description of the Memory pane makes explicit.

Swap Used: The amount of space being used on your startup disk to swap unused files to and from RAM. Source: support.apple.com

A disk with very little room left leaves the system less space to work in for swap, caches and temporary files at exactly the moment it needs them. This is the mechanism behind the common experience of a machine that was fine at sixty percent full and sluggish at ninety-eight. Nothing about the workload changed. The room to absorb it did.

A session that grew past what the machine can hold

The least dramatic cause and often the real one. Applications were added to the daily set one at a time over months, each one reasonable on its own. One morning the total crosses the point where memory pressure stops returning to green between tasks, and from then on every application switch involves compression or swap. It feels sudden because the threshold is sharp even though the growth was gradual.

This is the only one of the four where nothing external changed at all, which is why it is usually diagnosed last and is worth testing early.

Matching the signature to the cause

What Activity Monitor shows	Likely cause	Does it end on its own
High System, low User, macOS-owned processes on top	Post-update indexing or media analysis	Yes, hours to a day or two
One named client process plus constant disk and network	File sync catching up	No, not until the folder settles
Memory pressure in yellow, Swap Used climbing	Session larger than available RAM	No
Sustained disk activity with almost no free space	Disk too full for swap and caches	No
High User on one application only	That application, not the Mac	No
Everything moderate, machine still stuttering	Check displays and thermal conditions	Varies

Things that were added last week and are easy to miss

Two lists are worth opening once. The first is Login Items, in the General section of System Settings, which covers both the applications that open at login and the background items that vendors install alongside them. Installing one small utility frequently adds a helper that runs permanently, and the connection between Thursday's install and Friday's slowness is not obvious.

The second is the browser's extension list. Extensions with a background page run on every navigation whether or not they are used, and an extension that updated itself over the weekend can behave differently from the version that was installed. Disabling all of them and re-enabling one at a time is slower than guessing and is the only method that actually identifies the offender.

Both lists share a property that makes them worth checking early: the additions were deliberate but the cost was not, so they never come to mind when the question is what changed.

When it turns out to be the browser rather than the Mac

If the process list puts a browser at the top with a large User percentage, the slowdown belongs to a session rather than to macOS. The practical difficulty is that one browser row covers every application inside it, so the finding is real but not actionable.

Splitting the always-open applications away from the disposable ones changes that. When each application runs in its own isolated space, the process list attributes the cost to something recognisable, and the count of live applications stops being invisible. A session arranged that way also survives a restart in a predictable state, which matters when the post-update case above means restarting is the right move. The workspaces page covers how the separation works in practice.

This is not a substitute for the measurement. A sync client saturating the disk will slow a machine no matter how the browser is arranged. It is a way of making sure that when the browser is the answer, the answer names an application instead of a brand.

What to change first

Open Activity Monitor and read the CPU, Memory and Disk panes in that order before changing anything, because the pattern tells which of the four causes applies. If the top row is macOS-owned, leave the machine awake on power and let it finish. If it is a sync client or one browser, pause or separate that one thing rather than starting a general cleanup, and if the browser keeps landing at the top, give each application its own window and its own login, which is the arrangement SpaceDeck is built around on macOS.