Site Cache enabled with TTL versus disabled for immediate external file visibility on large sites

Answer

Keep Site Cache enabled with a short TTL for normal design work and do not disable the cache for commit windows. Use the Files panel Refresh command immediately after external edits or a version-control pull to force an instant update. Disabling the cache is reserved for short diagnostic checks, not daily use on large or network-mounted sites.

What to configure for alternating design and external commits

• Site Cache: Enabled. This keeps the Files panel and site-wide features responsive by using a local index of names, timestamps and site-map data instead of scanning the filesystem on every request.
• TTL: Short, e.g. 60–120 seconds. A short TTL gives near-real-time visibility without manual action while preserving most of the responsiveness benefit.
• Commit window workflow: After an external edit, git pull, or CI sync, run Files panel Refresh once before starting design work. Refresh bypasses the TTL and rebuilds the cache immediately.

Disabling Site Cache guarantees immediate freshness because Dreamweaver queries the filesystem directly for every operation, but it makes navigation noticeably slower on large local sites and especially on network mounts. The performance cost outweighs the freshness gain for routine work.

Likely explanation vs confirmed facts

Likely, based on model knowledge: Site Cache stores a local index; with TTL set, metadata is considered fresh until the TTL expires. The Refresh command forces an immediate rebuild regardless of TTL. A very short TTL reduces the caching benefit, particularly on network mounts where metadata checks still incur latency.

Confirmed facts: Current public documentation for Dreamweaver Site Cache behavior is limited and version-dependent. The exact TTL range, UI location for the setting, and the precise interaction of Refresh with background cache updates are not verified here and should be confirmed in the installed Dreamweaver version. Treat the steps below as a planning draft for human review.

Minimal steps for this case

1. Leave Site Cache enabled. Set TTL to a short window that matches your commit cadence, typically 60–120 seconds.
2. After any external change, open the Files panel and run Refresh to force an immediate cache rebuild.
3. During active design sessions with no external edits, rely on TTL auto-refresh. Avoid disabling the cache.
4. Monitor panel response time. If navigation remains sluggish with a short TTL on a network mount, increase TTL slightly and rely more on manual Refresh.

Practical verification

• With cache enabled and TTL set, make an external edit to a file and observe the Files panel updates automatically after ~TTL.
• With cache enabled, make an external edit then click Refresh and confirm the panel updates instantly, bypassing TTL.
• Temporarily disable cache and edit externally to confirm immediate visibility, noting the panel lag on a large site.

One diagnostic detail that changes the recommendation: the site file count and mount type. If you can confirm approximate number of files and whether the site is on local disk vs SMB/NFS/SMB, the optimal TTL and whether a short TTL remains viable can be refined.