The major XBlock rendering in Studio are:
Server side processing (~100-200 ms)
Loading of CSS/JS assets ( ? ms )
Processing of JS (compile time and execution)
This includes MathJax execution on load
I don’t have precise measurements at the moment, but the part that’s going to hit us the worst is
Single Preview Panel
Things to investigate:
If resource loading/init were the largest thing, we could look into pjax or similar solutions, in order to swap out an individual component’s worth of content on an already loaded XBlock rendering page.
For instance, we could make one background iframe per block type, and swap iframes + content to load in it at the time the user clicks. We cam fetch content differences pretty quickly, and it should be cacheable for most types. JS and CSS would not need to be reloaded.
There’s an extra callback for getting a handler url, but it seems like that could come over in the initial response?
Actual resource loading doesn’t seem that bad in libraries. Capa has about 800 KB of stuff, uncompressed.