Run tests in a real browser environment

[kitten]

Somehow we should consider running theses benchmarks in an actual browser (headless chrome)?

This is important, because CSS injection is one (or more) orders of magnitude slower and thus more relevant to our performance, than anything else. @threepointone has done some benchmarks around it which show that we lag far more behind than what it looks like. [Insert all the blah blah about how this doesn't matter a lot anyway here]

So it'd be nice to benchmark this consistently and automatically in here as well, so that we can test and benchmark Glen's batching patch, and maybe even speedy stylesheets easily. And even more important: consistently.

[jacobp100]

To go further than this, we need a relatively complex page to be rendered to measure the impact of adding new styles (and likely triggering reflows)

[geelen]

This is sorta where I was going with this: https://github.com/geelen/sc-perf-testing/blob/master/src/sc-inline/App.js

I took the homepage of tachyons.io, inlined all the CSS that each tag used, then converted them to SCs. There's a few other examples there in that project.

These are all concerned with initial bootup time, and I'm a little concerned that the numbers are a bit skewed simply by having that many distinct components on a page. Still, it's been a useful stress-test.

If you could figure out something that should happen on that page that might require styles to be injected, it might be worth adding.

[quantizor]

@philpl How about just JSDOM?

[kitten]

@probablyup that won’t be enough. CSS injection has proven to be the most significant factor (by up to an order of magnitude) for performance.

It’s a very specific way in which it has an effect on performance, that starts to show in styled-components after a thousand (?) classes being added.