Why WebDAV Is So Slow in macOS Finder (and What Helps)

Mount a WebDAV volume in Finder, open a folder with a few hundred files, and watch the spinner. Most people conclude the server is slow.

Usually it isn't. Finder's WebDAV client is unusually talkative, and that is what you are waiting on.

One folder, hundreds of requests

Here is what showing a single directory costs.

• A PROPFIND with Depth 1 to enumerate the folder. That part is fine. One request, one answer.
• Then a run of follow-up PROPFINDs as Finder inspects individual entries, re-checks properties it was already handed, and peeks into subfolders you only hovered over.
• A read of .DS_Store in every folder you visit, and a write on the way out, so your view settings stick.
• A probe for the AppleDouble sibling of nearly every file. Open a folder containing report.pdf and Finder also goes looking for ._report.pdf. On a server that has never seen a Mac, every one of those is a 404, and a 404 costs exactly the same round trip as a 200.
• A locking check while mounting. Finder wants to know whether the server speaks WebDAV class 2; a server that does not advertise LOCK can end up mounted read-only with no obvious complaint.
• A strong preference for responses carrying a Content-Length. Chunked replies are where Finder's client gets unhappy, which pushes servers into buffering.

Now do the arithmetic that nobody does. Three hundred files, three or four requests apiece, a server sitting 40 ms away: that is roughly forty seconds of waiting before a single byte of actual file content moves. None of that is bandwidth. It is latency multiplied by request count, and no amount of fibre fixes it.

Same server, different client, completely different experience.

What actually helps when WebDAV is slow on a Mac

The one setting genuinely worth changing stops Finder writing .DS_Store to network volumes:

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE

Log out and back in before judging whether it worked. Two caveats we would rather say out loud than bury: it applies to every network volume for that user, SMB shares included, and you give up saved view settings in exchange. Files already written stay put.

The rest is smaller, but real:

• Turn off thumbnails on the volume. View, then Show View Options, then uncheck Show icon preview. Otherwise Finder reads bytes out of your files just to draw the window.
• Keep directories under a few hundred entries where you control the layout. Request count scales with entry count.
• Use list view rather than icon or gallery view in a large folder.
• For bulk moves, skip the mount. A dedicated WebDAV client, or AnyStorage itself, does the transfer in one connection.

Notice that none of these make a round trip faster. They only reduce how many round trips happen. Which points straight at the other half of the equation.

Move the round trips to loopback

If you cannot cut the request count much, cut the latency instead.

That is the model AnyStorage is built around: the WebDAV server runs on your own machine rather than across the internet. In the sidebar, open Services, then the WebDAV tab, then Start. The default endpoint is http://127.0.0.1:3211, port configurable if 3211 collides with something. HTTP Basic auth is always on, with username anystorage and a 24-character password generated on first use, both editable, both with copy buttons. Then Finder, Go, Connect to Server, or just Cmd+K, paste http://127.0.0.1:3211 and connect as a registered user with those credentials.

Finder behaves no better than before: same PROPFIND storm, same ._ probes. The difference is that all of it travels over loopback and comes back in a fraction of a millisecond. Several hundred of those is still nothing.

Every storage connection currently connected in the app appears as a folder at that root, named after the connection: S3 and R2 buckets, Google Drive, Dropbox, an SFTP box, a local folder, 20 connection types in all. The only thing still crossing a real network is file content, and reads are streamed with HTTP range support, so scrubbing a video in QuickTime pulls the range it needs instead of the whole file.

What this does not fix

Finder is still Finder, and a local endpoint cannot invent throughput your provider is not giving you.

• A prefix holding 50,000 objects lists slowly because the backend lists it slowly. Loopback removes Finder's overhead, not the API call underneath.
• On the free tier the WebDAV server is read-only. Read-write is a Pro feature, and you can deliberately keep it read-only on Pro too.
• There is no TLS in the current version. The URL is plain http and Basic credentials cross in plaintext, which is why we bind to 127.0.0.1 by default. LAN access binds 0.0.0.0 and the app warns you first.
• There is no real file locking, so two machines editing the same file are not protected from each other. Do not treat the mount as team infrastructure.
• After an app restart, a connection appears under the WebDAV root only once you open it in the app, because connections connect lazily. New connections appear without restarting the server.

If Finder still irritates you after all that, browse inside the app and keep the mount for the moments when some other program insists on a real path.

Questions