Support » Plugin: Autoptimize » Also aggregate inline CSS causing infinitely growing cache size

  • Resolved courageous999

    (@courageous999)


    Hi,

    Up until yesterday we did not have either “Also aggregate inline CSS” nor “Also aggregate inline JS” checked because we had problems with overly fast growing cache when doing so.

    But lately, we have been having problems with too many requests when visiting a page on the site that Google didn’t like.
    And so, in an effort to resolve this, running some tests proved that there’s render blocking JS and aggregating the inline JS/CSS would fix most of the problems.

    Having said that, I went ahead and checked the “Also aggregate inline CSS” and right away the cache size (which would normally stay for months at less than 30%) grew from 20% to 30%. Having noticed that, I decided to not check the “Also aggregate inline JS” until I can confirm that the cache size will stabilize.

    Next thing you know, I came back today in the morning to a cache size of 1.3GB and an email of a too large cache warning. Within about an hour or 2 of noticing that, I checked again and the cache size was 1.48GB so it was still growing.

    I went into the Autoptimize cache directory, and the JS folder seemed normal with a size of 32MB whereas the CSS folder had this:
    https://www.dropbox.com/s/86nn05ctjridq7p/Screenshot%202019-07-18%2014.24.39.png?dl=0
    Upon noticing how recent the last few CSS files were created, I decided to do a normal refresh of the website’s homepage to see if that somehow generated one of those files. Unfortunately, what I suspected was true; for some reason a new CSS file is being generated every time the site is refreshed.

    Any ideas what we can do besides disabling “Also aggregate inline CSS”?

    Having a large cache size is one thing, which we can deal with to solve our “too many requests” Google problem, but having an infinitely growing large cache (about 1GB or more per day) is a bit too much.

    The page I need help with: [log in to see the link]

Viewing 15 replies - 46 through 60 (of 79 total)
  • Thread Starter courageous999

    (@courageous999)

    Silly me forgot to log the server variable, I just added that in.

    Entertain me this though, I just logged everything before minify and everything after minify using your hooks and then refreshed the page where the script lies:
    Before minify shows that very same script going in just fine without the '</p> tags, and after minify shows that exact script missing where it should be.

    That above seems to agree with the page source for that page showing the very same script missing when viewed.

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    but given you have “also aggregate inline JS” on, it is bound to be missing, no?

    Thread Starter courageous999

    (@courageous999)

    That actually makes sense and explains why it wasn’t showing up in the page’s source.

    Saying that I disabled “Also aggregate inline JS” expecting to finally be able to see the script on the page’s source and be able to debug through trial and error how to get rid of the ‘</p> tags from it…

    But guess what?

    ‘</p> tags are not on the script in the page’s source. Color me annoyed at this point.

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    Color me annoyed at this point.

    that makes 2 of us, afraid I have no idea whatsover what is happening there :-/

    Thread Starter courageous999

    (@courageous999)

    but given you have “also aggregate inline JS” on, it is bound to be missing, no?

    Going back to this though, this doesn’t make sense actually. The script shouldn’t be in the same place sure, but that doesn’t mean it shouldn’t anymore be in the minified output?

    Before minify shows that very same script going in just fine without the ‘</p> tags, and after minify shows that exact script missing where it should be.

    Because when I tried looking for that script, it was there in the before_minify but was nowhere to be found when I searched for keywords of it in the after_minify output of the page.

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    after_minify only has the HTML, not the aggregated & optimized JS 🙂

    Thread Starter courageous999

    (@courageous999)

    Yeah I realized that a while after I thought about it again.

    Coming back now I find there has been 1 more error and this time I got the Server variable/useragent. Guess what? It is a damn Google bot. Does this mean anything to you?

    Can I use this new information to replicate the problem better?

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    Can I use this new information to replicate the problem better?

    yes; use a “user agent switcher” addon in your browser, set the useragent to the one you just caught and make the same request to see what Googlebot sees?

    Thread Starter courageous999

    (@courageous999)

    That’s a good one. However, I didn’t need to use that. I should have just checked the mobile view *facepalm*

    That exact same error not only gets logged again when I do that, but it even breaks the page damn it

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    ok and what inline JS do you when on “mobile” see when “also aggregate inline JS” is off?

    Thread Starter courageous999

    (@courageous999)

    With or without inline JS checked I see the same errors and </p> tags EVERYWHERE.

    I’m surprised JSMIN only complained of a couple.

    Why is WordPress only doing this on Mobile is one question.

    This inline script was working fine before so I don’t understand why it’s broken now. Unless WordPress only added it’s stupid wpautop’ing recently, I don’t see how this is only a problem now

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    my gut feeling: this is not WordPress core, but a plugin (or your theme?) doing this (triggering wpautop one way or another). you might have to do the plugin-toggle-dance (or briefly switch themes) to find the culprit here ..

    Thread Starter courageous999

    (@courageous999)

    Actually, I just remembered something that has to do with wpautop’s.

    Long long ago, I added the following piece of code to functions.php in an attempt to solve a different problem with my editors:

    remove_filter( 'the_content', 'wpautop' );
    remove_filter( 'the_excerpt', 'wpautop' );

    At the time, I did not think about potential consequences to everything else when doing this. Do you think there is any consequences of doing this? Cause I mean this would apply to the whole site wouldn’t it?

    You see long after I made that addition in functions.php, our theme developers god bless them, updated the Mobile Plugin for the theme. We decided to activate the mobile plugin on our site and we liked the results. However, ever since doing so, whatever changes you write in the functions.php no longer affected the mobile versions of any page on the site. And those filters I posted up there are currently still residing on the functions.php file, which means they have no effect on the mobile version of the site. Makes sense?

    And this would explain why only mobile is affected by the </p> tags everywhere. I could just apply the above 2 filters in a plugin instead, and that would affect the whole site like it used to a few months back. However, I ask first, do you think this has any unexpected consequences that I should look out for?

    EDIT:
    I have added this already into a plugin and that solved every single error on that page, including the autoptimize complaints. I ask again though, do you think there’s any consequences I’m not thinking about?

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    don’t see consequences and good to hear this is fixed, but I don’t see why the <p>’s got added inside JS in the first place to be honest.

    Thread Starter courageous999

    (@courageous999)

    Yeah no idea to be honest but at least it’s fixed. Thanks for all your help on all of this

Viewing 15 replies - 46 through 60 (of 79 total)
  • The topic ‘Also aggregate inline CSS causing infinitely growing cache size’ is closed to new replies.