In short, no! Asset CleanUp deals with file optimizations and does not create and load render-blocking stylesheets in the front-end view as this is against the purpose of the plugin.
However, there are things that one needs to understand if CSS optimization is used in Asset CleanUp (either Lite or Pro). Sometimes, Google PageSpeed Insights reports render-blocking CSS that needs to be solved for the page speed score to go up and the CSS files loaded are stored in
/wp-content/cache/asset-cleanup/. One such request can be to a file such as //yourdomainhere.com/wp-content/cache/asset-cleanup/css/item/my-custom-style-v08ecee3985715c46a2ee6d08d13ee22657c66ec4.css. Although it’s reported as render-blocking by various page speed tools, the most popular one being Google PageSpeed Insights, this file is an optimized version of a CSS file that was already render-blocking. Because it had to be altered and stored in a caching directory for faster rendering, the location of the file is not the same.
For instance, the original location of the file could be /wp-content/themes/my-active-theme/my-custom-style.css. This is some custom styling that you applied to your website. This CSS file is not optimized and you enabled CSS minification in Asset CleanUp. The plugin will minify the CSS and store the final optimized version of the file here /wp-content/cache/asset-cleanup/css/item/my-custom-style-v08ecee3985715c46a2ee6d08d13ee22657c66ec4.css (which was in the same state before using Asset CleanUp: render-blocking).
What actually happens with optimized Asset CleanUp files (this includes, minified, combined, or altered in any way) is that they remain loaded in the same state that they were before, meaning that if the CSS was render-blocking, then even if the file is optimized, it’s still render-blocking, but now it’s not loading from its original location, but from the caching directory which is managed by Asset CleanUp. Although the result in terms of page speed and user experience is the same, it was the /wp-content/cache/asset-cleanup/ part within the URL that could make one believe that the file was intentionally loaded by Asset CleanUp as render-blocking which is false. Whether it’s stored in /wp-content/themes/my-active-theme/ or /wp-content/cache/asset-cleanup/css/item/, the CSS file will load in the same way by the browser 😉
Here are a few other scenarios to make things even cleared:
Scanario #1: Your targeted page (e.g. the homepage, most common one) loads 10 render-blocking CSS stylesheets from various plugins and the themes, having a total of 200 KB. You activate a feature such as minify CSS. The plugin will scan the files, minify them, and load them from the caching directory. The total size of the files is now 120 KB (after modification) which is great as 80KB were stripped from the total page size. However, although the CSS files are smaller now, they are still render-blocking as they were used to be before when they were loading from their original location. Even if they now load from the caching directory (just a different disk location), they have the same render-blocking state.
Scenario #2: Your targeted page has 10 CSS files that are required to be loaded (e.g. in this instance, all of them are useful and none should be unloaded) and you activated the combine CSS feature. You’re expecting to have the number of HTTP requests reduced from 10 to 1 or 2 (the plugin will calculate that accordingly, but for sure there should be fewer files loaded). The page is now loading 2 HTTP requests from the caching directory (minus eight). Although it’s an improvement, the final CSS combined stylesheets are still render-blocking (same state as they were before the merge).
One way to test how Google PageSpeed Insights score was before using Asset CleanUp was to append /?wpacu_no_load to the targeted page and it would make it load as if Asset CleanUp is fully deactivated (for debugging purposes). It would show the reference to the CSS file from /wp-content/themes/my-active-theme/ and alert it as being render-blocking.