Suboptimal performance of dweets on dwitter

In [d/11965](https://www.dwitter.net/d/11965) Cantelope brings to our attention that some dweets perform noticeably more slowly on Dwitter than they do on CodeGolf.tk

For a demonstration, compare: https://www.dwitter.net/d/11913 and https://codegolf.tk/a/366
(I observed the difference in Chrome)

Why is this, and can the loss be fixed somehow?

Are there redundant `postMessage()` calls being made? Are we reprocessing `u` on dwitter before each frame? Is it the infinite loop detector? Is it CSS?

How can we display framerate on CodeGolf.tk? What is the meaning of life?

If it _is_ the infinite loop detector, then I think we agreed before that's it's a price worth paying. In that case, perhaps we should file a bug on CodeGolf.tk that it lets us run dweets which lock up the browser?! :evil-cheeky-face:

~Edit: I don't believe it is the loopbuster because 1) Setting `window.instrument = x => x` in the iframe didn't change the FPS, and 2) the loopbuster doesn't really instrument `eval()` expressions much anyway.~ Edit: Based on KilledByAPixel's test, I think the loopbuster may be having an effect!

Start by comparing d/11913 on Dwitter with CodeGolf.tk/a/366 in Chrome and measure their frame rates. Trace the suspected postMessage calls, per-frame processing of u, infinite-loop detection, and CSS effects to identify the source of the performance gap. Done means explaining the cause and either fixing the loss or documenting why it is an accepted tradeoff.

Written by the indexing model from the issue text.