Script loading

AO only optimizes if the script is actually in the HTML source, so a plugin that stops plugins from adding scripts would indeed be beneficial. i know something like that exists, but I don’t remember the name I’m afraid …

frank

Oh, i just thought of dequeing myself in functions.php…

there’s a potential disadvantage though; in theory this could mean that a lot of requests (well, responses) will have a different set of JS or CSS. the result of that is is that the autoptimized JS or CSS for those would be different each and every time, meaning a cached file cannot be reused. In reality the impact will not be big, but still something to consider?

frank

I guess trial and error ??

my favorite approach! ??

have fun!
frank

Minqueue?

The disadvantage of dequeuing styles using functions.php is that some won’t get dequeued at all. I guess the same problem arises with Minqueue also.

This is because several plugins (and themes) don’t queue it in the modern WordPress way, i.e, they don’t use wp_enqueue_style and wp_enqueue_script

I think Frank you can add a “blacklist” in addition to “exclude” where the user adds file1.css, file2.css and file3.js, file4.js, file5.js in boxes.

So exclude is for not optimizing but allowing them to load, whereas blacklist is for stopping.

On a related note — we load a different set of CSS and JS for logged in vs. logged out users. Logged out users basically just see a marketing page while logged in users see more of a ‘dashboard.’ We handle this through a simple logged-in check in our functions.php to enqueue the right styles and scripts (3 total for each).

In our tests everything seems to work fine with Autoptimize and W3 Total Cache (minifying turned off), with the exception of Safari browsers which tend to hang on to the logged out CSS after logging in for some reason.

I am wondering what’s going on in the background. My read on the above is that Autoptimize will create two cached css and js files and load the right one based on the logic mentioned above. Is that right? Is there a better way to handle it?

Now that I think about it I think the Safari issue might have more to do with W3 Total Cache than Autoptimize, but thought I would bring it up in case there are any insights. Perhaps the best approach is to exclude all of our theme enqueues and simply use Autoptimize to roll up all the CSS and JS from plugins.

My read on the above is that Autoptimize will create two cached css and js files and load the right one based on the logic mentioned above. Is that right? Is there a better way to handle it?

That right. If asking if there is a better way, you seem to see disadvantages in the approach?

Hi Frank… sorry for the delay — I just realized that all my WordPress emails are going to spam :/

I now see my question was not clear as written. What I should have asked is: “Is there a better way for ME to handle the logged in vs. logged out css situation?”

But I’ll answer my own question. If Autoptimize displays the correct CSS based on the logic I set up in my enqueues, then no, there really isn’t a better way to handle it. It’s working just as expected.

As for the error I am seeing with Safari browsers, I did find some old bug report about it here.