WP-Optimize отрицает обвинения в мошенничестве с инструментами повышения производительности

Вчера мы опубликовали обвинения от Gijo Varghese против UpdraftPlus, создателей WP-Optimize. Варгезе является основателем конкурирующей компании FlyingProxy и называет себя «энтузиастом производительности». Он обвинил плагин в «обмане Pagespeed и других инструментов», скрывая файлы JavaScript от загрузки, когда пользователи тестируют свои сайты с помощью популярных инструментов тестирования производительности. Код использует странный набор запутанных имен для инструментов тестирования, что вызвало у него подозрения.

Варгезе не упомянул в своем твите, что это происходит, когда одна из настроек плагина в разделе Minify > JS настроена на отсрочку JavaScript. Есть две настройки переключателя, но они сбивают с толку.

Первый переключатель позволяет пользователям откладывать выбранные файлы JavaScript. В нем говорится, что файлы будут загружаться асинхронно (не то же самое, что отложить), а затем также говорится, что пользователи должны выбрать первый переключатель, если они хотят исключить сценарии из тестов скорости страницы. Непонятно, как будут загружаться скрипты для пользователя или для тестовых площадок. Исключение — это не то же самое, что отсрочка, поэтому в этом случае пользовательский интерфейс настроек несколько вводит в заблуждение и должен быть более понятным.

Второй вариант радио предназначен для пользователей, которые просто хотят отложить выполнение всего JavaScript. Если выбрать «Отложить с помощью JavaScript (используйте этот метод, если вам требуется поддержка старых браузеров)», он должен делать именно то, что описано в ссылке:

Если установлен атрибут defer , он указывает, что скрипт загружается параллельно с анализом страницы и выполняется после завершения анализа страницы.

Несмотря на то, что пользовательский интерфейс говорит, что он откладывает все файлы, WP-Optimize никогда не загружает JavaScript для сайтов тестирования производительности. Во втором варианте исключение тестовых площадок происходит без разрешения пользователей. Если бы пользователи хотели этого, они бы выбрали предыдущий переключатель и явно указали, какие сценарии следует исключить.

Варгезе упустил некоторые важные детали в своем первоначальном отчете, но он был точным в том смысле, что определенные настройки вводят в заблуждение относительно того, что они на самом деле делают. Он продемонстрировал это в последующем видео, где нет ручного ввода каких-либо сценариев для исключения, и отмечен второй вариант радио.

«Они предоставляют пользователям возможность обманывать инструменты тестирования», — сказал Варгезе. «Кроме того, использование таких имен, как «ighth» для Lighthouse и «tmetr» для GTmetrix, ясно показывает, что они пытаются сделать.

«Большинство пользователей пытаются отключать и включать различные функции, чтобы увидеть, какая из них увеличивает скорость/оценку в инструментах тестирования».

Варгезе утверждает, что нет необходимости делать что-то по-другому для инструментов тестирования и людей, поскольку это может сбить с толку владельцев сайтов. В его утверждении не учитывались важные детали и подразумевалось, что все это скрыто в коде. Это для одной из настроек, но не для другой. Интерфейс подразумевает, что для исключения из тестирования необходимо вводить скрипты вручную, но это тоже заблуждение.

Сегодня WP-Optimize опубликовала публичный ответ на обвинения, но не раскрыла никаких результатов проведенного ими исследования кода. Вместо этого компания процитировала видео, созданное Питером Уилкинсоном из Divi Engine, в котором утверждается, что пользователи должны вручную вводить сценарии, чтобы тестовые сайты исключали их.

Цитируется заключение Уилкинсона о том, что «Джиджо Варгезе использовал обман для продвижения Flying Pages и Flying Press», привлекая внимание общественности к этому вопросу в Twitter.

«На самом деле (из моего исследования) WP-Optimize не «обманывает» инструменты Pagespeed, когда вы устанавливаете или минимизируете свой JavaScript», — сказал Уилкинсон.

«Чтобы «обмануть» инструменты, вам нужно вручную добавить файлы JS, которые вы хотите асинхронно загрузить, в параметр, который четко имеет метку «Используйте это, если у вас есть полностью независимый скрипт или вы хотите исключить скрипты из тестов скорости страницы ( PageSpeed ​​Insights, GTMetrix…)»

Это не тот случай. Самый простой способ проверить — установить плагин, включить «отложить все JavaScript», а затем просмотреть исходный код, чтобы убедиться, что инструменты повышения производительности исключены.

Поскольку публичный ответ WP-Optimize на проблему не содержал ничего из их исследования кода, я снова связался с ними. Их заместитель Венкат Радж не смог ответить, почему другие настройки в плагине автоматически удаляют JS для инструментов тестирования производительности одним щелчком переключателя. Джо Майлз, глава отдела стратегии компании, поделился последней информацией, которую он получил по этому вопросу от Венката Раджа:

«Расширенная настройка, используемая в утверждении, на самом деле полезна, чтобы выяснить, действительно ли основные файлы js/css замедляют работу веб-страницы или нет. Эта функция по умолчанию отключена и включается только опытными пользователями, которые знают, что делают.

