css - LESS, Media Queries, and Performance -
i got started lesscss, , i've been having quite bit of success in regards how clean , readable css has become. however, don't think i'm using less fullest advantage.
i'm in process of coding first fully-responsive site using less, , i'm concerned performance , speed. one thing note don't stick "breakpoint" methodology - scale things , down until break, write css fix them; results in anywhere 20 - 100 media queries.
i'd start using less nest media queries inside elements, such example below:
.class-one { //styles here @media (max-width: 768px) { //styles width } } .class-two { //styles here @media (max-width: 768px) { //styles width } }
through initial testing, have found when reviewing compiled css output - methodology results in multiple (many!) instances of @media (max-width: ___px)
. have scoured internet, , haven't found explicitly explains performance implications of nesting/bubbling media queries.
update 1: realize more css information results in larger css file download - i'm not worried site load time sole metric. i'm more interested in browser's handling of memory , performance after dom ready.
update 2 & semi-solution: found this article discusses 4 main categories of css selectors , efficiencies. highly recommend read helped me sort out how best tackle over-media-query'd css.
so question this: after dom ready, having many media queries in compiled stylesheet affect load times & performance?
its impossible give totally accurate answer.
when asking performance typical answer profile , see get. fix slowest part first, repeat.
you can profile css selectors in chrome developer tools:
ultimately don't think media queries have anywhere near impact on performance compared complicated selector.
you can see more information writing efficient css here:
https://developers.google.com/speed/docs/best-practices/rendering
also regards file size , repeated css, gzip almost nullifies gzip algorithm works best repeated data.
Comments
Post a Comment