AJ @ WpFASTER.org

Does Performance –> Minify –> General –> Minify error notification: –> Disabled (from the drop down menu) fix it?

Best,
AJ

So long as you have activated only the JetPack features you actually use, there really shouldn’t be any performance issues so long as the site is adhering to optimization best practices (which W3TC greatly assists with so long as it is correctly — Read: Optimally — configured).

Would you mind posting the URL in question? I (and others) can then get a better understanding of where your site stands relative to performance best practices.

At any rate, you should — ideally — be using a CDN not just to optimize the delivery of your images, but a CDN for ALL of your site’s static resources/files: CloudFlare has a free option, and will greatly increase the delivery speed of a myriad of file types:
css
js
jpg
jpeg
gif
ico
png
bmp
pict
csv
doc
pdf
pls
ppt
tif
tiff
eps
ejs
swf
midi
mid
ttf
eot
woff
otf
svg
svgz
webp
docx
xlsx
xls
pptx
ps
class
jar

Best,
AJ

Hi Deborah,

To cache images: Performance –> Browser Cache –> Media & Other Files (last section under Browser Cache).

In addition, you should try Photon to serve your images.

Best,
AJ

One more, lol

You could also try skipping .js minification altogether and re-enabling Rocket Loader. Aside from asyncing them, Rocket Loader also combines (‘bags’) all of your scripts; which, in almost all conceivable instances, is more important than minification anyway.

The only (potential) downside to this being that, iirc, only Firefox and Chrome recognize CloudFlare’s script attribute. I.e Rocket Loader doesn’t work in Safari, IE, Et. al., etc.

Walking away now…

Awesome, glad you found a solution.

Rocket Loader… love-hate it.

Two other things you might try:
1.) Minify everything you’re going to minify with CloudFlare instead of W3TC, re-validate your cache, then re-test the load time to see which schema is ultimately faster for your site and set up. (if it works and is faster, re-enable Rocket Loader and see if anything breaks. Might not.)
2.) Try Autoptimize for .js: Autoptimize is often able to concatenate scripts that W3TC can’t. If that works for you, it is probable that you will be able to then re-enable Rocket Loader without issue.

EDIT: You could also try Autoptimize for all minification/combination, allowing W3TC to handle everything but.

Hi Josh,

You’ve got a lot going on there, so without at the very least a URL/source to examine no one is really going to be able to help all that much. Some things to consider, however, are:

1.) Does disabling Rocket Loader solve all of the issues you’re having?
2.) Are you minifying .js with W3TC only?
3.) If you’ve combined your .js via W3TC, have you attempted troubleshooting for dependency issues?
4.) What CloudFlare caching level are you using?
5.) Have you tried this plugin to exclude ClickDesk .js files from Rocket Loader?

Again, without at least a URL/source to examine, this is guesswork.

Best,
AJ

@forest Skills Member,

CSS:
Via W3TC, manually combine CSS files, excluding any and all WooCommerce CSS files (These can almost never be minified/combined without some in-depth engineering).

As implied, first try “Combine only”. If nothing ‘breaks’ tick both “Preserved comment removal” and “Line break removal”; for @import handling use “Process”). Have a look at the site. If something is broken, revert back to “Combine only”.

JavaScript:
Use Autoptimize for your JavaScript. If something ‘breaks’, try following the instructions in the Autoptimize dashboard. If still broken after trouble shooting (shouldn’t be, though) you can try something like CloudFlare’s Rocket Loader.

Notes:
Make sure JavaScript minification is not enabled in W3TC and CSS minification is not enabled in Autoptimize.

Take your pick as to which of these plugins you want to minify HTML with (if you want to minify it, that is), also making sure that only one of these plugins is handling HTML minification.

^ Doing these things will likely solve the problem.

Best,
AJ

Here here.

It wouldn’t even take a plugin, actually, to provide the most elegant solution. There is no good reason why CloudFlare does not offer the capacity to ignore certain scripts from right within the CloudFlare dashboard.

None. Zip. Ziltch. Zero. Nada.

But yes, a plugin would be better than the nothing currently provided.

Hi jp2112,

How CloudFlare ought to be doing things (while a reasonable discussion to have in itself) is ultimately irrelevant to whether or not this plugin fulfilled or now fulfills its function – and again misses the point.

If the plugin was tested to see if it actually excluded files from being processed by RL, and if you were able to somehow verify that it was excluding files, we are then left with only two logical possibilities given that the plugin could not have been excluding any files due to the misplaced attribute:
1.) the plugin was not tested at all; or,
2.) whatever verification methodology was employed with the test was also fundamentally flawed and didn’t actually verify anything.

If, however, one defines “works” as a plugin intended to exclude certain files from being processed by RL, that adds an attribute without actually excluding the file to which the attribute was added, then yes: The plugin “works”. Mission accomplished. This is, of course, setting aside all of the other issues with the plugin, some of which are arguably core.

The only other issue with the plugin was the way it was handling filenames being input into the textbox on the plugin settings page.

Not so. The plugin also was not (still is not? Dunno.) accepting exact or combined file names (see discussion above).

Further, I just attempted the update and, similar to Uzair’s fix, it either broke or initiated a conflict such that some WP Admin functionality immediately broke. This is the only plugin amongst 23 on this site and set up that breaks or conflicts with this site and set up. I understand that there may or may not be anything that can be done about that, but it is relevant to the discussion that has evolved.

I agree, this plugin does have the potential to be very useful. Generally, negative reviews are given to plugins that either do not, or as is the case with this one, cannot do what they are supposed to do, and have further problems radiating from that critical starting point. I am glad you’re willing to make the plugin better and look forward to watching its refinement.

Cordially,
AJ

Hi all,

@uzair,

