Hey guys. We have a sveltekit website and Iām noticing the live updates take too long to apply. Whether in Preview or live.
I checked the related closed topic, but Iām still facing this issue. I also installed Web previews Plugin instead of a private one Iāve been using but to no avail. Thank you in advance.
Hello @mohamed.elshazly
When you say ātake too longā, do you mean a few seconds (for example 5 to 15 seconds), or are we talking tens of seconds or minutes?
A first thing to double check is whether youāre hitting Save or Publish. If your models use the Draft/Published system, saving changes to an already published record puts it in āUpdatedā, and the live site will keep showing the last published version until you publish again. This is expected behavior. The draft and updated versions are only returned if your preview requests include drafts (DatoCMS docs: https://www.datocms.com/docs/general-concepts/draft-published and API headers (environments, drafts, strict mode, cache tags, content link) ).
On the Web Previews plugin, switching from a custom preview integration to the plugin wonāt make content propagate faster by itself. The pluginās job is to generate preview URLs and optionally reload the iframe after a record update. The actual freshness depends entirely on how your SvelteKit site fetches data and what caching exists in front of it. If you want the plugin to force a reload after each save, your preview-links endpoint needs to return the reloadPreviewOnRecordUpdate option (plugin docs: Web Previews - Plugins ā DatoCMS ).
Also, for truly āliveā previews without refreshing, your frontend needs to be wired to the Real-time Updates API (Server-Sent Events). In SvelteKit, the recommended approach is @datocms/svelteās querySubscription store (docs: https://www.datocms.com/docs/svelte/real-time-updates and Real-Time Updates API Overview ā DatoCMS ). With real time updates, updates are usually quick but itās normal to see a few seconds of latency. If youāre expecting immediate updates at 0 to 1 second, thatās generally not realistic.
The other common cause is that the site is statically built. If youāre using SvelteKit prerendering or adapter-static, both āliveā and āpreviewā routes will keep serving the build output until a new build happens, so the delay you see is your build time plus any CDN caching. In that setup, preview can still be instant if you implement preview as SSR (no prerender) and fetch draft content on request, but the public live site will still need a redeploy to reflect new publishes.
If you can share how your site is deployed (Vercel, Netlify, etc), whether itās SSR or prerendered/static, and roughly how long the delay is in seconds, I can point you to the most likely culprit. If you prefer, you can email support@datocms.com with a link we can test plus the relevant SvelteKit load code where you fetch from DatoCMS (including any cache headers or fetch caching options), and weāll take a closer look.
If it helps to compare against a known-good setup, our SvelteKit starter includes draft mode, Web Previews plugin support, and real time updates: https://www.datocms.com/marketplace/starters/sveltekit-starter-kit and https://github.com/datocms/sveltekit-starter-kit. You can also browse other starters here: Project starters - Free demo projects - Marketplace .
When you say ātake too longā, do you mean a few seconds (for example 5 to 15 seconds), or are we talking tens of seconds or minutes?
Weāre talking roughly a few minutes (~7 mins).
Weāre hitting Save on a draft page, but the preview is not showing the latest version of draft.
I added reloadPreviewOnRecordUpdate to the web previews plugin, and it does its job and refreshes the iframe, but no changes are applied.
Okay so Iām using @sveltejs/adapter-vercel and I have sveltekitās SSR implemented. I noticed, however, that when I redeploy and refresh the link it works fine.
A delay of ~7 minutes, plus the fact that a redeploy makes the newest content show up immediately, almost always points to caching on the frontend or hosting layer, not DatoCMS taking minutes to apply changes.
On the DatoCMS side, saving a draft should be visible in preview immediately as long as your preview requests are actually asking for drafts. For the Content Delivery API that means sending X-Include-Drafts: true, and if youāre using @datocms/cda-client itās the includeDrafts: true option (https://www.datocms.com/docs/svelte/accessing-draft-updated-content-with-fetch and https://www.datocms.com/docs/content-delivery-api/api-endpoints). If that header is missing, saving a draft wonāt affect what the API returns, so the preview will look āstuckā no matter how many times the iframe reloads.
Given that youāre on @sveltejs/adapter-vercel, the big thing Iād check next is whether anything is enabling caching at the Vercel level. In SvelteKit on Vercel this commonly happens via ISR on routes (export const config = { isr: { expiration: ... } }), which will serve cached HTML until the expiration window passes, and 5 to 10 minutes is a very typical value. The adapter docs cover this here: https://svelte.dev/docs/kit/adapter-vercel. If you have ISR enabled, you generally want it disabled for preview routes, or you need to make sure your preview mode is truly bypassing the cache.
The other common cause is Cache-Control headers coming from your SSR route. If the response includes something like s-maxage, Vercelās CDN will cache it and youāll see exactly this kind of āit updates eventuallyā behavior. For preview, itās usually best to explicitly return Cache-Control: no-store from the preview page response so every refresh is a real request. Vercelās caching behavior is explained here: https://vercel.com/docs/headers/cache-control-headers and https://vercel.com/docs/cdn-cache. In SvelteKit, you can set response headers from server load using setHeaders (https://svelte.dev/docs/kit/load).
One more thing to watch for is app-level caching inside your code. If youāre using Apollo, urql, Houdini, or any client with an in-memory cache thatās created at module scope, a warm Vercel function can keep serving stale cached results for minutes until the instance is recycled. A redeploy effectively wipes that, which matches what youāre seeing.
If you want a known-good reference to compare against: https://github.com/datocms/sveltekit-starter-kit.
If you paste the part of your SvelteKit code that fetches from DatoCMS (your +page.server.ts load, or the shared helper that calls the CDA) and confirm whether youāre using ISR anywhere (export const config = { isr: ... }), I can tell you exactly where the 7 minute delay is coming from. If youād rather share privately (if the project you are working on is not open sourced), feel free to email support@datocms.com with those snippets and a preview URL we can test
Hey thanks a lot, I believe it was indeed the caching. I added the header, and it now takes approximately 2~3 seconds