Finder is slow to show files in a folder, and what makes it wait

A folder opens, and the window stays empty. The spinner in the corner turns. Ten seconds later the files appear, and scrolling still stutters. The folder has not changed since yesterday, so something else is taking the time.

Finder does not simply list the files in a directory and draw them. Before anything shows up, it asks several other parts of macOS for information: thumbnails for each file, sizes for each subfolder, tags, iCloud status, and whether the volume the folder lives on is still answering. Any one of those can stall, and while it stalls, the window waits. Finding out which one is doing the waiting is most of the work.

What happens between the double click and the list appearing

When a folder opens, several things start at once.

Finder reads the directory itself, which is fast on internal storage even with thousands of entries. It then reads the folder's saved view settings, which decide how much more work follows. In icon view, or in list view with icon previews on, Finder asks the Quick Look thumbnail service for a preview of every visible file. For photos and video that means decoding part of each file. If the folder holds a few hundred large images, that request queue is the whole delay.

At the same time, Finder checks the state of the volume. For an external drive that has spun down, the first access wakes it. For a network share, Finder sends a request and waits for a reply. If the server is gone, the wait lasts until the connection times out, which can be tens of seconds, and nothing appears in the window during that time.

There is one more setting that is easy to forget. In list view, Calculate all sizes tells Finder to walk every subfolder and add up what is inside before it can display a size. On a folder with deep nesting, that walk takes longer than everything else combined, and it runs again each time the folder is opened.

None of this is visible from the window itself. The spinner looks the same whether Finder is decoding a thousand JPEGs or waiting for a NAS that is switched off. That is why the first step is measurement rather than a fix.

Find out which part is waiting

Activity Monitor answers the question in under a minute. Open it, switch to the CPU tab, sort by CPU percentage, then open the slow folder and watch which process climbs.

What rises in Activity Monitor	What it means	Where to look next
Finder itself	Finder is doing the work: view settings, large directories	View options for that folder
ThumbnailsAgent, QuickLookUIService	Previews are being generated	Icon previews and the files themselves
mds, mds_stores, mdworker	Spotlight is indexing	Recently copied files, Spotlight privacy list
Nothing rises at all	Finder is waiting on a reply	Network shares and external drives

The last row matters most, and it is the one people miss. If no process is busy while the window sits empty, the Mac is not slow. It is blocked, waiting for a volume that is not answering. Adding memory or clearing caches will not change that.

For a folder that is slow every time, a second measurement helps. With the window stuck, run this in a terminal:

lsof -p "$(pgrep -x Finder)" | grep -v '/System/'

The output lists what Finder currently has open. A network path or an external volume near the bottom of that list is a strong hint about what it is waiting for.

Turn off the view settings that cost the most

If Finder itself is the process using CPU, the view settings for that folder are the first thing to change. All of them are per folder, so a change in a scratch folder does not affect anywhere else.

Open the slow folder and press Command+J to bring up view options. Two settings do most of the damage.

Show icon preview replaces the generic document icon with a rendering of the file's contents. In a folder of raw photos or video, every visible item becomes a decode job. Turning it off means files show a type icon instead, and the list appears immediately.

Calculate all sizes, in list view, makes Finder traverse every subfolder before it can fill in the Size column. On a project folder with build output or a node_modules directory inside it, the traversal can cover hundreds of thousands of files. Leave it off and use Command+I on a specific folder when a size is actually needed.

Switching from icon view to list view with Command+2 avoids a large grid of thumbnails in one step. Closing the preview pane with Command+Shift+P stops Finder from rendering the selected file each time the selection moves, which is what makes arrow key navigation feel sticky in a folder of video files.

If the thumbnail service is the process using CPU rather than Finder, the cache behind it may be the problem rather than the files. Rebuilding it is safe and affects no original files:

qlmanage -r cache
qlmanage -r

The first folder opened afterwards will be slower, because previews are being made again, and later opens should be faster.

Disconnect what is not answering

When nothing shows up in Activity Monitor, the delay is a timeout. Finder is waiting for a volume.

Network shares are the common case. A Mac that mounted a NAS at home and then moved to a café still has the mount listed. Finder tries to reach it whenever something touches that path, and waits for the connection to fail before moving on. The same happens with a share left mounted after leaving an office network.

The fix is to eject rather than to ignore. In the sidebar, click the eject symbol next to every share and external volume that is not needed right now. Then restart Finder and try the folder again:

killall Finder

