WP-Optimize Plugin Accused of Cheating PageSpeed and Other Performance Testing Tools

Gijo Varghese, a developer who calls himself a “web performance enthusiast,” shocked WordPress users around the world over the weekend when he tweeted a screenshot of how WP-Optimize is allegedly preventing select JavaScript files from loading when users test their sites through popular performance testing tools.

“When a site is loaded, the JavaScript files are loaded only when the user-agent/browser is not Lighthouse/GTmetrix/Headless Chrome/Pingdom,” Varghese said. “No JS = high scores. But for real users, these JS files are loaded!”

Varghese confirmed that he was testing the free version of WP-Optimize, which is used on more than a million WordPress sites. UpdraftPlus acquired WP-Optimize in 2016 and claims that the tool “has everything you need to keep your website fast and thoroughly optimized.” A commercial version is also promoted through the free plugin that is hosted on WordPress.org.

“Tell me, UpdraftPlus, how I’m supposed to continue trusting your company with my clients’ backups when you use these deceptive and fraudulent practices?” one customer Adam Lowe said in response to Varghese’s discovery of the plugin not loading JS for performance tools.

“Wow, all I can say is what an utter disappointment,” WordPress agency owner and developer Brian Jackson said.

This type of alleged deception is eerily similar to a scam reported by someone who contracted a performance freelancer on Upwork who artificially manipulated Google Pagespeed results. Others participating in the discussion on Twitter compared it to the Volkswagon emissions scandal where the carmaker was found to activate its emissions controls only during laboratory testing in order to meet the EPA’s requirements after a violation. The vehicles on the road emitted up to 40 times more nitrogen oxides while driving, as compared to how they performed in the rigged laboratory tests.

Varghese and several other participants in the conversation concluded that this is why site owners should focus on what real world users are experiencing, instead of performance tool test scores.

Even when focusing on real user experiences, site owners often rely on the tests to diagnose issues and see how a site’s performance can be improved. They don’t expect that a plugin will be hiding JS files from performance tools. Tricking the tests has eroded WP-Optimize’s credibility.

“Wow. If true, this is as short sighted as it is inexcusable,” UpdraftPlus customer Johnathon William said. “And it makes me wonder if I can trust their other product, UpdraftPlus, which I use to backup several client sites.”

I contacted UpdraftPlus and lead developer David Anderson said the company was not aware of the issue with the code but related some of the backstory. UpdraftPlus was briefly in talks with the author of the Fast Velocity Minify plugin about the possibility of combining forces, in which he would maintain the minification module within WP-Optimize and gain more users. Ultimately they could not come to an agreement, but during that time WP-Optimize’s developers forked and adapted Fast Velocity Minify under the GPL. The developers who worked on that adaption are no longer with the company.

“In the commit to our own source repository, 2.5 years ago (Jan 2020), the commit was labelled ‘Resolve ‘Add CSS and JS Minification GPL code from ‘Fast Velocity Minify’ – Part 6′,” Anderson said. “Part of a series of initial merges of code that was re-factored to be cleaner and use our coding style preferences (but not change any functionality). So the apparent intention of the merge of those lines was to bring over refactored code without at that stage making any changes.

“According to the commit history (i.e. the ‘git blame’ function) no changes have been made to that code since, i.e. it is as-imported. (The history for WP Optimize is public in WordPress SVN too).”

After a cursory examination of the code, Anderson concluded that his team may need to reexamine it, as they were not aware of what was added two years ago.

“As I try to trace that function through the code within the plugins, the intention on the face of it appears to be that if the website visitor is a ‘bot,’ then code that is pointless for bots won’t be carried out,” he said.

“However having said that, 1) the bot names look to be heavily obfuscated/redacted, which is strange (why?), and  2) there are plenty of more obvious bots that aren’t listed there, such as the Googlebot itself. If that function was being put before me for review today, I’d certainly question why that is so. I can’t mind-read myself back 32 months ago, but, I remember it as being a long series of large patches, so it wasn’t being closely analysed on a line-by-line basis. We knew that we had identified FVM as a good plugin and our main focus was on adapting it to our structure and style, and those were the things I personally was looking at as the final reviewer.”

