First off, thank you for this fantastic plugin. I have tried several other ones that do the same thing and yours worked best.
One feature I would like to request is the ability to asynchronously load less important css without blocking rendering.
I would like to select the few most important css files (bootstrap and my theme’s css) to be combined and loaded in <head> and then combine all the other css files and loaded asynchronously using the loadCSS polyfill.
Here is a plugin that implements async css loading:
There are plenty of plugins that focus on completely eliminating render blocking resources, but I think that is unnecessary and too complicated, but making all the plugin css non render blocking is easy and has a significant benefit.
Thanks for your consideration, Kim
Hi, thanks for the feature requests.
I have actually looked into this extensively, but for an option to defer all css with a text box where you could insert the critical path css… however, I put it aside for now for a few reasons.
The LoadCSS is “not always” async, there’s a notable bug with pagespeed insights that I have experienced first hand (so I quit using it, as there was no benefit):
Obviously there are other async css techniques (this is already in place for the font awesome library if you enable the setting for font awesome optimization), so I might be able to extend it to other css files.
What can be done in the near future however, is to use the newer
<link rel="preload" as="stylesheet">but this currently only works on Google Chrome and Opera (same engine) http://caniuse.com/#feat=link-rel-preload
I suggest “for now”, that you select the option to “inline all css”, especially if it’s small and your page uses gzip.
Thanks for the quick reply.
Frankly, I think chasing pagespeed insights scores is a little silly. I am much more interested in real life performance and easy maintainability than some scores– which is why I like your plugin.
After reading the github comments, I think the issue is simply a bug in pagespeed insights that wrongly shows stylesheets as blocking even though in real life they were not.
This means there is a substantial real life performance benefit, even if google insights doesn’t show it (but who cares…).
I have considered using one of the plugins that allow you to enter the critical css and require you to maintain it, but I think it is too much hassle and is too error prone for me and probably for most WP users.
But you don’t have to go all the way and remove ALL render blocking css to experience a substantial benefit.
A lot of sites have primary theme stylesheets that actually style the site and then several more for plugins, lightboxes and so on that are not required to display most of the page.
A feature that allows you to load those important css in a blocking manner and the unimportant ones async would be very valuable and take your plugin to the next level.
You could simply provide a text box where people enter the identifiers of the important CSS. Those get minified into a file that is load in normal, blocking manner and the rest of the css is minified and loaded using loadCSS().
Right now I have setup your plugin to only minify and combine JS files and I am using the “Async CSS” plugin to only load my theme’s css and bootstrap in a blocking manner.
The performance increase was substantial!
I appreciate the suggestion to inline all CSS, but even though that would give me a better pagespeed score, it would actually decrease real life performance for users and I don’t think that makes sense.
I just looked into your preload suggestion and that might be the perfect solution for me and perhaps the majority of your users.
It is already natively supported in Chrome and Chrome for Android, which is apparently 50% of global usage.
And for all other browsers there is a polyfill:
My suggestion would be to allow users to select their most important CSS files that should be combined, minified and loaded in a blocking manner and then all the unimportant ones that should be combined, minified and loaded using the preload feature.
That would give users awesome performance and easy maintainability.
I understand your point and I’ve been taking a look into this for months, however is not that simple.
That pagespeed insights bug, it’s actually not a bug. It’s by design.
What happens there is that if you LoadCSS all of your CSS, it is considered render-blocking (pagespeed update in February 2017) because of the FOUC effect. In other words, google considers that async CSS is needed for the page to render above the fold (took me a while to find out this) so it is smart enough to say it’s render blocking even if you load it async.
That aside, you (and me) might not care much about pagespeed insights… but developers and their clients care. Furthermore, even though this is not a ranking factor, people see it as if it is, so it’s suddenly more relevant to have a better score for clients rather than better speed.
Clients trust what they see and understand, so they look at pagespeed insights and see a score of 100 and say it’s perfect. If you try to argue with them, less techie people out there that google is wrong… they are just going to look down on you, even if you know better.
Furthermore, clients cannot tell the difference between an improvement of 100 ms and an improvement of 200 ms, it’s just easier to use one of those tools to “measure” speed, and that is actually one of the objectives of this plugin.
One is to make the site faster (that’s why there are options) but the other is that you can tweak it so it gives a better score too, because most people care about it.
For example, my site scores 100 on pagespeed but I am aware it’s not the fastest possible (although the difference is negligible). However, I’m also a freelancer that does speed optimization and when clients check my site score, they say something like “WOW, this guy must know what he is doing”… (which happens to be true) but this is regardless of anything else other than the score.
As for the preload option, as I said it’s on my roadmap and it will eventually be added. It just happens that I am supper busy recently, so I’m taking it easy for now.
Makes sense. I totally understand that.
Thanks for taking the time to reply!
Just letting you know that Critical Path CSS as well as Async CSS is available on the latest version, however bare in mind that “async” means that the order of css loading is not kept, so it should only be used if you only have one css file on the page per media type.
If you have 2 css files, loading async means that the second file can actually be loaded earlier than the first, thus the first css file would overwrite your css code from the second file. It all depends on the browser and the size of each css file, plus it’s not linear which css file will load first.
If you understand or have only one css file, then go ahead and test it.
Sorry, where are available the Critical Path CSS as well as Async CSS?
I only see the CSS option:
– Preserve the order of CSS files [ If selected, you will have better CSS compatibility but possibly more CSS files]
Are both this? I was expecting to be able to select the few most important css files (bootstrap and my theme’s css) to be combined and loaded in <head> and then combine all the other css files and loaded asynchronously using the loadCSS polyfill.
- This reply was modified 4 years, 9 months ago by aberniz.
You may already know this plugin:
Does it work OK for CSS async with Fast Velocity Minify?
@aberniz this has been removed again after a few versions, as it lead to complaints by people that didn’t know how to use it, or understand what it is.
Deferring CSS only works if you have one single css file, so if you have 2 or more, the order in which they load is not guaranteed, thus breaking your styles.
The “safe” way to remove render blocking, is to select the inline css option, especially if your css is not too big.
If you were expecting to choose exactly which files to combine and defer, that means you know exactly what you’re doing and which files affect which parts of design.
Furthermore, it should also means you know how to extract the critical path css or do not bother with the FOUC effect, caused when you defer CSS.
That being the case, I would suggest either programmatically dequeue the files you want to merge on your theme functions.php, enqueue the merged file you want… or use another specific plugin for that, such as https://wordpress.org/plugins/above-the-fold-optimization/ which uses LoadCSS.
On FVM, I have been testing deferring the CSS with LoadCSS as well as critical path / uncss generation with nodejs and gulp… so eventually, this will either be added to FVM or discarded.
The current version, doesn’t have support for async css or critical path.
- The topic ‘Async CSS’ is closed to new replies.