Recent items and sidebar shortcuts count too. A sidebar entry that points at a server which no longer exists gives Finder something to check on every launch. Right click and remove the entries that are no longer real.

Spinning hard drives create a milder version of the same delay. After they park, the first access waits for the platters to spin up, which can be several seconds. That is normal behaviour, not a fault, and the practical answer is to connect them when they are needed rather than keeping them mounted all day.

Files stored in iCloud Drive with Optimise Mac Storage enabled behave similarly. The file list is local, but opening or previewing a file that has been evicted means downloading it first. On a slow connection, a folder full of evicted files feels broken even though nothing is wrong.

Smart folders and Recents are searches, not folders

Two entries in the sidebar behave differently from everything else, and they are worth separating out because they are slow for a reason that no view setting touches.

Recents is not a directory. Opening it runs a Spotlight query across indexed volumes and assembles the results. So does any smart folder saved from a search window. When the index is being rebuilt, when a network volume is included in the search scope, or when the query is broad, that assembly takes noticeably longer than reading a real directory, and the window stays empty while it runs.

If Recents is the window that opens at launch, every Finder launch pays that cost. Under Finder Settings, in the General tab, New Finder windows show can be set to a specific folder instead. Pointing it at a normal directory, such as a home folder or a current project, means a new window lists a directory rather than running a query. Smart folders can stay in the sidebar for occasional use without being the first thing that opens.

Look at free space and the indexer

Two background conditions make every folder slow rather than one.

Free disk space is the first. macOS writes caches, thumbnails, and temporary data constantly, and when the volume is nearly full it has nowhere to put them. Check System Settings, then General, then Storage. A volume with a few gigabytes free will feel slow in ways that no view setting explains, and freeing space is the only fix.

Spotlight indexing is the second. After a macOS update, a large copy, or a restore from backup, the indexer reads through the new files. While that runs, mds and mdworker use CPU and disk, and Finder competes with them. It normally settles within a few hours. To check whether indexing is even enabled on the boot volume:

mdutil -s /

Folders that never need to be searched can be excluded. Build output, dependency directories, and large media caches are good candidates. Add them under System Settings, Spotlight, Search Privacy, and the indexer stops re-reading them every time they change.

A quick order to work through

Rather than trying everything, work down this list and stop when the folder opens quickly.

Step	Action	Time	What it costs
1	Watch Activity Monitor while opening the folder	1 minute	Nothing
2	Eject network shares and unused external drives	1 minute	Reconnecting later
3	Switch to list view, close the preview pane	Seconds	A visual preference
4	Turn off icon previews and Calculate all sizes	Seconds	Sizes and preview icons
5	Rebuild the Quick Look cache	1 minute	One slow first open
6	Check free space and Spotlight indexing	5 minutes	Time spent freeing space
7	Move the Finder preference file aside and relaunch	2 minutes	Sidebar and view settings

Step seven is the last resort, and it is reversible if done carefully. Move the file rather than deleting it:

mv ~/Library/Preferences/com.apple.finder.plist ~/Desktop/finder-plist-backup
killall Finder

Finder comes back with default settings. If nothing improves, move the file back and the old configuration returns.

Folders that are being written to while they are open

One pattern deserves its own note, because it has become common and none of the fixes above address it directly.

An agent or a build process runs in a terminal and writes output into a folder. That folder is open in Finder in another window, so the results can be watched as they land. Every write triggers a file system event, Finder redraws, the thumbnail service queues a preview for the new file, and Spotlight adds it to the index. A build that produces several hundred files generates all three reactions several hundred times.

Finder is not failing here. It is doing exactly what it was asked to do, for a folder whose contents change faster than a person could read them. The practical responses are to keep that folder closed until the process finishes, to add it to the Spotlight privacy list so it is not indexed, and to watch progress in the terminal rather than in the file list.

There is also a structural answer: work in a tool where the folder listing and the terminal share one window, so checking what an agent produced does not mean switching windows and pulling Finder into the loop at all. How that differs from Finder is set out on the comparison page, and the features page covers what a combined window includes. For agents that keep running after the desk is empty, answering from an iPhone or iPad covers reaching the same session from a phone.

What to change first

Open Activity Monitor and watch it while the slow folder opens. If nothing is busy, eject the network shares and unused drives, because the delay is a timeout rather than a workload. If Finder or the thumbnail service is busy, turn off icon previews and Calculate all sizes for that folder.

If the same folder keeps causing trouble because something is writing into it constantly, the setting is not the problem and moving that work into a window that already holds a terminal removes the round trip. Atriens is built for that layout.