A single instance of paper-date-picker (v2.0.0) creates creates 556 DOM nodes, which blows more than a third of the DOM budget!
I have paper-date-picker in a card element that I show a list of. This causes my DOM size to balloon into tens of thousands of nodes, which is unusably slow.
Anyhow, it looks like the bulk of it is coming from paper-calendar. It's stamping three months at once, with several levels of dom-repeat. Reducing the number of nodes to stamp a month and/or not stamping invisible months would have a large impact on performance. I think the goal should be to get this under 100 nodes.
Lighthouse recommends keeping a web app under total 1500 nodes: https://developers.google.com/web/tools/lighthouse/audits/dom-size
A single instance of
paper-date-picker(v2.0.0) creates creates 556 DOM nodes, which blows more than a third of the DOM budget!I have
paper-date-pickerin a card element that I show a list of. This causes my DOM size to balloon into tens of thousands of nodes, which is unusably slow.It's so slow to stamp that I wonder whether somewhere under the hood the iterations are causing layout thrashing: https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing#avoid_layout_thrashing
Anyhow, it looks like the bulk of it is coming from
paper-calendar. It's stamping three months at once, with several levels ofdom-repeat. Reducing the number of nodes to stamp a month and/or not stamping invisible months would have a large impact on performance. I think the goal should be to get this under 100 nodes.