Where is Chrome's task manager on a Mac?

Select the More menu at the top right of Chrome, open More tools, then choose Task Manager. Click the Memory column header to sort by memory usage. Sorting by CPU afterwards is worth doing, since the heaviest row by memory and the heaviest row by processor time are often different.

Why are there more rows than tabs?

Because rows are processes, not tabs. A page containing embedded content from other sites produces a separate row for each of them, and extensions, rendering, and networking each add rows of their own. Chrome also groups tabs from the same site, which can produce fewer rows than tabs.

Disabling an extension did not make anything faster. Why?

Check the task manager again and confirm that the extension's row has actually disappeared, since the resident part takes a moment to shut down. If the row is gone and the numbers have not moved, the extension was not the cause and the next largest row is the one to look at.

Is restarting Chrome better than closing tabs?

It works, and it stops working quickly. A restart clears accumulated state, but resident extensions and the pages used every day come straight back, so the same condition returns. Measuring once to find out what was holding the memory tends to reduce how often a restart feels necessary.

Does Memory Saver make closing tabs unnecessary?

It reduces the memory cost of tabs that have gone unused, which is a different thing from reducing the tab count. A deactivated tab still occupies a slot in the strip and still has to be found. It also leaves some tabs alone by design, including pinned tabs and ones with a partially filled form.

Chrome slow with too many tabs? Measure before closing

The fan is running, switching windows has a lag in it, and there are somewhere north of forty tabs in the strip. The conclusion writes itself: too many tabs. That conclusion is right often enough that almost nobody checks it, and the cost of not checking is an afternoon spent closing tabs that changes nothing.

Chrome ships with a screen that settles the question in about a minute. It lists every process the browser is running, with memory and CPU columns that can be sorted. What appears at the top of that list decides which of several very different problems is actually happening, and the fixes for those problems do not overlap.

What the official steps name after tabs

Google's own page on speeding up Chrome moves through update, then close tabs, then something else entirely.

The more tabs you have open, the harder Chrome has to work. We recommend closing tabs you aren't using. Source: support.google.com

That much is expected. The step after it is not. It covers turning off unused extensions and opening the task manager to end resource heavy tasks, and it says specifically to look for items labeled "Background page." A background page is not a tab. It is the resident part of an extension, running whether or not anything related to it is open.

The ordering is not by size of effect. Closing tabs comes first because it is the one action that can be taken without measuring anything. In practice a single extension can hold more memory than a dozen tabs combined, and no amount of closing will touch it.

So the first move is not closing. It is sorting.

Open the task manager and sort by memory

The route is the one in the official steps. Select the More menu at the top right of Chrome, open More tools, and choose Task Manager. Then click the Memory column header to sort the list from largest to smallest.

The list shows how Chrome has divided itself into processes, which is why the number of rows will not match the number of tabs. Sometimes there are fewer rows than tabs, sometimes more. That mismatch is the first useful signal, and it is covered further down.

Memory is not the only column worth sorting. Sorting by CPU frequently produces a different order and a different culprit. A row holding a large amount of memory may be sitting perfectly still, while the reason the fan is audible is a much smaller row burning processor time on a loop. The word slow does not distinguish between these two, and the fixes are not the same.

Sorted results fall into three shapes. Tabs dominate the top. Extensions appear among the top rows. Or nothing in the list is large, and the slowness is coming from outside Chrome. Everything after this depends on which shape appears.

Five kinds of row, five different meanings

Rows are identifiable by how they are named. Anything showing a page title is a tab. The rest are not, and they are the reason this screen is worth opening.

Tab. Named after the page. If these fill the top of the list, the original assumption holds and closing will help.
Background page. The resident portion of an extension. It does not close with a tab and it runs for as long as the browser does.
Subframe. A region of a page belonging to a different site: an embedded video, a map, a payment widget, an analytics console. One tab can produce several of these rows.
GPU process. Handles rendering for the whole browser. There is exactly one, and it grows with what is being drawn rather than with how many pages are open.
Network service. Handles connections for the whole browser. Also a single row, and it normally sits far down the list.

If extensions show up high, the action is direct. Turn off the ones that are not being used, then reopen the same screen and look again. Measuring twice and comparing is more reliable than reasoning about which extension seems heavy, because the ones that turn out to be expensive are usually not the ones that feel expensive.

If subframes fill the top, the problem is the weight of one page rather than the number of pages. A dashboard with several embedded panels can cost as much as ten light tabs on its own, and closing unrelated tabs around it will not be noticeable.

If the GPU row is the large one, something being drawn is expensive: video playback, a map, a table that repaints constantly. Since there is only one such row, isolating the cause means closing the visually busy tabs one at a time and watching the number move.

Why the row count never matches the tab count

