Finder extremely slow when opening large folders

Because these are photos from my old phones, I keep them together so I can scroll through my memories seamlessly. Splitting them into hundreds of folders would completely break that experience. Importing them into the Photos app isn’t an option either — many images lose their correct timestamp metadata on import, so the chronological order gets corrupted, and my iCloud plan can’t store such a large archive.

Being able to smoothly open a folder with 20,000 files is something even Windows PCs — and honestly, even a Raspberry Pi with far weaker performance than a 15-year-old Mac — can handle without issues. This is a very basic capability of a file browser and the operating system. Questioning the user’s behavior doesn’t really address the underlying technical problem.

Yes. I can open the drive itself without any problem, but when I open that folder with a huge number of files, it feels like it’s loading forever.

No, I haven’t installed any cleaning, optimizing, anti-virus, or VPN apps. My Mac only has Office and a few very common programming tools installed.

No, but I do have the Toolkit app from Lacie. It is for the LaCie 8TB d2 Professional purchased from the Apple Store.

Thanks for the detailed questions. Here are my test results:

The 500-file folder I mentioned was tested on my NAS. I tried two ways of accessing it:

• using open smb://<ip>/<share> from the command line (which simply triggers Finder to mount the SMB share under /Volumes), and
• using Finder’s Connect to Server.

In both cases, Finder takes around 15 seconds to open the folder.

The entire network path between my Mac and the NAS is a wired Ethernet connection, with no Wi-Fi involved anywhere in the chain.

I don’t think this is related to bandwidth. Since I’m using Name List view, the folder only contains about 500 filenames, which is just a few dozen kilobytes of data. Even if Finder needs to load some metadata, the amount of data should be far below 10 Mbps. My NAS and Mac have a theoretical link of 1 Gbps, and real-world file transfers over this wired connection reach around 60 MB/s (≈ 480 Mbps), so the available bandwidth is more than sufficient. Even if Finder were downloading image thumbnails, the bandwidth would still be adequate.

I also tested the same 500-file folder on external drives. For both the HDD and SSD (a LaCie drive and a Samsung drive), the first time opening the folder takes a few seconds, but after that the folder opens almost instantly. Both external drives are formatted as exFAT, which is the most common formats for external storage devices. I would expect both macOS and Windows to have solid support for exFAT, so the file system format should not be the issue.

On Windows, opening the same NAS folder or the same external drives is almost instantaneous, and the icons/thumbnails load very quickly. This suggests that neither the NAS nor the drives themselves are causing the slowdown.

However, when it comes to the folder with 20,000 photos, the behavior is much worse. On external storage, the first time opening this folder takes around 10-15 minutes, and even after it loads, scrolling through the folder in an icon/thumbnail view is still choppy.

On the NAS, the situation is even more severe: the initial open takes more than an hour, and once it finally loads, scrolling in thumbnail view is almost impossible and often causes Finder to become completely unresponsive.

So at this point, I still suspect that this behavior is specific to Finder.

Then use some other photo database tool for those. I'm sure there are many.

Opening a folder is one of the most basic responsibilities of an operating system. If I need to launch a third-party database application just to browse a directory, that would be absurd. A file browser should be able to enumerate files and show them promptly — that’s a minimum expectation, not an exotic feature.

Then write your own photo database and sell it!

The point of mentioning a 200-line previewer is simply to show that listing tens of thousands of filenames and even loading thumbnails asynchronously is not inherently difficult. A minimal previewer lacks the full integration and features of Finder, of course, but it demonstrates it is something that is very simple to be implemented.

It's not a factor of the CPU. It's a factor of the file system speed. You're using SMB, which is very slow and has no optimizations.

Yes, SMB has protocol overhead — but that overhead is not remotely large enough to justify Finder taking an hour to open a folder. The exact same NAS, the exact same SMB share, and the exact same dataset load instantly on Windows. By the simplest form of controlled comparison, that points strongly toward macOS Finder’s behavior, not toward SMB itself.

It's 2025. Wifi is usually going to be faster than a wired connection.

That statement is imprecise, and in most practical scenarios it’s incorrect.

When Wi-Fi and Ethernet have similar nominal link speeds, Ethernet almost always delivers lower latency, higher sustained throughput, and more consistent performance. Wi-Fi has unavoidable protocol overhead, collision-avoidance mechanisms, airtime scheduling, and significantly higher per-packet cost.

Even with a high-end Wi-Fi 7 router like my ASUS BE86U, my Wi-Fi 7-capable iPhone still measures noticeably slower speeds than wired — even standing right next to the antennas. And my Mac doesn’t even support Wi-Fi 7; it’s limited to Wi-Fi 6, which is slower still.

So the “Wi-Fi is faster” blanket claim simply doesn’t hold here.

It's not just downloading them. It's generating them. And then it's caching them. And then it reads the cache. And then it reads the attributes. And then it updates the .DS_Store. Take one down, pass it around, 19,999 files to go.

Finder generating or updating a .DS_Store file for tens of thousands of items may indeed introduce overhead. That could explain some delay — but not delays on the order of one hour. That scale is far beyond what metadata bookkeeping should cost on modern hardware, and still doesn’t explain why Windows Explorer handles the same SMB directory instantly.