Condition to trigger Custom CSS aggregation?

Well, there’s no such issue in AO, so either it’s:

* a coincidence (with a specific string in the CSS triggering the exclusion mechanism)
* a conscious act by Jetpack to tell AO (through the API) not to aggregate the inline CSS
* a bug ??

So what would be interesting;
* can you replicate the behavior when adding the CSS in Appearance -> customize -> extra CSS?
* can you replicate the behavior when adding a long string of dummy CSS (stuff like abcde{fghi:klmnopqrstuvwxyz;}

frank

I don’t know why can see the comment I replied, here’s a nicer version: https://gist.github.com/sparanoid/cbec49bcbab1f424a4895bdff4a6c022

that’s weird indeed. now the “invalid, but smaller base64 string” indeed is not valid base64, what if you use a short but valid base64-string?

See https://gist.github.com/sparanoid/cbec49bcbab1f424a4895bdff4a6c022

Valid smaller embed webfont – still unaggregated.

I also tried a valid but lengthy embeded background image (larger than 64 KB which cannot be post here), also not aggregated.

OK, and did you test in Customizer -> extra CSS? same thing there or does this only happen in Jetpack Custom CSS?

There’s only one Additional CSS for me to add CSS. I believe it’s powered by Jetpack because it’s gone when the Jetpack is disabled.

Appearance -> Customize -> Additional CSS is part of WordPress core. Is that what you’re using?

Yeah, it’s this one.

well, the weird thing; I tried the exact same CSS and it gets aggregated nicely on my for me (see screenshot below of source of the AO file with the base64’ed font in it at the bottom). so I have no idea why it would not do so for you i’m afraid … :-/

So weird… I recorded a video to reproduce this issue: https://www.useloom.com/share/28be9e9bbfee458aa39c266a18885edf

More tests on different length with fake base64: https://www.useloom.com/share/d8c2662b3967444196c2b14c556bc30c

OK, so *something* (no idea what) is moving the custom CSS (which is normally inlined) to an external request with that ?custom-css=xyz123 call. AO does not optimimize that type of request because due to it’s dynamic nature it can’t be mapped to a CSS-file on the filesystem.

So the question becomes; what if moving that additional CSS out of the way (linked instead of inlined); a plugin? your theme?

I’m using a child theme of Twenty Twelve, with only some CSS tweaks.

After disabling AO totally, I got the answer:

If Additional CSS I use is smaller than n length (the exact length is not sure at the moment), WordPress just outputs the CSS inline itself:

`
<style type=”text/css” id=”wp-custom-css”>@font-face {
font-family: ‘Futura Std’;
src: url(data:application/font-woff2;charset=utf-8;base64,09GMgABAAAAAAUoAA4AAAAACjQAAATWAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGhYbIBwqBmAAPBEICoNsgxALFAABNgIkAxwEIAWKcwc0w) format(‘woff2’);
font-weight: bold;
font-style: italic;
}

:root {
–font-size: 15px;
–fontstack-heading: ‘futura-std’, var(–fontstack-prefix) var(–fontstack-sans-serif);
}

.entry-header .entry-title,
article.format-link .entry-content p:last-child {
font-style: italic;
line-height: 1.2;
letter-spacing: -.025em;
}

.searchform > div input[type=text] {
border-radius: 4px;
width: 100%;
}

#searchsubmit {
display: none;
}</style>
`

If it’s larger than n, it will be ?custom-css=xyz123.

So actually AO does not support aggregating Additional CSS?

Well I’m tired of WordPress editor, here’s the gist https://gist.github.com/sparanoid/cbec49bcbab1f424a4895bdff4a6c022#gistcomment-2780349

BTW what plugin are you using for the “additional CSS” feature that works with AO? Thanks