At times a notebook takes over 14 seconds to reload. I press reload, the browser window goes blank for 14 seconds or so, and then the notebook correctly renders itself in a second or two.
Subsequent reloads and serenaders are done in about 2 seconds.
Monitoring the timeline (in Safari) shows HTTP GET takes 19.93s.
Seems this happens after not reloading my notebook for awhile, while having edited it. Then again. I’m not sure if this is related.
How to fix this?
The most likely reason is that e.g. unpkg doesn’t have a cached version of one or more dependencies and needs to generate it on the fly. The waterfall in the network tab should show you which resources take up most of the time.
Unfortunately there’s not much you can do about it, I think, other than displaying a loading message that you remove once all resources have been loaded.
Edit: Can you link to a notebook where this happened recently? One should be able to simulate the delay by throttling network speed in the developer tools.
Happens regularly when I’ve been editing it for some time and not reloaded it for a while.
Few more questions to narrow things down:
I believe what’s going on here is that this notebook has an especially large history (currently 9,918 versions), and so when it happens to fall out of the cache, it can take a few seconds to load. We can look at optimizing the loads of notebooks with large histories.
Exactly what I thought. I’d be happy to delete the history if possible. Can I go into git and do so?
No, we don’t support destroying history. We’ll consider some optimizations on our side to improve this experience. You can workaround this issue by manually copy-pasting the contents of this notebook into a new one, but that’s tedious and necessitates a new notebook, so it’s not a particularly good solution.
Okay. Can I download the code and paste it into a fresh notebook and then delete the old one?
Hi @mbostock, sorry to bother you with this once more.
Having a load time of >10s makes notebooks beyond practical use, unacceptable even, TMHO. Potential visitors will either hit reload several times—making the problem worse, or simply leave.
I am seriously looking for a solution or workaround. I will be happy to go through any tedious and boring labour to get it fixed, while keeping the original title and user friendly URI (part of the UI).
Please tell me what I (or you) can do to get load time back to <1s.
P.S. I wonder if the versioning system under the hood uses forward or reverse deltas to get to the current revision. I remember from ancient times (1985) that SCCS used forward deltas: it created the current revision by applying all deltas since birth. Over time, performance suffered terribly. So we switched to RCS, which keeps the latest revision ready to check out. Earlier revisions could be retrieved by reverse deltas back in time.
P.S. 2 I’ve fallen in love with Observable (and D3), so do want to continue investing time and effort in it.
Hey Martien,
We did some digging, found a culprit SQL query which was soaking up the time, and just shipped an optimization that speeds it up by ~100x. This notebook should load comfortably in <1s from now on.
Thanks for bringing this to our attention, and sorry for the pretty rough load times. Here’s to fastness again.
-Tom
Dear League of Gentle Men of Observable,
Thank you so much for your quick and effective response. You’ve made me feel humble and extremely happy. It’s 9 p.m. overhere, and I’m sure I’ll get a very good night of sleep and some very sweet dreams (about NeWS and other things, perhaps).
Again, kudos in ample supply.
Wish you all a very good weekend.
Martien.