WP-Optimize Denies Allegations of Cheating Performance Tools

Yesterday, we published allegations from Gijo Varghese against UpdraftPlus, the makers of WP-Optimize. Varghese is founder of FlyingProxy, a competing company, and identifies himself as a “performance enthusiast.” He accused the plugin of “cheating Pagespeed and other tools” by hiding JavaScript files from loading when users test their sites through popular performance testing tools. The code uses an odd set of obfuscated names for the testing tools, which drew his suspicion.

Varghese neglected to mention in his tweet that this is what happens when one of the plugin’s settings under Minify > JS is set to defer JavaScript. There are two radio button settings but they are confusing.

The first radio button allows users to defer selected JavaScript files. It says the files will be loaded asynchronously (not the same as defer), and then it also says that users should select the first radio button if they want to exclude scripts from page speed tests. It is not clear how the scripts will be loaded for the user or for testing sites. Excluding is not the same as deferring, so in this case the settings UI is somewhat misleading and should be more clear.

The second radio option is for users who are simply looking to defer all JavaScript. If one selects “Defer using JavaScript (Use this method if you require support for older browsers),” it should do exactly what it describes in the link:

If the defer attribute is set, it specifies that the script is downloaded in parallel to parsing the page, and executed after the page has finished parsing.

Even though the UI says it is deferring all files, WP-Optimize never loads the JavaScript for performance testing sites. In this second option, the exclusion of testing sites happens without the users’ permission. If users had wanted that, they would have selected the previous radio button and explicitly identified which scripts to exclude.

Varghese left out some significant details in his original report, but it was accurate in that certain settings are misleading about what they actually do. He demonstrated this in a follow-up video where there is no manual entry of any scripts to exclude and the second radio option is checked.

“They’re providing an option for users to cheat testing tools,” Varghese said. “Also, using names like ‘ighth’ for Lighthouse and ‘tmetr’ for GTmetrix clearly shows what they’re trying to do.

“Most of the users try disabling and enabling different features to see which one is increasing the speed/scores in testing tools.”

Varghese contends there is no need to do things differently for testing tools and humans, as this can be confusing for site owners. His allegation left out significant details and implied that all of this is hidden in the code. It is for one of the settings but not the other one. The interface implies that you must enter scripts manually to exclude from testing, but this is also misleading.

WP-Optimize published a public response to the allegations today, but has not revealed any of the results from the code investigation they completed. Instead, the company cited a video created by Peter Wilkinson from Divi Engine, who claims that users must manually enter scripts to make testing sites exclude them.

Wilkinson is quoted as concluding that “Gijo Varghese has used deception to promote Flying Pages and Flying Press” in bringing this issue to public attention on Twitter.

“In reality (from my research) WP-Optimize do not ‘cheat’ Pagespeed tools when you install or Minify your JavaScript,” Wilkinson said.

“To ‘cheat’ the tools, you need to manually add the JS files you want to asynchronous load to a setting that clearly has the label ‘Use this if you have a completely independent script or would like to exclude scripts from page speed tests (PageSpeed Insights, GTMetrix…)’”

This is not the case. The easiest way to test is to install the plugin, turn on “defer all JavaScript,” and then view the source to see that performance tools are excluded.

Since WP-Optimize’s public response to the issue did not include anything from their code investigation, I contacted them again. Their deputy lead Venkat Raj was not available to answer why other settings in the plugin silently remove JS for performance testing tools with the click of a radio button. Joe Miles, head of strategy for the company, shared the last information he received on the issue from Venkat Raj:

“The advanced setting used in the allegation is actually useful to find out whether the essential js/css files are actually slowing down the web page or not.  This feature is by default, turned ‘off’ and only enabled by advanced users who know what they’re doing.

“You may use this feature if you have a completely independent script or would like to exclude scripts from page speed tests (PageSpeed Insights, GTMetrix…)

“Independent scripts are for example ‘analytics’ or ‘pixel’ scripts. They are not required for the website to work. ‘Use this if you have a completely independent stylesheet or would like to exclude stylesheets from page speed tests (PageSpeed Insights, GTMetrix…)

This applies to the first radio button. The second button does not have any indication that it will turn off all scripts when using testing tools – nor does WP-Optimize’s team seem to be aware that it is available with the click of a radio button.

