Yes and no. In some cases (3rd party content that you don't control), there's no way to know what script/iframe is going to do/use. For example, ads script that uses `document.write()` and kills perf.
Turning on certain policies can also help you be certain quality/standards are being met across your site. For example, the creative team forgets to optimize images and you end up shipping many more MBs of images than actually needed. The `image-compression` feature policy could be used as a gut check to make sure that never happens.
If your app uses a huge amount of code, then yes. But that's really the fault of the app developer. Not the library.
What developers often do is pull in a ton of components from the web components catalog and not realize that every component comes with a cost. It's no different than working with libraries. Know the tradeoffs.
https://ebidel.github.io/polymer-experiments/polymersummit/f... is another example that shows how to utilize the "upgrade" feature [1] of the custom elements API. IOW, the browser can render markup without JS ever running. Unfortunately, this is not something that Polymer leverages very much. It requires more work and is less friendly to new developers.
In using shadow DOM, one thing that's become clear is that it is a developer productivity tool (built in the browser).
With React, you have to use inline styles (https://facebook.github.io/react/tips/inline-styles.html) or a build tool to modularize/prefix CSS selectors (e.g. CSS Modules). Inline styles can muck with specificity and tons of inline styles can actually force the browser to do more context switching than necessary (HTML parser <-> CSS parser). Mind you, the latter is unlikely to actually be a perf issue in a real app.
In shadow dom, you just write CSS. Write simple selectors in a `<style>` or a stylesheet, the browser automagically scopes the selectors to the component, no tools required. Shadow roots also prevent outer styles from cross the boundary and leaking in. That one is particularly tricky without help from the browser.
As for perf...
In theory, the browser can optimize work (style recalcs, layout, paint) in shadow trees b/c the DOM is local.
However, generally there's a lot of low hanging fruit still to look at. Browser engines have been optimized for global css so those paths are super fast right now. https://bugs.chromium.org/p/chromium/issues/detail?id=314303 is a good example of the work that can be done (now fixed in Blink):
> Being inside a ShadowRoot disables lots of optimizations we have for the normal document. Authors also use ShadowRoots differently than the main document (ex. hundreds of tiny identical sheets in each Shadow instead of one really big one in the document) so we should consider those use cases and how we can handle them better.
> We should be able to get much faster. This bug tracks the many efforts to make recalcStyle faster in ShadowRoot (and by extension Web Components)
Another thing Blink does is optimize `<style>`s so they're shared/cached across instances of a component (as long as their `.textContent` is the same). That was a pretty big speed up in Blink.
Polymer itself is 47KB. If you add the web component polyfills (16KB), that's 63KB minified and gzipped. I tend not to consider the polyfills because they're not Polymer and are a stop-gap that goes away over time.
Perspective is important :) Putting 1000 material design inputs on a page isn't something a sane web app would do. The same is true for a native app.
Re. "bloat" of components. I think it's important to remember everything something like paper-input is doing for _you_. As a developer, I no longer have to think about: validation, animations, a11y, keyboard, knowing all the MD spec configurations, labels, underlines, colors, fonts, typography, margins, composability, x-browser interop,... Sure, if you were implementing your own input, you could cut corners and/or leave out what you didn't need. However, if you were creating a highly reusable, highly configurable element, you'd be implementing the same amount of "bloat" yourself.
Turning on certain policies can also help you be certain quality/standards are being met across your site. For example, the creative team forgets to optimize images and you end up shipping many more MBs of images than actually needed. The `image-compression` feature policy could be used as a gut check to make sure that never happens.