Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performances question #48

Open
paztis opened this issue Mar 31, 2017 · 7 comments
Open

Performances question #48

paztis opened this issue Mar 31, 2017 · 7 comments
Labels

Comments

@paztis
Copy link
Contributor

paztis commented Mar 31, 2017

Hi,
I recently read this article abouts the css selectors based on regular expressions: https://github.com/CSSLint/csslint/wiki/Disallow-selectors-that-look-like-regular-expressions

It seems all the selectors [class*="..."] you use in your code cost a lot for the browser, because it needs to check all existing DomElements in the page to check if its class verify or not the regExp (even if this DomElement doesn't works at all with flexgrid).

So I'm wondering about the performances of your grid compared to another one that doesn't use your suffix management, ie instead of use a class name "grid-spaceAround-center", use a more simple "grid spaceArround center" class.

The problem for me is that your code is more readable / usable than others that's why I'm hesitant.

To improve this potential problem, i've got 3 possible solution for you.

  • instead of managing your work in the "class" attribute, your can use another data-attribute like this:
<div flexGrid="grid-spaceAround">
  <col flexGrid="col-2"></col>
</div>

The advantage of this technique is only the elements that are concerned with the flexGrid management will be impacted with the CSS RegExp tests, because others will not have the data-attribute at all.
And in term of code in your sass file, it has a very small impact, because you can create a var
$gl-attributeName: class
and inside your mixins/code replace
[class*='#{$gl-gridName}']
with
[#{$gl-attributeName}*='#{$gl-gridName}']

And with this, basically everyone will have the same usage, and advanced user can change the attribute name if they want

  • Second possibility it to start all your css by a static class name:
    instead of [class*="#{$gl-gridName}-"] { .all nesting } for example use this
    .gridlex[class*="#{$gl-gridName}-"] {...}
    With this, the browser will check the existance of the class gridlex before any Regexp test I think.

  • Last possibility is to declare all existing possibilities as static classes:
    .grid-noGutter: {} .grid-noWrap: {} .grid-center: {} .grid-noGutter-noWrap: {} .grid-noGutter-center: {} grid-noGutter-noWrap-centerd: {}
    This can be done programmatically, but generates a very big css file (and perhaps not better in term of performances due to all the existing combinations.

I've no idea how to manage a benchmark for all these solutions because it's fully linked to the rendering / painting for the browser, so I cannot test all my ideas.

Are you interested by developping one of them, that can be backward compatible with olders versions ?
I can help you if you want.

Thanks

@devlint
Copy link
Owner

devlint commented Apr 4, 2017

Hello,
Thanks for your message!
I haven't test the performance for now between class and attribute selectors :)

It can be interesting to deal with it, but I'm not sure that the results will be significant...

I've readed this recently: http://ecss.io/appendix1.html and his conclusion is:

weating over the selectors used in modern browsers is futile; most selection methods are now so fast it's really not worth spending much time over

Nevertheless your first solution can be great to do the test because of not changing final code in css without adaptating the selector's value: with it, we can generate 2 css and 2 html files to performe the test!

If you have time for that, it can be great!! 😉

@paztis
Copy link
Contributor Author

paztis commented Apr 4, 2017

Hi
Job is done on the fork https://github.com/paztis/gridlex

  • doc/index.html file uses the class="..." mechanism
  • doc/indexAttribute.html uses the gridlex="..." mechanism

to test both you hust have to update the var gl-attributeName from "class" to "gridlex" in the .less or .sass files as you want.

I also test the perf quickly with chrome timeline with the doc/index page and it's quasi the same. Perhaps timeline is not representative for this.

Tell me if you want I PR my fork.

@paztis
Copy link
Contributor Author

paztis commented Apr 4, 2017

Ok I understand for the performances equality. It's because the all the index file used css classes are gridlex ones.
Test must be done on a real website with a lot of other stylings to see the real impact of removing flex management from classes.

@devlint
Copy link
Owner

devlint commented Apr 10, 2017

Hola @paztis !
Thank you for the fork. Yes please make the PR when you have time!

For the perf, sure that a file with a lot of different selectors must give us a more predicted result.
Not the time to test in "real" project :) but if anyone wants, we now have the possibility!

@paztis
Copy link
Contributor Author

paztis commented Apr 10, 2017

Hi
PR is done

@engelfrost
Copy link

Do you have any real world data to share yet? Performance on Safari for iOS and Chrome for Android would be especially interesting.

@adcortes
Copy link

adcortes commented Oct 4, 2018

Hi @David-Carty , i am facing the same performance issue, specially with IE (the latest one). It consumes a lot of 'styles calculation', but i mean... a lot :)
Have you checked this? Trying to find a solution, that is becauseof to much selectors like regular expressions like: *=, |=, ^=, $=, or ~=

I have my project with gridlex consuming 'styles calculate' of 62% and without it goes to '10%' (IE11).
If anyone has a solution or idea to it... Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants