I still have no idea what this could be. I think VRAM is ruled out by small projects doing it, and V8 garbage collection is ruled out by the fact Chrome has the same javascript engine, but doesn't reproduce the problem. I think export-mode only is probably not actually the case - the export-time optimisations usually help improve performance and there's really absolutely nothing in the export process that could cause long pauses, so I feel it is more likely it is a sporadic issue that has not been observed in preview mode only by chance (perhaps because people spend less time in preview and more time in exported games?). 4 seconds is also an extraordinarily long pause for any local activity: not even garbage collection covering hundreds of megabytes of memory, or very large disk accesses, would take that long. It might even possibly somehow be a blocking network request.
I would guess the most likely cause is the node.js component of node-webkit, since node-webkit is more or less identical to Chrome apart from in that regard, but that is out of our control and something the node-webkit developers should look at. It's also totally impractical to debug a sporadic issue that only reproduces after ~20min - debugging often involves running and testing the issue 10, 20, 30 times or more, and hours of sitting around watching a game does not sound like it would get anywhere. I think the best approach is to report the issue to the node-webkit bug tracker with (as always) as much information as you can possibly provide, and see what their view on it is.
Node-webkit is also now two versions behind Chrome; it may be the latest version of Chrome has performance improvements which node-webkit will also get when it catches up.
It's not always after 20 mins, to be fair. Sometimes much quicker. For me it can stop for about 5 seconds too.
But why it never happens on previews? I tend to run preview on second screen sometimes for an hour or so and no hiccups at all!