I wonder if wrapping each tooltip (and the control it's labeling) in a <span> instead of using the `for=` attribute would be more performant.
If the former is significantly faster, it would be worth documenting. On Fri, Sep 4, 2015 at 8:46 PM, Aleks Totic <[email protected]> wrote: > Removing paper-tooltip import from your example cuts down your loading > time to 2.2s from 5.5s. I suspect that dom traversal is costly. > > Aleks > > On Friday, September 4, 2015 at 10:32:04 AM UTC-7, Aleem Mawani wrote: >> >> Its made more tough by not the fact that the number of elements inside of >> a webcomponent is unknown (until you try it and look for it). >> >> For example each one of those build cards has 264 elements in it. Looking >> at the markup I wrote that seems way out of whack which basically means >> that most of the elements are coming from children of paper-button, >> paper-icon, etc. Optimizing the components themselves seems to be one path >> forward. >> >> On Fri, Sep 4, 2015 at 10:23 AM Eric Bidelman <[email protected]> wrote: >> >>> None of them are using Polymer. I was just pointing out that modern apps >>> don't use 1000s of nodes. They load things responsibly, on-demand. This is >>> something you should be doing with or without Polymer/web components. >>> >>> FWIW, I agree that this is really hard. Custom elements are SO easy to >>> use that we need to make sure developers are able to use them without >>> worries like this. But it's also important to have these types of >>> conversations so people understand the tradeoffs, design patterns, etc. >>> Many people I talk to assume web components fix everything about web >>> development. There are still dark paths! >>> >>> On Fri, Sep 4, 2015 at 12:14 PM Eric Bidelman <[email protected]> wrote: >>> >>>> On Fri, Sep 4, 2015 at 11:56 AM Aleem Mawani <[email protected]> wrote: >>>> >>>>> Thanks for the info. Here's a screenshot of my real ui (ci build >>>>> server). >>>>> >>>>> [image: Screenshot 2015-09-04 09.39.25.png] >>>>> >>>>> On screen I'm only displaying 3 builds and that still results in 348 >>>>> polymer elements and roughly 900 regular Dom elements being created at >>>>> page >>>>> load. Thats about 120 polymer elements for each of those builds. The >>>>> performance is ok with just 3 builds. >>>>> >>>>> Ideally my ui shows 50 of these builds in a scrolling list. It seems >>>>> that even when using an iron list, it creates several extra items for >>>>> buffering and the render delay then becomes noticeable. >>>>> >>>> It'll help manage the list of items for you. Generating 3-10 items is >>>> better than the entire list :) >>>> >>>>> Can you explain a bit more what you meant by hiding list items behind >>>>> a dom-if? Isn't that the point of the iron-list, that it won't create many >>>>> list elements because it only creates enough to fill the viewport plus >>>>> some >>>>> buffer. How does the dom-if help? >>>>> >>>> I mean stuff like this: >>>> https://github.com/GoogleChrome/chromium-dashboard/blob/master/static/elements/chromedash-feature.html#L96-L214 >>>> <https://github.com/GoogleChrome/chromium-dashboard/blob/master/static/elements/chromedash-feature.html#L96> >>>> >>>> Until the user opens the feature card, all of that DOM isn't stamped. >>>> Some of it's custom elements, some <span> and <div>s. >>>> >>>>> Any ideas to reduce the rendering time in general? >>>>> >>>>> Summary: >>>>> >>>>> 1) How does the dom-if help? >>>>> >>>>> 2) Ideas for reducing the number of items created or lowering the >>>>> initial render time? >>>>> >>>>> 3) Any idea when that improvement to iron-icons will be released. We >>>>> use a lot of icons :) >>>>> >>>> It's out now! bower update and start using it. I see a lot of icons >>>> on your page so it'll definitely help your instance count go down. >>>> >>>>> >>>>> On Fri, Sep 4, 2015, 9:11 AM Aleks Totic <[email protected]> wrote: >>>>> >>>>>> 1000 elements budget is stingy for single-page apps. Do hidden >>>>>> elements count against the budget? >>>>>> >>>>>> Polymer's coding style encourages using lots of elements ("there is a >>>>>> component for that"). >>>>>> >>>>>> Number of elements component uses is unknown to the developer, until >>>>>> you inspect the dom. Usually, it is surprisingly high (10 elements for >>>>>> paper button). >>>>>> >>>>>> Aleks >>>>>> >>>>>> >>>>>> On Thursday, September 3, 2015 at 9:10:48 PM UTC-7, Eric Bidelman >>>>>> wrote: >>>>>> >>>>>>> I've been interested in this topic as well. >>>>>>> >>>>>>> *Your page *(http://jsbin.com/qunepiqeho/edit?html,js,output) >>>>>>> >>>>>>> I'm seeing *5591* custom elements being created on that jsbin (see >>>>>>> bookmarklet below). That's a lot! This is because >>>>>>> some elements create other sub custom elements in their shadow dom. >>>>>>> It's >>>>>>> important to keep in mind that custom elements do more than >>>>>>> plain-o-<div>. >>>>>>> They don't come without costs. You're creating shadow dom, composing >>>>>>> others >>>>>>> elements, running lifecycle callbacks, doing layout, style >>>>>>> recalc.... >>>>>>> >>>>>>> My first recommendation is to create fewer element instances. We're >>>>>>> actually told by the Blink engineers that 1000 elements is the >>>>>>> budget. That's not a lot, but 5k+ is way more than you ever should >>>>>>> create >>>>>>> on page load. >>>>>>> >>>>>>> On the Polymer side, we're looking at perf optimizations like the >>>>>>> one that recently landed in <iron-icon> >>>>>>> <https://github.com/PolymerElements/iron-icon/commit/2e06ec25a12b4bd39ef5aca8f9f79c5b492e6d60>. >>>>>>> Basically, >>>>>>> every instance of <iron-icon> was creating an <iron-meta> child. The new >>>>>>> version (not the one you're using) creates a single instance of >>>>>>> <iron-meta> >>>>>>> that's shared across all instances of <iron-meta>. That makes a real >>>>>>> difference if your page is using a ton of icons. >>>>>>> >>>>>>> * chromestatus.com <http://chromestatus.com> case study* >>>>>>> >>>>>>> Debugging chromestatus.com loading perf, I found there were 4000+ >>>>>>> elements being created on page load. Each of the 356 feature >>>>>>> elements in the list produced many sub elements. The solution was >>>>>>> to *create fewer instances up front*. The way I did that was to use >>>>>>> <iron-list> and selectively use <template is="dom-if"> to generate >>>>>>> DOM only when I needed it (e.g. when the user scrolls the page or opens >>>>>>> a >>>>>>> feature panel). It was silly to generate that much DOM on upfront. 90% >>>>>>> wasn't visible to the user. >>>>>>> >>>>>>> *Tools * >>>>>>> >>>>>>> Justin has been developing a Chrome Extension that will be useful >>>>>>> here. It will show per element metrics and answers questions like "What >>>>>>> is >>>>>>> the cost of putting this element on my page?" If you want something >>>>>>> now, I created a bookmarklet that may be helpful >>>>>>> <https://gist.github.com/ebidel/57c9e9379ec6b0bda16d>. It records >>>>>>> interesting numbers to the console. >>>>>>> >>>>>>> Lastly, we've also been talking to the DevTools team to see what >>>>>>> information we could expose to developers. If you have any ideas, please >>>>>>> let us know! >>>>>>> >>>>>>> Eric >>>>>>> >>>>>>> On Thu, Sep 3, 2015 at 2:27 PM <[email protected]> wrote: >>>>>>> >>>>>> I'm trying to determine if the rendering performance I'm seeing with >>>>>>>> a page with 1000's of custom elements is expected or not. >>>>>>>> >>>>>>>> Here's an example I put together: http://codepen.io/anon/pen/GpgmQV >>>>>>>> which has a few thousand custom elements. You'll notice that the render >>>>>>>> (i.e. after all the assets have downloaded) takes anywhere from 2-6 >>>>>>>> seconds >>>>>>>> (see chrome profiler output: http://i.imgur.com/F8nhHPA.png). It >>>>>>>> looks like most of this time is spent with polymer creating and adding >>>>>>>> the >>>>>>>> custom elements to the page. Is this expected? >>>>>>>> >>>>>>>> p.s. The obvious question is why would you have 1000's of elements >>>>>>>> on a page but lets ignore that for now. >>>>>>>> >>>>>>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >>>>>>>> --- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "Polymer" group. >>>>>>>> >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>> >>>>>>> >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/d/msgid/polymer-dev/8af8f0be-434d-4a8f-b8b7-5c60cf2559b8%40googlegroups.com >>>>>>>> <https://groups.google.com/d/msgid/polymer-dev/8af8f0be-434d-4a8f-b8b7-5c60cf2559b8%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Polymer" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/polymer-dev/CADBYpykxtX3X4CyPdexrbgbKRorr9mqeCKtNfVMUG_TzDZ6q5g%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/polymer-dev/CADBYpykxtX3X4CyPdexrbgbKRorr9mqeCKtNfVMUG_TzDZ6q5g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 > --- > You received this message because you are subscribed to the Google Groups > "Polymer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/polymer-dev/0b5c7314-cb92-4bec-a993-3466d2616a14%40googlegroups.com > <https://groups.google.com/d/msgid/polymer-dev/0b5c7314-cb92-4bec-a993-3466d2616a14%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CADSbU_y_MivjVdUZSQu_yBnSH1g3EY68UR0cfTokS_mwBK5oOg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
