Hi Ceciliaaltieri;
That is normal; Autoptimize honours the mediatype of the CSS it aggregates. In your case, your site has some CSS with media=”all” and some with “screen, projection” and Autoptimize keeps those separate to avoid things breaking.
Hope this clarifies,
Greetings from the North of the country (Lokeren),
frank
Hey Frank!
Thanks for your reply.
I’m currently working on reducing my server response time for my site http://www.therapy.brussels
Once I figured out your plugin it made a great improvement! Yay!
Plus other things I had to work on myself.
But I still have a couple of questions regarding this…
I did marked this option: “If your scripts break because of a JS-error, you might want to try this.” in the settings, as my home page was showing the menu in a weird way after optimizing the site, the only thing that changed is that now you can still see the menu in a weird way… but for less time (you can check it out by visiting the site to see what I mean, as it won’t be possible for me to make a screenshot as it lasts 1 second…)
I think this happened after including the scrips jquery.js and aggregating inline JS.
Do you have any tips on how to improve this (error)?
On the other hand when I started researching about how to reduce server response time I came across a tool that tells you the requests of the page ( https://varvy.com/tools/requests/ ) and only if this makes sense… it is telling me that it has 14 requests… :O and some of the files that it’s showing me belong to Autoptimize, apart from the photos that I still have to figure out how to sort them out…
I hope you can guide me through a bit at least to fix the menu showing properly once you access the page. Or you may even know a different way to reduce the server response time.
Please let me know if you need the full details about how I set your plugin. And also if you prefer I can open a different tread for each topic for the sake of the forum.
Thank you very much for your time and for sharing your plugin!
Greetings from Limburg 😉
well, I would really stick to the default of excluding js/jquery/jquery.js and not aggregating inline JS. although theoretically not excluding anything is better, there are some important technical consequences (disadvantages), so …
regarding “reduce server response time”; you need a page caching plugin for that. I see you use WP Super Cache (which is a good one), but I see this warning in your HTML;
<!– Dynamic page generated in 2.501 seconds. –>
<!– Page not cached by WP Super Cache. Could not get mutex lock. –>
which implies your page caching isn’t working right now. either look into this (there’s *some* info in WPSC’s FAQ) or consider switching page cache plugin (to e.g. comet cache, simple cache or hyper cache).
groetjes,
frank
HI Frank!
Thank you so much for the tip! I changed to comet cache and now my speed went from 2.501 seconds to 0.23 seconds! That was a genious move!
I realised that what broke my “menu” was using this: “inline and Defer CSS?” plus adding a code provided by https://jonassebastianohlsson.com/criticalpathcssgenerator/
I reversed it and now it’s working fine.
Knowing that, would you still recommend not to exclude js/jquery/jquery.js and not aggregating inline JS.?
As that got rid of my render-blocking JavaScript and CSS the first time I did it. I wonder how bad those ‘disadvantages’ you mentioned really are. Or maybe there is adifferent way of fixing that?
Thank you sooooooooooo much again for your support! 😉
Cecilia.
main disadvantage is that your JS cache could grow _very_ fast when inline JS is aggregated, so would have to keep an eye on that.
good you’re happy with Comet, do use the link on AO’s “optimize more” tab if you would want to buy the PRO version, that way I get a klein zakcentje 😉
frank
Hey Frank,
Thanks for the advice.
I do have a question though, I noticed that you set a button on the top bar to delete the cache.
So the question is: if I aggregate inline JS and I exclude js/jquery/jquery.js my cache might grow fast, but can I manually clean it by using the button (delete cache)provided by the plugin? or apart from that this will lead me into more trouble? I’m asking this as I saw in a post of yours “Autoptimize cache size: the canary in the coal mine”, even though this talks about “autodeleting”, so I would like to know if this is still valid or if I should be ok by just manually deleting the cache every now and then…
And the last question is, will this be taken care in a better way by using Comet Pro?
I’ll see to your klein zakcentje as soon as I get this little one to produce 😉 I won’t forget!
Cheers,
Cecilia.
manually (or automatically) deleting the cache indeed only fixes the most visible problem, but the fact remains that a big cache indicates a low cache hit ratio, which means you will have more users waiting for (js) optimization to be done and that users requesting multiple pages will probably also have to download a new autoptimized JS-file for each request.
but you could go for “aggregate inline JS” and only evactuate the coalmine (disable inline aggregation) if the canary dies? 😉
comet pro does not affect above problem, but does offer some nice extra’s (which you might or might not need/ want), cfr. the comparison here.
frank
Thanks for that Frank!
So basically I’ll know the canary is dead or about to die when cache gets fat?
I’m sorry about my IT illiteracy 🙁
when that happens I just disable inline aggregation and after a while would I be able to aggregate inline JS again? or that means this is irreversible? (I mean the canary’s death)
I think that this might be my last issue, at least according to Google’s Page Speed: “Your page has 2 blocking CSS resources. This causes a delay in rendering your page.”
http://therapy.brussels/wp-content/cache/autoptimize/css/autoptimize_7b56f8aa297e89291643d292a18f8100.css
http://therapy.brussels/wp-content/cache/autoptimize/css/autoptimize_2170ea179e6ffea492076c16299235ea.css
This is what I did (after watching your video about Eliminate Render Blocking CSS)
I copied the code from one of them on (text edit) and I used https://jonassebastianohlsson.com/criticalpathcssgenerator/ to get a critical path, then I pasted it into the box
and whoohoo!!!!!!!!!! I’m at a 100%
I hope I didn’t break anything :/ site looks alright though…
I did the test on the other site you recommended (which Ican’t find the link anymore)and soon enough I will be adding CDN in order to leave search engines happy (as recommended on the page) so far it seems to be the only thing I’m lacking… even though I’m not sure it is necessary.
Thanks again for the great support and the endless patience!
groetjes,
Cecilia
PS: when I’m done with all this I’ll catch up with my Dutch classes 😛
ah, forgot to answer this part;
So basically I’ll know the canary is dead or about to die when cache gets fat?
when that happens I just disable inline aggregation and after a while would I be able to aggregate inline JS again? or that means this is irreversible? (I mean the canary’s death)
when your cache gets big, you should disable inline JS aggregation (optionally excluding js/jquery/jquery.js) and “save changes & empty cache” and you’ll be good to go with the canary living a happy life in retirement 😉