In summary, UpdraftPlus’ development team was not aware of this code until the Twitter thread was published over the weekend.

“I’m certainly glad to have it brought to our intention,” Anderson said. “The associated code comment on a related fragment in its original source that it’s intended to prevent unnecessary requests for bots, but on a closer examination than that line got at the time, that’s something we’ll want to look at, as it does look questionable/strange, and we’ll be doing that by assigning it to a team member who’s our expert in JavaScript optimizations.”

Anderson also said that if the JavaScript optimization experts cannot find any legitimate purpose for the code, “it will certainly be removed,” with a clear and unambiguous disclosure for the reasoning behind it.

In the meantime, UpdraftPlus has published a notice in the plugin’s support forum to inform users that the code is currently under investigation.

“To be clear and set users’ minds at rest: the code in question is not dangerous, a virus, an infection, useful to hackers, or anything of that kind,” Anderson said. “The allegation is that its only purpose in existing is effectively to cheat on speed tests. Such code, if so, does not belong in WP Optimize and we will remove it with a new release. Our products’ integrity, and our customers’ trust, are essential for us (and deliberately putting things in open source code that compromises that is, frankly, a stupid thing to do).”


46 responses to “WP-Optimize Plugin Accused of Cheating PageSpeed and Other Performance Testing Tools”

  1. Just one extra clarification (way, way past bed-time now, very tired….). The words “that code” in the quote in the article is intended to refer to those few lines that have been identified as problematic. It doesn’t mean the minification module in general, which has been subject to continuous improvement, bug-fixing, etc. (The quote if read out of context makes it sounds like the minification module is more or less a copy – but it has never been that, after forking it underwent months of our own development before the first launch, and that process has continued since).

  2. Frankly, given how often we all use more or less unvetted dependencies, I’m surprised this type of thing doesn’t happen more often.

    Btw, I think you should have mentioned in the WPT article copy that Gijo is the author of another speed related plugin. That doesn’t change the facts. But not everyone is going to check the dependency (i.e., click the link). Yeah, kinda ironic.

  3. Preventing requests from bots is not a good explanation to me, as bots still can access to the page. If that’s the purpose, bots should be blocked from all requests.

    I hope the team will remove the code and examine the plugin in a whole. The company and brand is big and this will break the user trust.

  4. Thire is another one plugin which do the same which load the js files with delayed so Google Page Speed Inside show 95+ score by just installing and activating the plugin.

    I did lot of research regarding speed optimisation but when I see that plugin it surprisingly show 100% score.

    I was really shocked. I had checked it on websitepagespeed test site and found that the plugin don’t load the js files initially.

    And page Speed online tools don’t detect the CSS and JavaScript file’s that’s why it’s loading fast.

    It is something crezy and something misleading for end user. Because mostly user notice such technical stuff.

    • To be fair, vanilla WordPress with text and appropriately sized images runs very fast, especially if you pay for decent hosting. The real bloat comes in with themes, plugins, and website owners uploading massive images or videos. None of which WP core can control.

      • I think the point maybe more that core should protect users more from doing things that slow their site. Rather like core is trying to protect users from having to know html and CSS or going through the pain of selecting the most appropriate page / site builders. It is totally possible for core to optimize images on upload, minimise and combine html/css/javascript, have built in page caching processes etc. rather than leave non technical users having to test the best marketed optimization plugins when they discover their site runs slow.

        Just putting the other side of the coin there.

  5. Interesting to read about this now when Nitropack was/has been doing that exact same thing for a long time.

    Things like this will keep happening if admins and stakeholders blindly rely on KPIs (like Pagespeed Insights) without checking what they actually refer to. So they’ll happily accept increase in the number and even push for these.

    I had multiple clients complaining about their Pagespeed Insight scores while not wanting to remove their 100% background images or
    autoplaying background videos.

  6. This is not a lot different from theme developers advertising their themes loading times and performance scores, while the tests are done on blank pages with no scripts and no content.

    But this is also very predictable. As long as there are tools that generate a score, people will find ways to manipulate those scores. Either through normal means or through cheating, a high score of any kind is a marketable asset.

  7. (Please use this comment, not the just-posted one which accidentally missed a line).
    Now that our main WP-Optimize developer (in a different timezone) has got out of bed and investigated without the time pressure deadline that WP Tavern gave us and explained, the situation now looks very different, and the controversy is entirely mistaken.
    I sent in what I could when given a very short deadline just before bed-time in our timezone (a UK post-weekend public holiday, which I had not spent monitoring any corners of Twitter; we do have other official support channels), and did my best. But the controversy would not have existed if we’d been given time to let the main developer get out of bed, it’s simply wrong.
    I naively assumed that with what I’d written WP Tavern would contact the author of the other named plugin for his input, or at least redact the details at first, completing the research before publishing. In respect to him we did so on our posts on wordpress.org and getwpo.com. On seeing the piece I immediately wrote to him to apologise that he’d been identified here through my words.
    Details will be forthcoming in the proper channels. We will have to discuss with WP Tavern – we are very unhappy about how this has been dealt with.

  8. Has any one tried to replicate this behaviour without ticking abox that says ” would like to exclude scripts from page speed tests (PageSpeed Insights, GTMetrix…”!!!

    What testing did WP Tavern do before re posting news from Twitter from some one that followed the revalation with “Shameless plug: if you want to improve the “real” performance for “humans”, try ….”?

    Asking because something does not seem right here, I tested and so did others and something smells fishy.

      • It does what the label next to it says it does, and the tooltip explains its legitimate uses.
        I’d been up since 5am and took the info that the Tavern says they were about to publish shortly before bed at face value when asked for comment, and missed the bleeding obvious (as I say, our main developer was in bed). That was my mistake, and unfortunate for us.
        Three questions about the story interest me: 1) Did WP Tavern notice that the guy who created the Twitter storm is a direct competitor? 2) And that he responded to people on Twitter who were outraged by what he’d reported by marketing his competing products to them? 3) If WP Tavern knew, then should not those facts be present in the published story?

      • Exactly.They don’ know yet if it is dubious or valid. No one – not even the original Twitter poster has yet posted a repeatable methodology to should it is deceiving users. Yet several people testing can only make it happen IF that box is checked. Have you tried?

  9. Hi there,

    I am the author of the FVM plugin referred on the article here.

    A few years ago, developers of the WP Optimize plugin decided to copy portions of FVM to their code (no problem for me as the plugin is GPL) and I can confirm that equivalent code was part of our plugin.

    However, the purpose of such code on FVM was completely different than the one on WP Optimize and furthermore it required for the users to manually enable this option via wp-admin (it was disabled by default).

    The purpose of that code was to selectively test the impact of new scripts or plugins in performance, and help developers decide if they should refactor, remove or replace heavy plugins or scripts.

    This existed on FVM to answer questions like these:
    “I have a production site and my performance is low. What would be the performance if this plugin was simply not here, but without actually removing it from the site for regular users yet?”
    “What would the performance be if I could defer all scripts, or specific scripts that are not currently compatible with defer, before actually doing that change for everyone?”

    An official explanation regarding it’s use on FVM exists here,

    I suppose that the developers hired by WP Optimize did not understand what this was doing on FVM or under what settings, or perhaps, they may have felt tempted to use it as a hack.

    We should also carefully remember that at that time, there were still no web vitals metrics publicly available, so using something like this would have yield better “measurable” results, thus offering a product advantage.

    Whatever was the case, WP Optimize and FVM are unrelated, so their choice to copy and refactor that code to do what it does is theirs alone.

    • “It was a feature that existed as an option on wp-admin (disabled by default), for developers to test the impact of the “specified scripts”, fonts, or ajax requests on performance, but without impacting real user experience.”

      I believe, and I have asked the Twitter poster 3 times now for his methodology and he has avoided a straight answer, that this is also ONLY is the option is set and a script specified in WP Optimize.

      I am happy if someone proves me wrong and demonstrates how teh code can be triggered without user knowledge.

  10. Please Post another article regarding this after checking with other developers as it seems a false claim. The Claim that he accused as a cheat is already mentioned in the plugin backend. It’s not good to kill a reputation for competition. If it was due to any confusion or mistake, he should apologise. WP Rocket also has Js Delay Option which is almost the same thing.

      • This is not good Sarah. It’s obvious to me and other plugin leads that this is a false claim. It’s not on that developers of plugins can make these claims and it becomes headline news before being truly investigated which it now has. This claim is false by the OP on Twitter and a retraction by wp tavern and him is the right thing to do.

        • We are definitely going to write a follow-up and informed UpdraftPlus as well when they said they needed to investigate to understand their code better, as it had not been touched for a few years. With hundreds of people discussing it, it was definitely pressing news and we included UpdraftPlus’ understanding of the situation as well. More info will be included in a follow-up. This is a developing story.

          • Sarah, while the follow-up is being researched and written, wouldn’t it be appropriate to insert a notice at the top of THIS article, stating that this is a developing story and that it has now been called into question whether there is any deception or trickery involved?

            This article uses the word “deception” – that’s your word, not a quote. Deception, by definition, requires intent. It seems very clear at this point that it would be unreasonable to attribute an intent to deceive to this component of the plugin.

            Under the “Defer selected JavaScript files” option, this looks to be a case of inadequate documentation. Although the on-screen instruction alongside the option DOES state it will exclude the script from page speed tests, it does not explain when or why you might want to do that. Under the “Defer using JavaScript” option, which is not a default option, this appears to be a bug.

  11. I just noticed that WP Rocket does the same. Testing a website this afternoon, and viewing the source code, yielded 28 .js files. Using WP Rocket and testing with GTmetrix, yielded only one .js file, a lazyload.min.js script. The results in GTmetrix were obviously 99-100%.

    I find this misleading, again, as the website is not as fast for me, as a user, than it is for GTmetrix.

    As a developer, I would try to bring those 28 scripts down to a maximum of 5-6 and be able to test the impact.

  12. I just checked Gijo’s own FlyingPress, and it has the “Load Script on User Interaction” feature. But it’s clear what it does, and it’s something you can choose to turn on, and you even have to set which scripts delay manually.

    Yes, on mobile devices, it would up the page speed, but on desktops, not so much since the mouse is almost always moving.

    I would say it’s cheating to use such a feature, as the speed tools don’t include delayed scripts, thus returning a better score than the site have. But for the end user, scripts are loaded anyway if they move the mouse.

    A better, more correct way to optimize scripts is to async, defer, and remove JavaScripts that are not in use. And choose plugins that output less code. Rather than using Divi or Elementor, use something like Bricks or Oxygen Builder. It’s like 7-10x less code on the front end.

    There’s a helpful thing you can do with scripts like live chat. I use the GTMs feature of executing the live chat scripts when reaching a certain scroll depth on the page, like lazy loading the JavaScript.

    Let me explain why I don’t think that is cheating.

    Not only does it improve the overall performance but also the first impression.

    Because the thing is, when a live chat is loading initially, there are message notices, and a chat bubble shows up. And this often steals attention from the visitor when the primary focus is to read the headline.

    You have a few seconds to get the reader interested, and you rarely need the live chat at first. So lazyload such things to when it’s more likely to be wanted and used.

    • Your article deals with the facts fairly well, except one section “Response to WP-Optimization’s Claim” which does not present the full picture or time line. At the time I was following closely as an independent too, and I had pressed Gijo three times to reveal his methodology as several of us had been unable to reproduce the issue. At that time, as he had not revelled his methodology, it was assumed by many ( and I believed WP Optimize under pressure to respond ) to be the option that had the notice that it does what is says on the tin. Only later Gijo reveal the other option also did it without the written text.

      I also think your article could have also examined the process of public ‘reveal’ of a free plugin issue on Twitter and then that getting picked up by WP Tavern.

      In my opinion, this is not the accepted behaviour of Open Source collaborators, as is the ethos of WP and free plugins published on WP.org. My take on the ‘right way’ is Gijo should have raised this with the plugin author, and if he felt that it was something to be aired publicly that the right public place is the plugin’s WP.org support forum.

      • Thanks for clarification. I wouldn’t comment on the open source ethos as I am not the best person to do that.
        My article talks about whether the claims are true or not and the response of Wpo team.
        I tried to be neutral. In fact I had the opinion that Gijo manipulated by misrepresentation. But as I tested, I was wrong.
        The Wpo team’s response does not AT ALL address the “Defer All JS” feature which Gijo talked about.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.