Hi AJ!
Thanks a lot for the suggestions! I will consider the page-based-configuration. I will actively use the plugin in optimization service and improve it further. Perhaps I will find a way to automate the Critical Path generation process or integrate a WYSIWYG generator within WordPress.
Can you perhaps provide an example of a website where page based configuration is required to achieve a higher PageSpeed score?
Regarding aggregation, the plugin is meant to be simple and light weight and to work next to other optimization plugins that for example handle aggregation. The only thing the plugin (optionally) does is optimize the delivery of CSS files by loading the files asynchronously via a modified version of LoadCSS that includes the CSS via Window.requestAnimationFrame().
When using the minification function of W3 Total Cache the plugin will optimize the delivery of the minified CSS files. It should work with any other aggregation plugin.
The plugin does not yet touch inline CSS blocks. I will consider the suggestion, however, perhaps it is better to handle it via an other plugin.
Regarding the usage of W3 Total Cache + Autoptimize + this plugin, can you please provide details about the problems you experienced?
[ Signature moderated ]
Hi Optimalisatie.nl,
Can you perhaps provide an example of a website where page based configuration is required to achieve a higher PageSpeed score?
Well, a higher PageSpeed score and optimal critical path rendering ride the line of being mutually exclusive. Setting aside the ubiquitous false-positives and bugs of the PageSpeed tool, what I’m specifically interested in is actual, real optimization of the critical rendering path when the critical CSS differs on different pages/posts.
For aesthetically redundant instances, a globally applied block of above-the-fold CSS can be applied and still render each page optimally (Smashing Magazine is a good example of this). However, in aesthetically ‘diverse’ instances, there is a need for more granular control (our website, as one example: note that different blocks of inline CSS are applied to every main page; then, a block applied globally to blog posts). 90%+ of the sites we work on require such granularity for optimal rendering/UX.
Regarding aggregation, the plugin is meant to be simple and light weight and to work next to other optimization plugins that for example handle aggregation. The only thing the plugin (optionally) does is optimize the delivery of CSS files by loading the files asynchronously via a modified version of LoadCSS that includes the CSS via Window.requestAnimationFrame().
When using the minification function of W3 Total Cache the plugin will optimize the delivery of the minified CSS files. It should work with any other aggregation plugin.
Ah, okay. So you’re saying that this plugin does/should be making use of the combined W3TC (or Autoptimize) CSS file, yes? If I recall correctly, the problem I was having is that it wasn’t, at least not when using Autoptimize for aggregation/concatenation: the combined (Autoptimized) CSS file was still appearing at the top of the HTML with your plugin including the globally applied, inlined CSS as well as each individual CSS file via Window.requestAnimationFrame() at the bottom. I didn’t experiment with W3TC as we generally don’t use it for minification since it too does not aggregate inline scripts or inline CSS output by plugins.
You may wish to construct your own instance and scenarios with these three plugins, though, to get your own eyes on the conflicts (potential or otherwise) as my experiment was very basic.
Best!
AJ