deferattribute is set, it specifies that the script is downloaded in parallel to parsing the page, and executed after the page has finished parsing.
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.
“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…)’”
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?