css optimisation - 48,139 unused selectors in 35 stylesheets (dust me selectors output)

i just ran 'dust me selectors' addin in firefox and spidered my whole 1.8.8 site.

as you can see from the heading. there was a surprisingly high amount of CSS.

21,909 used selectors
48,138 unused selectors

in 35 stylesheets.

looking at the list of stylesheets, i see:

ie6
ie7 

and a number of cached css files, each with progressively higher numbers of selector.. which i presume are old cached css files that have increased as i added more elements to them?

e.g. http://www.mysite.com/cache/css/default/elgg.1351852670.css 

so firstly, why are there so many of these numbered files? there are at least 20 of them..
aren't these meant to be being cleared when i press 'flush cache' in the admin area?

if i assume that most of these can be cleared somehow, leaving only one version of each file, the total selectors will drop to roughly 1350 unused and 850 used selectors. the unused ones include page elements that the spider app hasn't reached, such as system config pages/ messaging /friend picker.

does anyone have a smarter way of reducing the size of that unused list without going through each entry 1 by 1 and at the same time ensuring i don't remove any that are needed? (most likely i'll just leave most of them and only remove ones i have added that i know aren't needed any more - but maybe someone has some tips?)

thanks 

  • These "numbered" files only exist in your browser's cache; they are harmless and are expunged as new items are added to the cache.

    Feel free to report CSS that is truly unused anywhere in the framework, but my bet is much is coming from CSS for 3rd party libs/components like jQuery UI. Spidering can't catch all the selectors you'll possibly need and removing these from Elgg could break other people's sites.

  • hmm, no its not the browser cache as i hardly ever use firefox.. and i just cleared the cache and reran the spider and am seeing the same results.

  • BTW, you're right that the "flush caches" action does not technically "flush" any client/proxy caches. HTTP doesn't let you do that.

  • Are you saying some pages are referencing elgg.<some number>.css and some others a different number? That should not be happening. Load the page directly and view source.

  • ah yes.. the CSS number is different on each pageload.. if i change pages or reload the same page, i see different numbers each time.. the 2 caches are checked in the advanced admin page

  • The cache is being regenerated on every request. Is your dataroot directory writable? That would be one thing to check.

  • i do not find it so convincing to go simply by the browser addon's stats..
    which reflects only that particular site, siituation, browser..

    of course.. jQiery IU's CSS *might be largely unused
    and the only way to streamline that will be
    to analyze the UI's actual selectors versus
    references to determine what could be superfluous

    i might extend my CSS parser to scan the elgg core + plugins
    views to see what stats come out..

    CSS_SCAN1
    ::Merged0.PHP::

    ░  ###   ░SEL?ATTR░            ░SELECTOR NAME░                                        ░                        ░
    ░  :::   ░  :     ░            ░    ATTR NAME░                                        ░VALUE                    ░
    ░ ````                             
    ░   12    SEL     ░             .EXAMPLE1 > PTR                                
     ````       .                      CHL
        13      A     ░                 COLOR                                              #000
    ░   15    SEL     ░             .EXAMPLE2 .EXAMPLE2                            
     ````       .                      MUL
        16      A     ░                 COLOR                                              #111
    ░   20    SEL     ░             .elgg-button                                   
        21      A     ░                 font-size                                          14px
        22      A     ░                 font-weight                                        bold
    ...
    ░ 4312    SEL     ░             .elgg-output img                               
     ````       .                      MUL
      4313      A     ░                 max-width                                          100%

    ░ TOTALS ░

    ░ SELE░ 825
    ░ ATTR░ 1,664
    ░ SUBS░ 97
    ░ CHLD░ 112
    ░ MULT░ 258
    ░ VALU░ 1,664
    ░ LENG░ 11,779

    OPTIMIZED:
    ░ UNIQ░ 380
    ░ LENG░ 3,481

    ::EOF::

  • @ura, I just found this bug, which may be related. Check your site for /cache/ URLs that may not map to existing simplecached views.

  • i'm not exactly sure what you are asking.. 

    look for entries in the CSS listing that point to views that haven't been cached?

  • Build a list of all CSS/JS URLs that start with /cache/. Make sure all those filenames (stripped of the number) map to real views that are registered with simplecache. That's only one possibility of what's happening on your end.

Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.