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
deferattribute 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?
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.