«Вы можете использовать эту функцию, если у вас есть полностью независимый скрипт или вы хотите исключить скрипты из тестов скорости страницы (PageSpeed ​​Insights, GTMetrix…)

«Независимые скрипты — это, например, «аналитика» или «пиксельные» скрипты. Они не нужны для работы сайта. ' Используйте это, если у вас есть полностью независимая таблица стилей или вы хотите исключить таблицы стилей из тестов скорости страницы (PageSpeed ​​Insights, GTMetrix…) '

Это относится к первому переключателю. Вторая кнопка не имеет никаких указаний на то, что она отключит все сценарии при использовании инструментов тестирования, и команда WP-Optimize, похоже, не знает, что она доступна одним щелчком переключателя.

Майлз не смог подтвердить, так ли это задумано или это ошибка. Он также не смог объяснить, почему названия популярных сайтов для тестирования были замаскированы в коде, но сказал, что первоначальный разработчик «не работает для нас, поскольку это открытый исходный код, перепрофилированный из других источников».

«Однако мы считаем, что это отвлекает от ложных обвинений, и важно то, что пользовательский интерфейс очень понятен для настроек, поэтому пользователи не обманываются», — сказал Майлз.

Рауль Пейшото, автор Fast Velocity Minify (FVM), плагина, из которого WP-Optimize скопировал код, сказал, что может подтвердить, что этот код был частью FVM, но сказал, что он не использовался таким же образом:

Назначение такого кода на FVM было совершенно другим, чем на WP Optimize, и, кроме того, пользователям требовалось вручную включить эту опцию через wp-admin (по умолчанию она была отключена).

Цель этого кода заключалась в том, чтобы выборочно протестировать влияние новых скриптов или плагинов на производительность и помочь разработчикам решить, следует ли им реорганизовать, удалить или заменить тяжелые плагины или скрипты.

Это существовало на FVM, чтобы отвечать на такие вопросы:
«У меня есть производственная площадка, и моя производительность низкая. Какая была бы производительность, если бы этого плагина просто не было здесь, но пока фактически не удаляя его с сайта для обычных пользователей?»
«Какова была бы производительность, если бы я мог отложить все сценарии или определенные сценарии, которые в настоящее время несовместимы с отсрочкой, прежде чем делать это изменение для всех?»

Официальное объяснение его использования в FVM доступно сегодня утром на форуме поддержки плагина.

«Я предполагаю, что разработчики, нанятые WP Optimize, не понимали, что это делает на FVM или при каких настройках, или, возможно, у них возник соблазн использовать это как хак», — сказал Пейшото.

«Мы также должны тщательно помнить, что в то время еще не было общедоступных показателей веб-жизненных показателей, поэтому использование чего-то подобного могло бы дать лучшие «измеримые» результаты, что дало бы преимущество продукта».

Пьезото сказал, что он «почувствовал себя вынужденным» удалить этот код два года назад из-за того, как часто разработчики злоупотребляли им, обманывая тесты для своих клиентов:

Перенесемся на некоторое время вперед, и я понял, что некоторые разработчики на самом деле использовали это, чтобы обмануть тесты для своих клиентов, поэтому я был вынужден принять решение об удалении этой функции в FVM 3 (уже в конце 2020 г.), что было встречено множество протестов разгневанных разработчиков, когда их клиенты начали жаловаться, что их оценки упали.

В то время я пытался объяснить, что иметь хороший результат — это не то же самое, что иметь хорошие показатели Web Vitals, но в конце концов я отказался от этого, так как некоторых людей больше волновали результаты тестов, чем реальная производительность.

После выпуска FVM 3 я в основном просто поддерживаю его и делаю небольшие исправления ошибок, когда мне сообщают, так как я должен сосредоточиться на других вещах. Я удалил эту функцию и исправил пару ошибок, ожидавшихся в версии 3.2.9, и отправил обновление, так что спасибо, что сообщили мне об этом.

По какой-то причине UpdraftPlus решил объединить этот код с WP-Optimize в 2020 году и, как сообщалось вчера, с тех пор не трогал этот код.

То, что вчера казалось черно-белым вопросом, на самом деле представляет собой более тонкую ситуацию. Реализация WP-Optimize кода FVM плохо документирована в пользовательском интерфейсе и вводит в заблуждение относительно того, как загружаются скрипты. Это может привести к тому, что владельцы сайтов активируют его, не будучи опытными пользователями, и исторически имеет высокий потенциал для злоупотреблений. Когда Варгезе обнаружил его, он разоблачил его в подстрекательской манере, чувствуя уверенность, что обнаружил нарушения из-за того, насколько необъяснимо запутан код. Это усугубило проблему, но положило начало более широкому и важному разговору.

Должны ли пользователи иметь такой простой доступ (два щелчка) к отключению сценариев для инструментов тестирования производительности? Как разработчики из той же отрасли могут лучше сообщать пользователям о потенциальном вреде, который они видят в чужих продуктах? Какие требования к документации по коду должны соблюдать агентства, чтобы предотвратить подобную ситуацию, когда код необходимо исследовать в течение нескольких дней, чтобы выяснить, для чего он предназначен?