Not sure I follow. CloudFlare/RL still processes .js files combined via W3TC. Generally speaking, as is the case with our particular set up, a single (or a couple) combined and Rocket Loader ‘bagged’ .js files constitutes a significantly faster load-time scenario than does implementing non-combined, CL auto minify and bagging from there. Also, we (as is the case with the majority of sites) have some .js that cannot be minified without site breakage, but can be combined. In the end, we’re not combining the .js for the caching benefits as those headers are stripped-away once the files are bagged via RL anyway, but for the benefits of combining those files into one. At any rate, there should be no technically insurmountable challenge to getting an attribute applied to any script that is RL enabled, bagged, and served asynchronously, be that a file combined via W3TC or no. Thanks again for all your efforts.

@jp2112,

Let me start by saying that CloudFlare support is notoriously bad. Perhaps even worse than their poor documentation. And it is poor. I too hope that they meet the more-than-fair challenge you’ve set. I will go ahead and add another: that CloudFlare works to improve their support in any and all ways online support can be improved, up to and including improved education of support staff as to how CloudFlare’s products and features work.

Your choice to look at reviews and make changes accordingly is obviously your own. That said, and as already elaborated upon, there is nothing currently – or essentially – functional about the plugin. Not just that it misplaces the load order of the attribute, which is, of course, a big deal in itself. It is broken out of the box and required someone with the patience of Uzair to doctor it up such that it worked at least in his environment. Were there a single jenky thing about it or perhaps a couple relatively insignificant bugs that were not integral to the plugin’s reason-for-being, it would indeed be a matter of first requesting support.

The comment in my review about whether or not the plugin was tested prior to release is also fair for all of the reasons both express and implied in this support thread, and the review itself. The crux of course being how you were able to test and verify that the plugin was fulfilling its function of excluding Rocket Loader from processing certain scripts, all while the plugin was misplacing the “false” attribute.

In short, there was not proverbial ‘jumping the gun’ as it was not I who needed support, but the plugin itself. Ergo: straight to review. This is my reasoning and I feel you deserve to hear it as I think your plugin will ultimately prove to save a lot of headaches that CloudFlare shows no interest in saving themselves.

Best,
AJ

Hi Uzair,

When the cfrli.php edits are made and the plugin activated, some functions in WP Admin are immediately broken in our setup prior to configuring the plugin in any way. Or, and if you like, some or another conflict is immediately created upon post-fix plugin activation such that some WP Admin functions are broken. Said either way, the net result is the same: Broken WP Admin functions. This likely has something to do with our caching schema – APC database cache in particular. Regarding that, I’m not going to undergo some time consuming investigation and/or re-work all (or any) of that finely-tuned schema to suit a plugin, the only function of which is to add an attribute to a script tag. I mentioned the broken WP Admin functionality not as a jab at you or your committed efforts, but because if the fix (or the resultant conflict of having edited the plugin) breaks our set up it will break others. The bottom line is what it is: the author of the plugin needs to go back to the drawing board, both to fix the plugin’s fundamental flaws, and, to insure that it ultimately ends up working in a reasonable range of environments, up to and including the complex or necessarily complicated ones in which it should technically work.

The combined file name examples I provided are indeed combined (and cached) files created by W3TC, and what you write about wp_register_script or wp_enqueue_script wordpress functions are certainly correct. That said, the plugin in its original state, or with the edited cfrli.php file, is still not recognizing certain other combined file names that it should; or – and more importantly and particularly – exact file names, which is what I meant to provide examples of, but in my rush, did not:
backstretch-2.0.3.min.js
jplayer-2.3.0.min.js
jquery-ui-1.8.22.min.js
So on and so forth, etc.

I am glad you have found a work-around such that you can use this plugin, even though you have – in essence – created an entirely new one. You should not, however, have had to go through the trouble, which would be the first, best, and most salient point I’m trying to express.

Best,
AJ

Unfortunately, the above fix (somehow) broke some WP Admin functionality.

Also, the plugin still is not accepting exact file names or combined file names.

E.g:
default.include-body.8d4ce0.js
default.include-footer.64e61e.js

I am rating this plugin 1 star. I will change the rating should the author make a working plugin.

Ah, okay gothca. Very nice.

I should note that what I wrote about the “true” attribute above turns out to be incorrect. Both the “true” as well as the “false” attributes are to be placed before the ‘src’.

I am including the correction as there is another CF/RL plugin that deals with RL from the other direction; in “Manual” as opposed to “Automatic” mode – which also places the attribute incorrectly (i.e. after the ‘src’).

As per CloudFlare:

In order for Rocket Loader to recognize the script, the data-cfasync=”true” attribute will need to be place BEFORE ‘src’.

Thanks for the solution, Uzair. I will implement this and report back.

The question is still begged as to how the plugin can actually fulfill its intended purpose given that it is placing the data-cfasync='false' attribute after the source rather than placing it prior. It seems pretty clear that it cannot.

In short, even though you’ve found a work-around to get multiple filenames inserted with the attribute, the attribute is nonetheless misplaced in the order of the URL. Ergo, CloudFlare still processes the URL.

To be frank, Uzair, I wouldn’t waste any more time on this plugin until its author chimes in. Let’s hope he opts to support it. It is looking, however, as if we ought not hold our breath.

I’m having this same issue.

The plugin also doesn’t accept exact files, even when only trying to add one (e.g. /jquery-migrate.min.js?ver=1.2.1). One has to use ‘jquery’ thereby adding the attribute to a host of things with ‘jquery’ in the URL. Etc, etc.

I actually wonder if this plugin can work given that it is placing the data-cfasync='false' attribute after the source rather than placing it prior… As I understand it, only the data-cfasync='true' attribute functions in this manner, and if and only if Rocket Loader is in “Manual” mode.