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?
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 … :-/
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?
BTW what plugin are you using for the “additional CSS” feature that works with AO? Thanks
