...

• 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 A lot of the overhead is also in making many concurrent requests to Studio to get the data to populate these.

Use Cases in Libraries

There are at least a few use cases for previewing libraries content that I know of:

...

So we might do (1) or (2) for the results view when it's in list-mode (or possibly neither). I'm not clear on whether we should be aiming for (2) or (3) on the preview pane though.

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.

List View

Course Unit Page

Issues to investigate when preview is open on the new Unit page:

• Remove unnecessary JS assets (loading things for unrelated XBlocks)

• Remove MathJax init

• …