[Plugin: WP SlimStat] Version 2.5.1 significantly increases page load times

wp-slimstat.js may be the source of degradation. It runs at each page load. I found this in the load time report by testing my domain with https://tools.pingdom.com

My site shows an ~3sec increase. I’m ok with this for now but am considering StatPressV as a replacement.

I just ran a test with gtmetrix.com (great site, btw).

Anyway, with SlimStat installed or uninstalled, the page load times were roughly the same. However, SlimStat caused a three-point reduction in my Google PageSpeed score.

The PageSpeed score went back up three points when I set “Enable JS Tracking” to No. I probably don’t need that anyway, since Google Analytics covers what that covers, I think. (Let me know what I’m missing. ?? )

Thank you Steve,

I’ve tried to be as careful as possible in optimizing the code to reduce the overhead added by my plugin. GTMetrix penalizes your site, I think, because the javascript is not compressed. That is something I could not do on my end because most hosting providers do not support this feature (gzip). But once the javascript is cached by the browser, it will not be downloaded every time the user loads a new page.

Best,
Camu

Camu,

In my case, if the JavaScript is enqueued, the “Better WordPress Minify” plugin gzips it. It not enqueued, .htaccess deflate gzips it. I double-checked and this is all working.

What I think is the issue for PageSpeed is that this JavaScript isn’t enqueued, and thus the minify plugin can’t combine it with other JavaScript. Thus, it is seen as one extra resource to load, and PageSpeed likes these minimized.

Would it be possible to enqueue the JavaScript, or is this not possible by design?

Thanks,
Steve

Good point, I hadn’t thought about that! Maybe because old versions of WordPress (which I’m not supporting anymore, anyway!) didn’t have that functionality. Added to my todo list.

Cheers,
Camu

Done ?? Version 2.5.2 enqueues the script per your suggestion. Please let me know if this is how you wanted the plugin to work!

Camu

That did the trick! Thanks! Now, I have another suggestion, but I’ll start a new thread for that.

Cheers!

Steve

Cool, as you can see I’m always open to new ideas to improve my plugin.

PS: a vote for WP SlimStat would be a nice way to say thank you!

Already has a 5-star rating from me. You have a great plugin there.

Thank you, sir ??

wow, nice tip steve :} ur suggestion helped improved it, now i can worry less about using slimstats.

WP SlimStat 2.7 will further improve this mechanism by optimizing the script.

wow :d sounds good.

Thanks

Unfortunately the original issue is still unresolved.

From WP Slimstat 2.5.1 to 2.6 there is still a 30-50% impact on page load times than with all versions prior to 2.5.1. This occurs on a WP3.3 setup or prior WP version. Whereas WP Slimstat 2.5 works fine on WP3.3 and prior.

As awoz stated above, it may be an issue with the tracker, as when a filtered user views the same pages, the impact on load time disappears (as it does when WP Slimstat is deactivated).

Also, WP Slimstat V2.6 browscap.php line 230 is causing errors in the server logs whenever it is called (i.e. on every page view)

“[30-Jan-2012 13:45:29] PHP Warning: touch() [function.touch]: Utime failed: Operation not permitted in /usr/home/../../wp-content/plugins/wp-slimstat/browscap.php on line 230″

PHP V5.2.12. This may be a file permission issue. (The install instructions for WP Slimstat have been followed).