Caching

When you save a change in the Finder Builder, your visitors don’t see it instantly. The widget reads from a CDN, and the CDN cache adds a few minutes of delay between save and propagation. This page explains the caching model, how long things take, and what to do when you need a change to land faster.

The TL;DR

Five minutes is the typical wait. Worst case (rare): a visitor whose browser cached the old version sees that version for up to 10 minutes, but new visitors after the 5-minute mark always see the new version.

How caching works (light version)

DropAFinder caches in two layers:

1. CDN edge cache — the global edge servers that serve cdn.locationfinders.com. They cache the widget’s data with a 5-minute TTL.
2. Visitor browser cache — each visitor’s browser stores the most recent payload it loaded, used as a fallback if the CDN is briefly unavailable on the next visit.

The widget loads finder data through a two-step pattern:

1. Pointer fetch — a small JSON file naming the current payload version. Cached for 5 minutes.
2. Payload fetch — the actual finder data (design + locations) at a versioned URL. Cached forever (the URL changes whenever the data changes).

When you save, the pointer is rewritten to name the new payload version. The new payload is uploaded immediately. But visitors won’t pick up the new version until their cached pointer expires, which takes up to 5 minutes.

For the engineering rationale of this design (why pointer/payload split rather than single-URL with cache-busting), see the internal docs on the CDN pointer pattern.

”I changed my finder and it’s not updating”

This is the most common caching question. The diagnostic flow:

Step 1 — How long has it been?

If under 5 minutes, the answer is “wait.” The pointer hasn’t expired yet.

If over 5 minutes, continue to step 2.

Step 2 — Are you testing in the dashboard’s Live Preview?

Live Preview always shows your latest unsaved + saved state. If your change appears there, it’s saved correctly; the host page just hasn’t picked it up yet. Continue to step 3.

If your change doesn’t appear in Live Preview either, the change wasn’t saved. Open the Finder Builder and check for unsaved-changes indicators or browser console errors.

Step 3 — Hard-refresh the host page

In your browser, hard-refresh the page where the widget is embedded:

• Chrome / Edge / Firefox: Cmd+Shift+R (Mac) or Ctrl+Shift+R (Win/Linux)
• Safari: Option+Cmd+R

A hard-refresh bypasses the browser cache and forces a fresh fetch.

If your change appears after a hard-refresh but not on a normal refresh, the cause is your browser’s cache (not DropAFinder’s). The browser cache will clear on its own within minutes.

Step 4 — Try in incognito / private window

If your change doesn’t appear even after a hard-refresh, open the host page in an incognito / private browsing window. Incognito windows have an empty cache.

If it appears in incognito, your normal browser has a cached version that hasn’t expired yet. Wait a few more minutes, or clear the site’s cache from your browser’s settings.

If it doesn’t appear in incognito, the change isn’t reaching the CDN. This is rare; check that you’re actually viewing the page you think you are (right URL, right environment), and that the embed snippet on that page references the right finder key.

Step 5 — Wait the full 10 minutes

If you’ve done the above and it’s still not appearing 10+ minutes after save, file a support ticket — see Troubleshooting the embed.

What you can do to “force” an update

You can’t force the CDN cache to invalidate from the customer side. The 5-minute TTL is fixed.

What you can do:

• Use Live Preview for tight iteration. Your edits show up there immediately, even before save.
• Hard-refresh the host page once the wait is over to bypass your local browser cache.
• Use a different browser or incognito window to verify what new visitors will see.
• Wait the 5 minutes. Annoying, but reliable.

Why we don’t make this faster

The 5-minute pointer TTL is a deliberate balance:

• Shorter (e.g., 30 seconds) → updates propagate faster, but the CDN gets hit more often, edge cache hit rate drops, and visitors see slower load times
• Longer (e.g., 1 hour) → updates take much longer to propagate, frustrating customers who just want to see their change

Five minutes is the spot where most edits feel “current enough” while keeping the cache hit rate high.

If you have a use case where 5 minutes is genuinely too long, file a feature request — sub-minute propagation is technically possible but currently scoped out.

Per-visitor caching detail

When the widget loads on a visitor’s browser, it does the following:

1. Fetches the pointer (CDN-cached up to 5 min)
2. Looks at the pointer for the current payload hash
3. Checks localStorage for a previously-loaded payload at that hash
4. If found in localStorage, uses it (instant); if not, fetches it from the CDN (also fast since payloads are immutable)

The localStorage cache is per-visitor and per-domain. It cannot be cleared by you; it clears when the visitor clears their browser data, switches browsers, or — most commonly — when the payload hash changes (because you saved a new version).

Edge cases

• You revert a change. The pointer is rewritten to a previous payload version. The 5-minute clock restarts.
• You delete a Finder. The pointer is removed; the widget falls back to the origin API for one fetch, which then 404s. Visitors see an empty mount div. (See Troubleshooting the embed for the symptom.)
• The CDN is unavailable. Rare, but if the CDN can’t serve the pointer, the widget falls back to the origin API at api.locationfinders.com/api/ext/finders/details/{key}. The origin API is slower but always returns the latest version.

Where to next

• The “where do my analytics come from?” companion: Analytics
• Why edits in the dashboard don’t show up as visits: Preview mode
• A symptom-by-symptom diagnostic: Troubleshooting the embed
• For engineers — the internal mechanics: CDN pointer pattern (internal)