Page Weight for gist parser - need it be reduced?
zawsx opened this issue · 1 comments
When using just-dashboard, you've kindly provided the option to submit ready-written dashboard and data files. With this, however, the bundle.js (as used for one of your simple pie chart examples for instance) is 907kb ([http://bottoml.in/e/kantord/2973bdd4ad689642562018bb4091ffbd]). Doesn't that make the idea a bit restricted in the width of uses? I had hoped to use it in a sort of 'i-frame' manner (without the iframe of course) as I think you intend.
However, in a text and graphics-heavy page, adding 1Kb to that page weight for a graph makes it noticeably slow to load when I try it - will people for the graphs to load whilst browsing the page, especially on mobile? Obviously caching will alleviate massively but for me, it'll only be one page per website so that doesn't help.
A news article might well have a page weight of 1Mb. If it were to include an auto-generated graphic (or set of graphics), generated by just-dashboard (as in http://bottoml.in/e/kantord/2973bdd4ad689642562018bb4091ffbd), there would be a further delay, after the 'main' page has loaded.
Maybe if the just-dashboard bundle.js could somehow be able to use async defer from the calling (1Mb) page, then the delay wouldn't be noticeable? Destroy some simplicity of use, so maybe as an option?
It is definitely a goal to reduce bundle sizes, as they are without doubt oversized. There are many opportunities, but it might not be easy to make it very small. The ideal would be to separate each chart component into separate chunks that only depend on the relevant parts of d3. I'm not sure whether it's possible to do that with billboardjs though.