Miles could not confirm whether this is how it is intended to work or if it is a bug. He also could not account for why the names of the popular testing sites were obfuscated in the code, but said the original developer “doesn’t work for us as it’s open source code repurposed from elsewhere.”

“However, we believe this is a distraction from the false allegations, and what matters is that the UI is very clear for the settings are for, so users aren’t deceived,” Miles said.

Raul Peixoto, author of the Fast Velocity Minify (FVM), the plugin from which WP-Optimize copied the code, said he can confirm that this code was part of FVM but said it was not used in the same way:

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 its use on FVM is available in the plugin’s support forum as of this morning.

“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,” Peixoto said.

“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.”

Piexoto said he “felt compelled” to remove this code two years ago because of how often it was abused by developers who were cheating on tests for their clients:

Fast forward some time, and I realized that some developers were actually using this to cheat on the tests for their clients, so I felt compelled to make the decision on FVM 3 (already late 2020) to remove this feature, which was met by a lot of protests of angry developers when their clients started complaining that their scores went down.

I tried at that time, to explain that having a good score was not the same as having good web vitals metrics, but eventually I gave up on that, as some people cared more about the test results than the actual performance.

After FVM 3 release, I am basically just maintaining it and doing small bug fixes when reported, as I have to focus on other things. I have removed that function and fixed a couple of bugs that were pending on version 3.2.9 and pushed an update, so thank you for referring this to me.

For whatever reason, UpdraftPlus chose to merge this code into WP-Optimize in 2020 and, as reported yesterday, hasn’t touched the code since.

What appeared to be a black and white issue yesterday is a more nuanced situation. WP-Optimize’s implementation of FVM’s code is poorly documented in the UI and misleading about how the scripts are loaded. It can lead site owners to activating it without being advanced users, and historically has a high potential for abuse. When Varghese discovered it, he exposed it in an inflammatory way, feeling certain he had found wrongdoing because of how inexplicably obfuscated the code is. This compounded the issue but started a broader, important conversation.

Should users have this kind of easy access (two clicks) to turning off scripts for performance testing tools? How can developers in the same industry better communicate about potential harms to users that they see in others’ products? What kind of code documentation requirements should agencies implement to prevent a situation like this where code needs to be investigated over the span of days in order to find out what it is intended to do?


