Wilson Page wrote a really great article for Smashing Magazine digging into a real world website and all the cool modern tools and techniques he and his team used to build it.
For layout, they initially chose flexbox, but…
As the app began to grow, we found performance was getting worse and worse.
We spent a good few hours in Chrome Developers Tools’ timeline and found the culprit: Shock, horror! — it was our new best friend, flexbox. The timeline showed that some layouts were taking close to 100 milliseconds; reworking our layouts without flexbox reduced this to 10 milliseconds!
There are some before/after screenshots of the dev tools timeline in the article. Worrysome, no?
I was talking to Tim Kadlec about it. Tim said he reached out to the team to see if they had created a reduced test case or had any more data to share. Unfortunately they did not.
Maybe we can find that data. I built a little random flexbox layout generator thingy.
Sliding that range slider around regenerates the random flexbox layout. The further to the right, the more. So far, I haven’t been able to find anything terribly taxing. However, my little demo there isn’t exactly “real world”. Perhaps images inside there are problematic. Perhaps using the flexbox properties to change source order are what is taxing. Perhaps old flexbox is the culprit. Perhaps there is nothing to be worried about at all.
If you have any ideas on how to replicate some bad performance around flexbox, feel free to fork my generator thingy and add/change what is needed to make it happen.
The best way I know of to actually measure the performance is Chrome Dev Tools > Timeline. Then hit the “Record” button, slide the slider around, and stop. Then look around the timeline for long paint times. Like this:
The purple there is layout, which is fast in this case (so far).
If we can gather some solid data, I’ll update this post with those closest thing to an answer as we can to the title of this blog post.
UPDATE: And here we go!