That 600ms difference between load times for the style guide is not something small. In fact, the difference in load times for the merchant portal was also 400ms. Given the importance of page load times for SEO (especially on mobile), this is not a marginal result. For most sites that I've dealt with, consolidating assets makes the biggest impact. But once you've done that, if you can squeeze another 500ms just from your CSS, you'll do it.
For larger sites with tons of visitors, page load speed has a tangible impact on revenues. Being able to trim off another 100ms can result in millions of extra sales every month.
Perhaps we should focus on a CSS optimizer that rewrites CSS rules in the mixin style? Then it makes the whole thing an exercise in code style.
I think his issue may be more that it's hard to be certain of this difference because it's relatively small and there are many other factors at play. He also doesn't say how many times he ran this test, but assuming he does sufficient test runs then I'd agree a 300-600ms difference is worth it.
@lucisferre, you're 100% correct here. I certainly don't ignore 300-600ms differences but I only look for them after I've exhausted other, perhaps larger, gains.
As for how many times the test was run, it was randomized but but somewhere between ~60-100 times.
This is pretty interesting because the extends certainly result in DRYer CSS, which I think most of us would have figured to perform better.
I know I've gotten myself into some hairy situations in the past by mistakenly extending things that were already extended, and unintended consequences are a concern even now.
I've got a hefty redesign due to launch in the near future, and I'm doing a lot of performance tuning. I've got ~300 includes (mostly media queries) and ~30 extends. This seems like an easy enough change to make right now for a quick, but small win.
> This is pretty interesting because the extends certainly result in DRYer CSS, which I think most of us would have figured to perform better.
I'm not so sure. Matching selectors to the DOM is a time consuming process. So more selectors, more time spent. I think parsing the rules is fast in comparison.
I've heard some horror stories of mistakenly nested extends resulting in CSS files that were in the megabyte+ range at the local Sass meetup. I've shyed away from extends mostly from a sanity perspective as I've found mixins more sane.
For larger sites with tons of visitors, page load speed has a tangible impact on revenues. Being able to trim off another 100ms can result in millions of extra sales every month.
Perhaps we should focus on a CSS optimizer that rewrites CSS rules in the mixin style? Then it makes the whole thing an exercise in code style.