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

    (@optimizingmatters)

    well, you did the heavey lifting, but you’re welcome 🙂

    feel free to leave a review of the plugin and support here! 🙂

    Thread Starter courageous999

    (@courageous999)

    Done!

    I also found a very nifty plugin that complements Autoptimize called Asset Cleanup. Helped me remove countless more useless resources loading on the Homepage!!!

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    good to know 🙂

    have a nice weekend,
    frank

    Thread Starter courageous999

    (@courageous999)

    Actually Frank, I need your opinion on 1 more thing as I’m getting desperate to solve this problem. You see the whole enabling of inline CSS/JS was to try and solve the Google Mobile Friendly conundrum.

    In other words, if you look at the following image (zoom in to read):
    https://www.dropbox.com/s/l5zegrv2ae03b97/Google%20Other%20Error.jpg?dl=0

    You’ll see what resources Google was able to load when it tried accessing the Homepage from a mobile useragent. As you can see, it was able to only load 7/25 of the resources. Every time I run this test it comes back with a different number and different randomly loaded resource files. All I do know, is that Google doesn’t like to load too many requests; thus why I was trying to reduce that with inline CSS/JS and installing Autoptimize in the first place.

    Doing all the above was not enough to reduce the too many requests problem, so I downloaded Asset Cleanup, another plugin that allows you to select and remove specific resources on a page by page basis. Using that plugin, I removed every single resource that I found to be unnecessary on the Homepage until there was no more useless resources that can be removed.

    After doing all of the above, I once again tested my site’s homepage and it came back with pretty much the same result on Google’s end (see image above).

    Saying all that, the only thing that makes the test come back as “Mobile-Friendly” is when Google is able to load the Autoptimize’s CSS file. Even then, all these other requests in the image would still come back as “Other Error” and couldn’t be loaded.

    Any thoughts on this?

    Anyone else complain about this? Is it a global problem?
    Or
    Am I missing something simple that can reduce the current list of requests? Especially, the butt-load of image requests that keep showing up in there I don’t understand what can be done about those. I have already compressed, optimized, and cropped every image to the best fit. In case you’re wondering, I also momentarily tried activating Pickapixel in Autoptimize’s settings, and then did the Google test again, but the result was the same.

    I am pulling my hair out at this point.

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    The only thing I can think of is that Google is requesting an older AO’ed CSS-file which has since been removed from cache. The solution to that is to not delete AO cache too often I guess ..

    Thread Starter courageous999

    (@courageous999)

    Unfortunately, that’s not it. I just checked a live version of the mobile page and it’s pulling the same CSS/JS filenames as Google.

    Desktop page had a different CSS/JS filenames by the way

    Thanks anyway. Guess I’ll keep fiddling around with this game Google is playing

    Thread Starter courageous999

    (@courageous999)

    Hi again Frank,

    I’m afraid our efforts may not have been sufficient in stopping the cache from growing too fast.

    I left the cache on Friday at 67%, came back on Monday to find it at 100% with 500MB and 600 files. Upon looking at the files, I saw an equivalent number of CSS/JS new files that seemed to be responsible for the growth in cache size.

    Saying that, I was not looking forward to hunting for another needle in a haystack so I just disabled “Also aggregate inline JS” and cleared the cache yesterday in hopes of the problem just going away on its own.

    Unfortunately, problems with cache seem to never go away on their own. Since I still have “Also aggregate inline CSS” enabled, it seems the cache is still growing too fast with the current statistics at:
    21%, 106.22MB, and 168 files.

    21% in one day? That’s a bit too fast, is it not?

    Is there any way to add some kind of debug line through a hook (or directly in the plugin temporarily), but this time to catch any form of auto-changing CSS/JS inline blocks on any and all pages? Because I have not been able to find anything else changing in the CSS/JS when loading random pages on the site.

    I’ve also checked our traffic inspector for the site, and the pages that were visited during the times that many of the new CSS/JS autoptimize files were created, did not seem to create new files when visited, so nothing abnormal there. Checked it from Mobile as well, seemed fine. About 300MB of cache came over the weekend wherein no one was modifying the site in any way, so something fishy was happening there.

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    ok, some questions;

    * so “also aggregate inline JS” is off, how about “also aggregate inline CSS”?
    * what CSS optimization exclusions do you have (specifically, are wp-content/cache and wp-content/uploads still there)?
    * is “Minify excluded CSS and JS files?” on or off?
    * are you using plugin organizer or similar resulting in different plugins being stopped/ allowed on different parts of the site?

    Thread Starter courageous999

    (@courageous999)

    1. “Also aggregate inline CSS” is on.
    2. Yes, current excluded CSS: “wp-content/cache/, wp-content/uploads/, admin-bar.min.css, dashicons.min.css, .td_uid”. The last one you and I added due to randomly hashed CSS selectors that were being generated by Google Ads on the Homepage on each page load.
    3. ON
    4. I’m using Asset CleanUp on the Homepage of the site, and have disabled a few needless Plugin’s CSS/JS files using it.

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    ok, can you try turning Also aggregate inline CSS and/ or Minify excluded CSS and JS files? off?

    Thread Starter courageous999

    (@courageous999)

    I already know it works fine without “Also aggregate inline CSS”, but I want inline CSS aggregated since it seems to reduce the number of requests per page load drastically.

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    I want inline CSS aggregated since it seems to reduce the number of requests per page load drastically.

    that is pretty bizarre, as inline CSS by definition is inline and thus not subject to extra files being loaded. the only alternative is trying to find out what inline CSS you need to exclude for the cache not to get busted?

    Thread Starter courageous999

    (@courageous999)

    Right, that’s why I asked this:

    Is there any way to add some kind of debug line through a hook (or directly in the plugin temporarily), but this time to catch any form of auto-changing CSS/JS inline blocks on any and all pages? Because I have not been able to find anything else changing in the CSS/JS when loading random pages on the site.

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    no, there is not; AO just aggregates the CSS and then calculates the hash of the aggregated code and checks if for that hash a minified file is in cache. you’ll have to compare autoptimized CSS-files of similar pages I’m afraid.

    Thread Starter courageous999

    (@courageous999)

    But if I load a page multiple times and the Autoptimize CSS file is the same, then what am I comparing that to? There’s no other page similar to the Homepage for instance?

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