Some of my notebooks do not render a thumbnail.
Running time too long? How do I check that? How can I fix it?
Can I render them myself and have them cached by Observable?
Notebooks in question:
The limit is 30s of runtime on the server instance, according to this post. I don’t know how to check it in advance, but one thing that I’ve been doing is placing userAgent guards like this:
if (navigator.userAgent.match('HeadlessChrome'))
return;
// rest of cell follows...
at the beginning of long-running cells. I got the idea from @mootari’s notebook:
Thanks.
I’ve:
- added a elapsed render timer in the footer in
show(); and - disabled blur filters when
navigator.userAgent.match('HeadlessChrome').
Let’s see what happens.
Still curious, because I find it hard to believe that it takes more than 30s to render.
Wonderful! I’ve got a thumbnail on https://beta.observablehq.com/@martien/flower .
It says the render time equals 4 ms…
The thumbnail’s got no blur, as expected. Maybe that’s the culprit?
And it’s gone again. Baffled.
Yeah, I’ve noticed that with my notebooks as well. The only thing I can think of is that it may depend on things like the overall server load when the thumbnail maker runs the notebook.
Apparently the Observable team has other plans for the thumbnails, so at some point in the future we won’t have to worry about this sort of thing anymore.
Okay, I’ll just wait for that then. I dislike creating my own static heroes, though.
1 Like
Hmmm… forking the notebook:
- Renders the new (forked) notebook faster.
- Brings back the thumbnail for the new notebook.
Seems like a large edit history slows down the thumbnailer process.
Not necessarily. Could be that the load on the instance is lower at the moment, and updating your original notebook would have yielded the same result (note: cell content or positions need to change for the thumbnail to update).
The actual timeout appears to be somewhere around the 12s mark. I’ve created two notebooks to test thumbnail generation for:
- a single image, moved bottom to top with increasing delays,
- multiple images, created bottom to top with increasing delays.
The tumbnails and notebooks can be reviewed here:
2 Likes
Hey Fabian,
Apologies for the late reply. Enjoyed a couple of busy days.
Thanks for this nice approach to test this. And yes, I can see the 12s mark.
Then again, I cannot imagine that my little notebook takes more than 12s to render, not even on the thumbnailer.
When I time it, it’s under 2ms.
If you take a look at my overview page on https://beta.observablehq.com/@martien and zoom in using your browser, you can see in the footer of Flower—a simple fork of Flower (old)— a render time in ms of 0, 1, 2 max.
Flower (old) fails to show a thumbnail, despite being the same code. I cannot figure out why that may be.
Puzzled as ever 
Your timing only accounts for the evalutation of the show function. You’ll want to start your timer from the moment the notebook loads: https://beta.observablehq.com/compare/64effbd662037e97...8156160658b490e0
In the case of my fork the thumbnail generated without problems. Try adding a whitespace somewhere in your “Flower (old)” notebook and check the thumbnail again. I’m fairly certain it will generate properly right now.
How do you mean, “add white space”? In the code? In the chart?
My experience is similar to yours. When I forked Flower, it renders the thumbnail correctly.
In any cell. It’s just to change the notebook content and force a new thumbnail to be generated.
From what I’ve gathered it really for the most part depends on external factors, like overall load on the server that’s responsible for thumbnail generation, and response times from external sources (e.g. unpkg.com).
Ah, clear. Thanks.
Re unpkg, I assume that’s run under the hood. Is it run for the notebook itself, too? How does the revision history influence the unpkg time?
As far as I can tell there’s really nothing special going on. The headless Chrome instance just accesses notebooks like you in your browser would. The only difference is the URL it uses, which seems to render just the notebook without any Observable UI.
I also still don’t believe that the revision history affects the load time. Again, try changing your notebook content (so that its hash changes) to force a new revision, and in turn force the thumbnail to be regenerated.
I’ve tried forcing regeneration repeatedly, without success.
I’ll let it go for now. Thanks for your lasting support.
As far as I can tell forks keep the revision history. Would you humor me and republish Flower (old) so that its update date (mouseover on publish date) shows today?
I just humoured you.
Thanks! And again, a fork’s thumbnail appears almost immediately. …
@mbostock @tom Possible bug in thumbnail generation, tldr:
- Thumbnail for https://beta.observablehq.com/@martien/flower does not generate despite multiple updates,
- thumbnails for vanilla forks of the notebook generate almost immediately.
1 Like