We’ve been getting flak from several clients about slow refresh times in draft mode. I’m fairly confident this is a service-level issue—not an implementation one. Here’s why:
The lag is being reported across multiple, unrelated projects.
When I inspect the behavior, the delay is consistently in waiting for the server-sent event from graphql-listen.datocms.com/channels to emit an update.
The video below shows how long it takes for that event to arrive. (Note: CMS content is redacted.) I saved a draft right at the start of the video. The update event takes 8-10 seconds to come through. I then save again almost immediately after so you can see multiple attempts.
The editorial experience is currently so sluggish that editors are giving up and just refreshing the page—defeating the entire point of real-time preview.
@roger I’m not sure exactly when it started—definitely a couple of weeks ago at least. I figured it might resolve on its own, but since it hasn’t, I wanted to get it on your radar. Glad I did, and good to hear you’re able to reproduce it—hopefully that means a fix is on the way.
No fix yet, but a quick update: This was indeed on us, not anything you did. It was an unintentional side effect of some backend tweaks we made a few weeks ago. We had to tweak some internal delays to avoid a webhook cache race against a CDN. But that also unintentionally slowed down real-time updates by a few seconds.
The devs are discussing whether there’s anything we can do about that. Will report back as soon as I have more info.
Thanks @roger as a temporary solution i’ve implemented a polling based workaround via a useSWR hook for a few projects that is working well, but it would obviously be great to return back to a server side event listener with useQuerySubscription once resolved.
An update for you here. We are working on a possible fix that could improve the speed of real-time updates and might even go faster than before. We’ll keep you posted as soon as we have news.
