Smaller JS package sizes!

I think we’ve beaten the world record of biggest JS bundles. Let’s contain this.

State of things:

$ du dist/*|sort -n -r | head
14640   dist/dashboard.13e463a9f8b8738180b3.entry.js
14032   dist/explore.248040abcbbaf60a59b9.entry.js
6072    dist/sqllab.ea495dee48ee855009f6.entry.js
2296    dist/addSlice.66d103d9c1275427d857.entry.js
2064    dist/profile.90e39d37579af32c6091.entry.js
2040    dist/welcome.41f4f4057ba02c52f350.entry.js
1072    dist/common.7ece420589d15408bce6.entry.js
520     dist/theme.ed0d61cb90e4574ee3da.css
216     dist/89889688147bd7575d6327160d64e760.svg
160     dist/dashboard.13e463a9f8b8738180b3.css

Ideas:

• break out a superset-visualizations npm package with sub packages for each visualizations sets, one for deckGL-related visualizations, one for nvd3-related, and any other big chunks separately. This will also pave the way towards a superset-embedables package
• the biggest win is to break out the deckgl related packages (luma.gl, mapbox.gl, deck.gl, …)
• in the main app, visualizations bundles should be lazy loaded
• working viz out of explore and dashboard, should make those much leaner
• keep theme.js we still need that has standalone
• maybe add a common.js with things like React and commonly used utilities that we need across the board
• …

[williaster]

think I have a proof of concept (this is just lazy loading the visualizations, could do more with mathjs, etc). dashboard + explore are cut in half on their own.

before

after

[Neel-rishabhsoft]

Hi, I am looking for improving the performance my superset charts. Recently we upgraded our superset to the latest version. We are using MySQL database both as data source for charts and as the meta-database. We have also optimized the queries such that they don’t take not more then 1-2 seconds in running. We are using charts in a standalone mode inside iframes, then those iframes are integrated with our angular application. For the purpose of applying filters we are editing the chart-url and that is being handled from the angular side. We did this sort of implementation as we were looking for a more flexible orientation of charts inside our web applications. However, we are currently facing performance issues in our production environment(which is set up with gunicorn, apache server for reverse proxy and superset installation on a centos 7 remote server). I am currently looking for some performance enhancements from superset UI side as the chart rendering is taking a long time(around 2-3 minutes). We have approximately 10-15 charts in each web-page.

Can anyone from the community please let me know if this current issue has been fixed with superset-ui plugins implementation. If yes, can you suggest me any alternative to improve the performance and load time of the charts.

Thanks.