简体   繁体   中英

Why is the self-contained htmlwidget so much bigger than the htmlwidgets.org example page?

Comparing the size of the html widgets example page with the size of a self-contained html widget:

  • when inspecting the example page, I'm getting a total of 717KB for the entire page

htmlwidgets页面加载perf

  • when generating a self-contained html widget, I'm getting a ~3MB page that contains only the widget

htmlwidgets保存perf

# Code to generate the html widget
library(ggplot2)
library(plotly)
library(htmlwidgets)
p <- ggplot(data = diamonds, aes(x = cut, fill = clarity)) +
  geom_bar(position = "dodge")
p <- ggplotly(p)
htmlwidgets::saveWidget(p, "path/to/my/widget.html", selfcontained = TRUE)

I'm trying to serve htmlwidgets to a web app over an HTTP API, so the size of these widgets is a concern. Why is the self-contained htmlwidget so much bigger than the htmlwidgets.org example page? Can I do something to change that?

Note: I'm considering generating a non-self-contained html page, splitting the page to get the data , and serving the *.min.js files but the aggregated js files still add up to a few MB.

The numbers you are seeing when inspecting are the lower because the files are compressed using gzip compression, which is the deflated once the data arrives.

检查文件gzip

I've run your example and the biggest offender for data size seems to be plotly-latest.min.js , which on disk occupies ~2.8 MB of storage.

To validate this, you can download the version from the example link you provided and it will occupy ~1.7 MB of storage. This is not the same, however the versions I'm seeing locally generated and R on on the example webpage are many version apart (Example: plotly.js v1.16.3 , My R: v1.39.2 ), so it's likely attributed to plotly developing quite a lot in the what seems to be 2 year gap between versions (files have copyright date ranges, maximums are 2016 and 2018).

As far as trying to reduce the burden of file size, my best guess is that your HTTP API you are going to use can offer the same gzip encoding. There is no other way to transfer less data unless you can trim un-needed files as a post-process, determining those would be an exploratory process.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM