Also aggregate inline CSS causing infinitely growing cache size

  • Resolved courageous999

    (@courageous999)


    5 years, 8 months ago

    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 - 1 through 15 (of 79 total)
  • Plugin Author Optimizing Matters

    (@optimizingmatters)

    you’ll have to find what inline CSS is breaking AO’s cache and exclude that from aggregation by adding a keyword of that block of inline CSS to the comma-separated CSS optimization exclusion list @courageous999

    hope this helps,
    frank

    Thread Starter courageous999

    (@courageous999)

    How can I find that out? By disabling plugins one at a time and checking if refreshing the Homepage will still create new CSS files?

    Assuming that I find that out, how can I restore normal cache size without clearing important CSS cache files as well? Cause Google seems to struggle to find the CSS files when the Autoptimize cache is cleared.

    EDIT:
    I just re-read your reply and realized you are saying that I can block a specific inline-block?? How do I find out which inline block is causing this? And if I do, how would I exclude it? And would excluding that specific inline block also exclude it if it shows up on other pages?

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    easiest way is by comparing the autoptimized CSS source between 2 pages, very likely you’ll have one block of CSS being different. excluding is can by done by finding a keyword in there which is not in other inline CSS and adding that to the comma-separated CSS optimization exclusion list.

    Thread Starter courageous999

    (@courageous999)

    So I have to find a page which is not causing the CSS to be re-created, then compare the autoptimize CSS file of that page with the Homepage? Which other page do you mean? Like any other page on the site? Wouldn’t the CSS be different on different pages?

    As for excluding by keyword, I saw your FAQ example of “funky_data” as the keyword to put in. I imagine I can put this after the comma without the quotes? And what if I put “<script>funky_data=” instead, will that still work?

    Thanks

    • This reply was modified 5 years, 8 months ago by courageous999.
    Plugin Author Optimizing Matters

    (@optimizingmatters)

    had a quick look, comparing the source of the main aggregated CSS-file between 2 loads of the homepage and there is custom CSS for your Google Ads which sees a class selector changing every time;

    
<style>
/* custom css */
.td_uid_1_5d314c35e6c96_rand.td-a-rec-img {
				    text-align: left;
				}
				.td_uid_1_5d314c35e6c96_rand.td-a-rec-img img {
                    margin: 0 auto 0 0;
                }
</style>

    so try adding .td_uid to the comma-separated CSS optimization exclusion list and see what gives? ??

    Thread Starter courageous999

    (@courageous999)

    Oooooooh! 2 loads of the homepage!!! Genius!

    That makes sense! Thanks for that!

    So I added the keyword into the exclusion list as you suggested, and then accidentally cleared the cache when saving ?? which I didn’t want to do.

    Moving on, I went into the CSS directory to do the same test again (i.e. reload the homepage and look for new generated CSS autoptimize files). No more new files are being generated when re-visiting or refreshing the Homepage. However, this is what the Autoptimize CSS directory currently looks like:
    https://www.dropbox.com/s/jn1zvwdedr6m3cx/Screenshot%202019-07-19%2012.54.52.png?dl=0

    Considering I just cleared the entire cache. Is it normal for Autoptimize to have more than 1 “autoptimize_%RANDOM_HASH%” CSS file in there? Or does this mean there’s more changing CSS selectors somewhere on the site (probably not on the Homepage) that I have to hunt for?

    Also, in the 10 mins that I spent writing this reply, a couple more “autoptimize_%RANDOM_HASH%” files have come in. I’m not even looking at the “autoptimize_snippet_%RANDOM_HASH%” files cause I don’t know what those are, but more of those have come in as well.

    EDIT:
    Upon Checking WP Cerber, a plugin that monitors traffic, looking at traffic at the last 2 times that Autoptimize generated new CSS files shows the following 2 URLS were visited, I don’t know if just coincidence or not because there was nothing visited for some of the other files:
    https://familyhealthadvocacy.com/?wordfence_lh=1&hid=AFBD103FBBC322C82A55A9FAD62AA5CD&r=0.786671285195326
    https://familyhealthadvocacy.com/?wordfence_lh=1&hid=0B5C821FC84178552FEBBB9CA2876C4E&r=0.5965496545868533

    Note: Autoptimize is currently sitting at 5% with 21.18MB and 88 files.

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    the snippet files are kind of cache within the cache, allowing AO to create new non-snippet cached files (a lot) faster. based on the info provided my gut feeling tells me all is OK really. give it a couple of days and see what happens? ??

    in the mean time; have a nice weekend! ??
    frank

    Thread Starter courageous999

    (@courageous999)

    UPDATE:
    Turns out WP Cerber wasn’t logging crawlers so I just enabled that, and then 3 more CSS files were just generated. First at 1:52:13PM, another at 1:52:22PM, and another at 1:52:25PM. Upon checking the Live Traffic inspector, the only 2 URLS visited at 1:52PM were the following:
    /?wordfence_lh=1&hid=01DEB4905D6846BFBD441315E5FCEA7D&r=0.29594579794330667
    and by a Google bot: /heal-cancer-king-mushrooms/?mode=list

    When I tried visiting both in incognito however, no new CSS files were generated.

    While writing this 2 more files were generated at 2:01:14PM and 2:01:16PM, looking at the live traffic inspector again, I saw 8 URLS that were visited at 2:01PM, however, all lead to 404 Not Found pages. This was 1 of them for instance:
    /apple-touch-icon-120×120.png
    Since they all lead to a 404 Page Not Found, I tried visiting just 1 of them and no new CSS files were created.

    I’m a bit at a loss as to what’s causing the new CSS files to generate or why, is this normal Autoptimize behavior? If it is, is it fine to let cache grow this way even if it surpasses 100%? I’m thinking besides disk space, there really is no harm of a large normal cache.

    Note: Autoptimize is currently sitting at 6% with 26.83MB and 93 files.

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    I’m a bit at a loss as to what’s causing the new CSS files to generate or why, is this normal Autoptimize behavior?

    new cache files are created if cache does not have a minified version of the aggregated unminified file yet.

    If it is, is it fine to let cache grow this way even if it surpasses 100%? I’m thinking besides disk space, there really is no harm of a large normal cache.

    have a look at this blog post of mine for reasons why you do not want your cache size to “explode”

    Note: Autoptimize is currently sitting at 6% with 26.83MB and 93 files.

    perfectly normal, let’s reconvene on Monday and review status? ??

    Thread Starter courageous999

    (@courageous999)

    Thanks for the quick reply. I’ll come back and check this after the weekend and see where we are at. I do want to enable Inline JS caching as well which I imagine will be a whole new story, but I will hold off until we can confirm that the CSS is no longer an issue.

    You have yourself a great weekend as well Frank!

    Thread Starter courageous999

    (@courageous999)

    Hi again Frank,

    I hope you had a great weekend.

    Checking in today, I found Autoptimize sitting at 24% with 121.38MB and 170 files. Is this normal behavior?

    If so, is it safe to go ahead and activate “Also aggregate inline JS” now? Ironically, this is the one with the warning about growing the cache size quickly. Is this guaranteed to happen if I enable it? Any tips on what to look out for once I do?

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    Checking in today, I found Autoptimize sitting at 24% with 121.38MB and 170 files. Is this normal behavior?

    it is ??

    If so, is it safe to go ahead and activate “Also aggregate inline JS” now?

    you’ll probably face similar issues which will require similar solutions ??

    Thread Starter courageous999

    (@courageous999)

    I just enabled “Also aggregate inline JS” and the result wasn’t as bad as I thought, there’s 1 tiny issue however. I did NOT clear the cache after I made this change, just wanted to mention this in case it has something to do with this problem.

    Could you please have a look at the homepage again, every time I load up the homepage there’s a console error that now shows up and would otherwise not show up without “Also aggregate inline JS” being checked.

    “tdBlock is not defined” shows up 5 times, when I click on the line causing it, it shows a script that starts off like this <script>var block_td_uid_3_5d35e3cdb05c9 = new tdBlock();. As you can guess, this is also a random variable name with a hash that changes after “block_td_uid_3_”. I tried your trick of adding “block_td_uid” into the “Exclude scripts from Autoptimize” section, but that didn’t seem to stop that error from triggering. Any thoughts?

    It’s worth noting that there’s other variables that also randomly change that start with “block_td_uid_4”, “block_td_uid_5”, etc. So I think I’ll keep excluding “block_td_uid” from the Inline aggregation if it’s working.

    • This reply was modified 5 years, 8 months ago by courageous999.
    Plugin Author Optimizing Matters

    (@optimizingmatters)

    probably wp-content/themes/Newspaper/js/tagdiv_theme.min.js

    Thread Starter courageous999

    (@courageous999)

    I have tried putting the following: https://www.dropbox.com/s/26fey8w1mapo6mi/Screenshot%202019-07-22%2013.01.00.png?dl=0
    and saving WITHOUT clearing the cache. Unfortunately, neither of them stopped the error from appearing.

    I can also confirm that 10 new Autoptimize JS files have been created since activating the inline aggregation about 50 mins ago. However, they’re definitely NOT being created from reloading the Homepage.

    • This reply was modified 5 years, 8 months ago by courageous999.
Viewing 15 replies - 1 through 15 (of 79 total)
  • The topic ‘Also aggregate inline CSS causing infinitely growing cache size’ is closed to new replies.