23 responses to “WP-Optimize Denies Allegations of Cheating Performance Tools”

  1. This article takes simple things and makes them complicated.
    Yesterday WP Tavern published an article repeating Twitter allegations about WP Optimize possibly having a deliberate and disguised intent to cheat PageSpeed-like testing tools for evil ends, based on the allegations of someone who was presented in the article as an independent party.
    That, and only that, is what we should have been discussing. Deliberate hidden cheating, disguised deception, now caught out, etcetera. That was the accusation.
    Upon investigation once our expert developer, who couldn’t be consulted prior to that article (being asleep in another timezone) was able to get up, it was quickly spotted that actually the guy had entered settings into an expert-user field which said right next to it that it was for omitting things from PageSpeed bots (and had a tooltip explaining further some potential use-cases, which were not how he used it). The whole premise of the guy’s outrage, and the story – that there was something deceptive, hidden, an attempt to cheat, evidence of evil, etc., was just entirely false. The failure to clearly explain that he was entering his own settings into a explicitly labelled feature was also highly objectionable. The feature is up-front, and has legitimate uses, and if someone decides to use them to cheat, that’s something else. Not what the original allegations were about.
    If there are bugs, that’s also something else. If someone thinks that the use cases don’t actually makes sense, that’s also something else. If someone things that the user interface isn’t as well presented as it could be, that’s also something else.
    The guy hyping all the outrage about deliberate, hidden cheating turned out to be a competitor who was in the same thread promoting his own products as the antidote to these evils.
    And as I say, that’s the end of the story. The article above is a new really over-complicated story about tangential questions and issues and third-party off-the-cuff speculations and musings about those related, but actually different, things. We’ll no doubt, as part of normal development, have a look at related issues. But they’re not what the allegations and outrage stirred up by the original Twitter poster were about, or the preceding article. Twitter is there for people who like discussing these things on Twitter. For me, I’d like to get back to doing useful work.

    • That field in question used by Gijo does NOT have the same label / information as the other one you reference. It is a one-click radio button and something a standard user might try out considering “Deferring Javascript” is what the feature is called. Yes, it’s there on the other radio button, but the logic behind radio buttons is that they are seperate choicecs – so the information, logically, would only apply to the first selection. Besides, why is this called “Defer Javascript” when it is more like “Hide JavaScript from page speed tests and load them asyncronously for users”? I would definitely not expect it to do that. If this is meant for testing scripts agains page speed tools then why isn’t it clearly labeled as such?
      At best this is bad UI that should be fixed.
      I have to agree this could have been handled more clearly initially to avoid this confusion – but you’re not making it any better by still not understanding (or pretending not to understand) the issue.

      • That’s a “bait and switch”, Niko. The allegation (look at the title of the WP Tavern stories) is of deliberate deception, such that it justified jumping ship from WP Optimize for moral reasons.
        If he’s now talking about confusing UI, or buggy behaviour, etc., that’s something to raise in a support channel, not a cause for moral outrage and Twitter lynch mobs.
        I said: you can consider other issues lodged in our support tracker for normal processing. I’m not ignoring “the issue”, because “the issue” as framed was that we were doing deliberate evil. We’re owed an apology for that, not a bait-and-switch to something else.

        • It could still very well be argued that this is deliberate deception. It’s not a different topic and therefore not a bait and switch.
          We will never have an answer whether it was deliberate or not becase we can’t read the person’s mind who made the decision.
          The original point stands – your plugin is tricking people’s sites into ignoring page speed tools by making it very confusing (and I’d argue impossible) to understand this is what the function does. This is the issue you are not addressing and I have to think it’s deliberate at this point – it’s making you look much less trustworthy.
          I notice you still haven’t addressed the issue that this button in question DOES NOT have the same information as the per-script exclusion button or that this feature is extremely misleadingly named (Defer All JavaScript).

      • As I’ve said, I’m not really here to discuss UI choices – not because I think they’re not up for discussion or are always right (not at all!) – but because I object to it being done under the framing of a competitor attack that has caused repeated headlines about “WP Optimize Cheating” to be fed into every WordPress install in the world (and because frankly, it’s not my role!).
        But for what it’s worth, our main JavaScript developer thinks it’s perverse for someone to claim that you wouldn’t expect the button marked “all” to be doing all that the radio for merely ‘some’ was doing. Excluding “all” scripts does the same for “all” scripts as excluding individual scripts does for those scripts.
        And that makes perfect sense to me – after all, as far as I know, absolutely nobody else was confused by that up until the competitor was. Our developer uses the analogy: if the car manual says that you shouldn’t drive the car at 100mph on public roads, then a driver doesn’t get to claim that he wasn’t told he couldn’t drive it at 150mph. The greater obviously includes the lesser.

        • This isn’t a question of just UI choices. This is a question of misleading description of what that function does. No other optimisation tool I’ve ever used has had “Defer JavaScript” as a “testing tool to bypass page score tests”. Deferring JavaScript servers a different purpose (legit optimisation) and the fact that, only in a related setting you have a small text about this is a dark pattern. Intentional or not.

          It would be much better for you to recognise these following things:
          1) The text should be on both of the options
          2) It should be called something more descriptive than “defer JavaScript” to avoid people mistaking it for legit optimisation

          Now these things are not a huge deal IMO, it could be a simple mistake or not thought out completely. However the practical effect of this now is that, even a semi experienced developer like me, could very easily miss this and just try to optimize my pages by deferring all JS. If I didn’t read the fine print in the other setting (and understand it also applies to the other since it’s far from clear) I’d feel cheated.
          I’m a bit surprised you’re not ready to budge on this – it makes this whole thing feel like you’re hiding something and that this is actually intentional. If you said “Yeah, I can see why those settings can be misleading and we’ll look into fixing it to be more clear” this wouldn’t be an issue, for me at least.

    • To be honest, that’s kind of a disappointing response to the situation.

      I actually thought your comments yesterday were quite good – you explained (I’m paraphrasing) that most of the minification code was taken from another plugin and it may not have been completely reviewed when that happened, so you would be taking a closer look at it going forward and any dubious functionality would be removed. It sounded like a straightforward, honest answer, and you seemed to be doing a good job making the best out of a bad situation. Today, on the other hand, you seem to have forgotten everything you said yesterday and decided to just do your best Leslie Nielsen impression… (“Nothing to see here!”)

      What about the code with the obfuscated user agents? Are you going to do anything about that? It seems to be a violation of guideline #4 of the WordPress Plugin Directory guidelines.

      • Hi Ed,
        Yesterday I took at face value the report that WP Optimize had hidden behaviour, and responded to that when given a really short deadline before bed-time, with the limitation that I was not the developer, who was already asleep. The next day on proper analysis we spotted the obvious thing, that the guy had actually entered something into a clearly labelled setting, and had declined to actually point out that he’d done that, and so the whole thing was absurd.
        The user agent list came over from the original source of the plugin. Given that the user inteface is clearly labelled “exclude scripts from page speed tests”, I don’t see how that could be counted a deliberate attempt to obfuscate anything. I also find it odd that the user agent list lists fragments instead of complete strings, but from my point of view here, I’m just dealing with the allegation that someone’s trying to deliberately hide the purpose of the expert setting. Anything else is a run-of-the-mill support request, not a cause for launching a massive public attack. We’re happy to process support requests – but as I say, I’m distinguishing those from competitors alleging that we’re evil, and that’s what I’m saying here.

      • (Please post this response to Ed which I believe makes how I see it clearer than the previous one).
        Hi Ed,
        I don’t mean at all to be understood as saying that WP-Optimize has no room for improvement, or no room for improvement around the discussed feature. Not at all. As per my comment, we’ll certainly want to look at the feature using our normal development processes. “Nothing to see here” is absolutely not what I want to be heard as saying. We respond to all users’ support requests and ideas and are grateful for them. They’re an important part of improving.
        What I’m responding to here, under this article, is specifically (and really, only) the Twitter poster’s offensive framing that WP-Optimize is deliberately evil and should be abandoned (preferably for his products). He’s managed to induce WP Tavern to run two articles under that framing of the issue, and managed to induce his Twitter followers to propose that the plugin directory should cancel our plugin. That’s why I’m here. (I’m assuming most people wouldn’t like to see that in their daily feeds).
        We have channels for discussing plugin development and features in normal ways. But under the framing of deliberate cheating, that’s what I came here to discuss – to refute a direct and public competitor attack that successfully induced WP Tavern to then re-publish the allegations and get them syndicated to every WordPress install on the planet via the news feed. Ouch. Other issues, as I say, fine. But in their proper channels, not as part of a public spat under the current framing, I’m not up for that. That’s not running away – it’s not actually my normal role to discuss precise UI implementations anyway, as I’ve said, our main WP Optimize JavaScript expert is someone else.

        • Sure, of course no one wants to see that sort of thing in their daily feeds. But again, I thought you were handling the situation quite deftly on day one, explaining where the issues in your plugin came from and promising to do something about them. Then the next day you seemed to flip 180 degrees and claim that you were nothing but an innocent victim being persecuted for no reason. Yes, the plugin’s settings should have been mentioned in the original story, but that doesn’t change the fact that there are real, serious issues with your plugin. Multiple serious issues.

          One of the issues – and this is largely, if not entirely, unrelated to the issues with the plugin settings – is the obfuscated user agents. You still have not explained what you plan to do about those. At a minimum, I would think you would want to try to de-obfuscate the user agent names and make it clear what it is you are sniffing for. But it would probably be better to just remove the user agent sniffing entirely.

          If people are suggesting that the plugin directory should remove your plugin … well, that’s not really surprising, because it appears to be in violation of the plugin directory guidelines (specifically #4). You keep talking about how you may make changes in “normal development processes” but I would think that fixing a guideline violation would be a bit more urgent than that.

          • I don’t see anything obfuscated part though. To me it looks like a normal math() function with the “internal content” of the user agent? My guess is the original plugin author used it to avoid capitalized letters issues. Or am I missing something?

            • Well, if you look at the original tweet that started this, it shows a screenshot of some extremely cryptic-looking JavaScript code. To be honest, if I saw code that looked like that on my own site, my first thought would be, “Oh no, the site’s been hacked.” (Because hackers love to use obfuscated code.) If I were to examine it further, I would probably conclude that it doesn’t really seem like a hack, but it appears to be checking for a bunch of user agents I’ve never heard of – “ighth”, “tmetr”, “eadles”, “ingdo”, and some others that are even stranger-looking. I would probably guess that these are simply some obscure bots that the author of the code decided to exclude for some reason (perhaps they’re just badly-behaved). I would be unlikely to realize that these are actually substrings of legitimate performance testing tools – Lighthouse, GTmetrix, Headless Chrome, and Pingdom.

              To answer your original question – the regular expression has the /i modifier at the end, so it is a case-insensitive match – capitalized letters can’t be the issue.

              It seems to me, if the author of the code had a legitimate reason for wanting to detect, say, Lighthouse (for example), then it would be better to simply use “Lighthouse” in the regular expression match. Not only is it easier to understand, it’s also less likely to result in false positive matches (e.g., suppose in the future someone creates a browser named “Nighthawk”). I can’t see any reason why anyone would use short, cryptic substrings of the actual user agents – unless the intent was to obscure the purpose of the code.

    • There is still a problem with your plugin that you seem to underestimate: if people is legitimately willing to defer their JavaScript on their site, they are automatically cheating the pagescore tools. This is not an ok situation, and should be fixed even if you consider that having a “test” function in order to skip pagetools userAgents is ethically correct (there is a debate on that too).

      • As explained (not just by us), there are legitimate reasons for being able to test different Page Speed scenarios. The feature is clearly marked. Yes, a site owner could decide to abuse that. If anyone says that I’m encouraging them to do that, and launch a public outcry against me for that, then the only thing I have to say is “they are lying and should apologise for that sort of dishonourable speech”.

        If someone wants to say that they consider the feature problematic for other reasons, that’s legitimate debate. But the reason I’m here in WP Tavern is not to have a lengthy debate about other things, it’s because someone decided to launch a public assault on our integrity, and because WP Tavern gave that publicity. We have support channels and processes to look at other things, and really aren’t eager about doing it under a framework that’s something like “should we publicly lynch these wicked people”?

        • From your answer, it looks like you don’t understand the point that I’ve raised. Let me rephrase it: How are we supposed to differ the Javascript files (legitimate action) without cheating the pagespeed tools (debatable action) using your plugin? If the answer is “you can’t”, then there is a legitimate concern you are encouraging cheating the pagespeeds and the first thing you should do is to fix that ASAP if you wanna keep your integrity intact.

  2. UIs are subjective. You can code and design that section a hundred different ways and still irk people.

    That this being a “hidden” advanced feature, it doesn’t surprise me that it would confuse normal users.

    Knowing UpDraft and their team, they want thorough options and the fact that you can activate a complex action in two clicks should be applauded, not sanctioned.

  3. I looked into this and did testing.

    The fact is, there is functionality in WP Optimize that almost all of us (working in good faith) would want removed, functionality that is indeed controversial and has been employed by other plugins in the past with an admitted aim to get better core web vitals scores (not WP Optimize).

    So this functionality is controversial, and simply has no place in any performance solution for WordPress. The functionality being here, also nulls the purpose of the actual feature itself – a feature that exists in almost all script management solutions minus the hiding to page speed tests.

    What we know is the plugin does this. What we don’t know is if WP Optimize had a naughty motive to do this, and if Gijo had a deceitful plan to promote his product – we don’t know these things, we can guess only.

    This initial Tweet was “possibly” (because, I don’t know intent right cause I’m not Gijo) born out of frustration. It’s escalated here on the Tavern in a most unfortunate way.

    OK so WP Optimize does need to change the plugin, I for one as somebody identifying as a “web performance enthusiast” could not use WP Optimize without the following tiny tweaks:

    Here is the solution to put this to bed:https://share.cleanshot.com/X4Xcmf

    Likely people may not agree with my take, I have no skin in the game here.

    A washed up WP Podcaster indentifying as a “Designer” (pronounce part in air quotes with sarcasm please).

  4. Darn it!

    From my perspective, open source and radical transparency go together. When we offer open-source repo plugins to help site owners with some performance problem, we explain what we do, and how we measure what we do, to the best of our abilities.

    All this performance scrambling we do: it’s about our human users, delighting them and respecting their time.

    Spoofing browser performance measurement tools? Just how does that help our users? Maybe it sells more premium plugins, sure. But does it help the plugin customers help their audience?

    To the extent there’s any demo-hacking going in here, it breaks my heart.


Subscribe Via Email

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

%d bloggers like this: