jscripts.php and W3TC

Hi ZehrGut,

I’ll be happy to answer your questions. ??

1. You are correct that the jscripts.php file cannot be loaded to a CDN. Files with a .php extension should never be loaded form a CDN so be sure your exclusion list includes .php files.
2. No, the plugin should be loaded on all pages. The jscripts.php file is a hybrid PHP/JS file so it has more functionality that aids in anti-spam even when loaded on pages that don’t have a form. It also adds essential hidden fields to all forms automatically, and this is how the plugin can work on forms where no additional code has been added. It will not slow down your site’s performance. (See the breakdown below.) If you use W3TC’s caching feature, you will be in excellent shape.
3. Regarding your own forms, it will work automatically on Contact Form 7 forms and many others without any additional code. All Contact Form 7 forms are covered. To test if other forms are covered, turn off JavaScript in your browser and clear your browser cache, and cookies. Then load up a page with one of your other forms, and try to post. If you get an error message regarding JavaScript being required, then the plugin is protecting that form. Turn JavaScript back on, and everything should work normally.

Regarding performance and W3TC, you will be happy to know that the plugin has been optimized to use a very light server load. It’s actually a very efficient plugin. Clients hire us day in and day out to optimize their sites, and we write plugins that help improve PageSpeed, so that’s one area we specialize in and would never let a plugin slow a site down.

Here is a breakdown:

• There is one hybrid PHP/JavaScript file called in the header of the page.

• It takes between .000200 and .000500 seconds to generate the file in PHP in most cases. That’s 1/5 to 1/2 of a millisecond, in other words, 1/5000 to 1/2000 of a second. You can verify by viewing the file and looking at the “// Generated in:” info.
• The total size of the file generated is 1078 bytes (just over 1kb) and already minified, so the amount of time it would take to download to the user’s browser is negligible, on any connection.

• There is one JavaScript file and a small inline script in the footer of the page.

• The JavaScript file is 750 bytes (less than 1kb) and already minified, so the amount of time it would take to download to the user’s browser would be negligible, even if it was in the header.
• This can be cached in the users browser so it will only need to download the first time it’s loaded.
• It’s in the footer of the page, so it would not add any time to the page load even it was larger.
• The inline script is 487 bytes (less than 1 kb).

• On posts that have comments, the plugin adds a small amount of code to the comment form.

• It is 398 bytes (less than 1kb) when site is in English (this size will vary slightly depending language but will not significantly increase), so the amount of time it would add to a page’s load time would be negligible.

• Database queries:

• During normal page loads the plugin used minimal database queries. For detailed info, use a plugin like Query Monitor to verify.

• Processing spam submissions is the only time that data-intensive processing occurs:

• Processing spam submissions is the most data-intensive part of the plugin’s work. Most spam comments are processed and blocked in less than .000500 seconds by the JavaScript and Cookies Protection Layer. That’s 1/2 of a millisecond, in other words, 1/2000 of a second.
• Even the most complex processing of spam comments (through the Algorithmic Protection Layer) happens in less than .25 seconds, in other words 250 milliseconds, or 1/4 second. This only occurs when a comment is submitted, and does not occur during regular page loads. This is still faster than any anti-spam plugin that uses a cloud-based service to check comments for spam. (And these slow sites down long-term because they store spam comments in the database, along with their meta-data.)

• The plugin is optimized to work well with all popular caching plugins.

All tests were done on shared hosting to replicate the average user’s experience. These times may vary slightly depending on the server, and will be even faster on VPS and dedicated hosting. (If you see significantly slower times than these, there there is definitely an issue on your site. Site slowdowns are most often caused by PHP errors, memory issues, and old PHP versions.)

As you can see, it’s simply not possible for the plugin to slow a site down, and no further optimization of the plugin is needed. It has negligible processing overhead on normal page loads and only adds 2,713 bytes to the overall code that downloads to a user’s browser. In fact, because it keeps spam out of the database, and helps prevent database bloat, it actually speeds your site up in the long term.

I hope that helps! Let me know if you ever need help again.

– Scott

Scott, thanks a lot for such detailed response!
Appreciate this very much!

You’re very welcome! ??