Docs/Website request: Performance statistics

[kevinSuttle]

It would be valuable to have Polymer's performance stats documented. Technical decision makers look for this kind of thing. I've asked the React folks to do this as well. facebook/react#4974

[tjsavage]

We've discussed this a bunch within the team here as well, and have come to a very similar conclusion that @jimfb describes in his response to the similar issue on React.

That is: it's really hard to tell the whole story with benchmarks, other web frameworks & libraries like Polymer are so different that it's inevitably comparing apples and oranges, and the truly valuable metric is "will it be easy to build a fast website with X?"

You're absolutely right though, technical decision makers look for this kind of thing. They're correctly looking to make the right decision when picking a dependency for their application, to protect their investment and make sure they're not spending weeks/months/years on writing code that - if it turns out they're not using the fast thing - may have to be thrown away.

The fact that deciding on a web framework can be such a huge, scary, risky up-front investment is really a bug in the platform. We're trying to fix this bug with Web Components & Polymer.

So that's a long way of saying - we probably won't invest time in comparing Polymer with other frameworks in terms of an arbitrary notion of performance. That said, there are certainly other valuable, specific things we can highlight to help decision makers - I’d love to have the discussion of what we can do to communicate a more nuanced view of what web tools do well and what they can improve on. Curious to hear your thoughts here.

[kevinSuttle]

Thanks for the thorough response, @tjsavage. In retrospect, I could have spent more time clarifying. I'm not interested in Polymer's performance as it compares to other frameworks. I'm interested in how the performance of Polymer affects the end UX for my product. It's also a dependency discussion. Dependencies often get overlooked in terms of performance, but the fact is you inherit the optimization of the framework you choose.

[ebidel]

Dependencies

The Polymer core library has no dependencies. Of course, one could make the argument that the polyfills are dependencies, but those are a short-term requirement and will go away over time. By itself, Polymer is very lean b/c it uses the native browser APIs.

Elements are a separate conversation. They're built using Polymer but are not Polymer-proper. This is one reason we've moved them into the catalog as branded collections. They're also versioned separately. As such, the elements (and their deps) should be discussed as separately.

*"affects the end UX for my product" *

is specific to your product :) So the question becomes, what types of things would you like to do in your product? We can help highlight the features, elements, and fast paths where Polymer can help and make you more productive.

Real app numbers

If you want hard numbers of a real-world Polymer 1.0-based app, see my PolyMail app results.

TL;DR

• Chrome desktop - first paint is 589ms and loads in 1s.
• Chrome with 3G connection - 1.66s first paint. Repeat view is even better thanks to Service Worker (first paint: 589 ms, Speed index: 2627).

Keep in mind, these are numbers from a single app and first paint is but one metric. Once you're in the app, it's also important to keep user interactions, animations, and UI, fast. Polymer has reusable elements and features for those things.

If you want more, I did a session on Polymer performance patterns at the Polymer summit last month. There's a lot of good stuff in there.

[ebidel]

This issue was moved to Polymer/old-docs-site#1376