Вчера мы опубликовали обвинения от 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 плохо документирована в пользовательском интерфейсе и вводит в заблуждение относительно того, как загружаются скрипты. Это может привести к тому, что владельцы сайтов активируют его, не будучи опытными пользователями, и исторически имеет высокий потенциал для злоупотреблений. Когда Варгезе обнаружил его, он разоблачил его в подстрекательской манере, чувствуя уверенность, что обнаружил нарушения из-за того, насколько необъяснимо запутан код. Это усугубило проблему, но положило начало более широкому и важному разговору.
Должны ли пользователи иметь такой простой доступ (два щелчка) к отключению сценариев для инструментов тестирования производительности? Как разработчики из той же отрасли могут лучше сообщать пользователям о потенциальном вреде, который они видят в чужих продуктах? Какие требования к документации по коду должны соблюдать агентства, чтобы предотвратить подобную ситуацию, когда код необходимо исследовать в течение нескольких дней, чтобы выяснить, для чего он предназначен?