Even when tabs do occupy the top, the relationship between tab count and resource use is looser than it looks.

Chrome groups tabs from the same site together under the right conditions, so eight tabs of the same service do not necessarily produce eight rows. In the other direction, a single page carrying embedded content produces extra rows for each embedded site. Counting rows describes the machine's actual workload far better than counting tabs does.

Inactive tabs pull the relationship apart further. Tabs that have not been touched in a while are deactivated and reload when they are next opened, which means they appear in the list as small numbers. Closing fifty tabs that were already inactive reclaims very little, and this is exactly the experience that leads people to conclude that closing tabs does nothing.

Pinned tabs work the opposite way. Pinning exempts a tab from automatic deactivation, so a pinned tab keeps its contents no matter how long it sits. Pinning frequently used pages is sensible, and it also means the savings from deactivation stop applying to that portion of the strip. A row near the top belonging to something untouched for hours is worth checking for a pin.

The gain from closing tabs is mostly in finding things, not in freeing memory. Titles become readable again, the target tab is one glance away instead of a scan. That is worth having, and it is a different problem from the machine being slow.

When the browser is not the problem

If every row in the task manager is small and the machine is still sluggish, the cause is outside Chrome. The screen to open next is Activity Monitor, on the Memory tab, and the number to read is not the amount of free memory.

Memory Pressure: Graphically represents how efficiently your memory is serving your processing needs. Memory pressure is determined by the amount of free memory, swap rate, wired memory, and file cached memory. Source: support.apple.com

A low free memory figure is not a problem by itself, because macOS puts unused memory to work as cache. The signals that matter are the color of the pressure graph and the Swap Used figure below it. Swap climbing steadily means everything on the machine, Chrome included, is waiting on the startup disk.

In that state, closing things does help, but not necessarily in Chrome. Another application may be the one applying the pressure, and no amount of browser tidying will move it. Checking the whole machine first and the browser second avoids a lot of wasted effort.

When it happens narrows down what it is

The time of day the slowness appears is nearly as informative as the task manager itself, and it costs nothing to notice.

Slow only right after launch usually means session restore. If Chrome is set to reopen the previous session, launching starts loading every one of those pages at once, and the machine is genuinely busy for a few minutes before settling. Opening the task manager during that window shows rows that never normally appear. Turning restore off, or narrowing what it reopens, removes that particular spike without changing anything else.

Slow after several hours of use is accumulation, and it is the case the task manager describes best. Long lived pages hold onto what they have allocated, and the difference between a morning reading and an end of day reading shows exactly which rows grew.

Slow only at the moment of switching to a specific tab is usually a reload after deactivation. The tab's contents were discarded while it sat unused, so returning to it starts from a fetch. That is waiting rather than load, and the resource numbers during it are low. This is the mismatch behind the common complaint that everything looks fine in the numbers and still feels wrong.

What the measurement means and what it changes

What the screen showed	What helps	What does not
Extension background pages at the top	Remove or disable unused extensions	Closing tabs
Subframes at the top	Close that one heavy page	Closing other tabs
Tabs at the top, many rows	Close unused tabs, raise the Memory Saver level	Removing extensions
High CPU, low memory	Stop video and auto refreshing pages	Freeing memory
Swap climbing in Activity Monitor	Reduce load outside Chrome as well	Changing browser settings
Every number low, still feels slow	Treat it as a retrieval problem	Anything on the machine side

The last row is more common than expected. Nothing is under pressure, the numbers all have headroom, and the experience is still bad, because the delay is the time it takes to locate the right tab among forty identical icons. That delay is real and it is not a resource problem, which is why it survives every attempt to fix it with settings.

Why it comes back within a few days

Suppose the measurement is done, an extension is removed, thirty tabs are closed, and the machine feels fine. The strip refills, usually within the week, and the reason is what survives a cleanup rather than what gets removed.

The tabs that get closed are the short lived ones: search results, a page opened to check one fact, a document that belonged to a task that has ended. The tabs that survive are mail, chat, the project tracker, the notes tool. Those are never candidates for closing, so every cleanup leaves them in place and new residue accumulates around them.

That means the count is structural. The permanent items sit in a strip designed for temporary ones, and everything else grows on top of them.

What to change first

Move the permanent items out of the strip and the rest of it empties on its own, because what remains has a natural expiry. Giving each web app its own window with its own session is what an app aggregation browser does, and the Features page describes how far that separation goes. The Supported apps list covers which services fit directly, and Compared with Ferdium sets out the differences between products built on the same idea.

Open the task manager and sort by memory before anything else. If extensions are at the top, no tabs need closing today. If tabs are at the top and most of the survivors are tools used every day, the next change is not the count but the place they live, and SpaceDeck is built around giving each of them one.