WP-Optimizeは、不正行為のパフォーマンスツールの申し立てを否定します
公開: 2022-08-31昨日、私たちは WP-Optimize のメーカーである UpdraftPlus に対する Gijo Varghese からの申し立てを公開しました。 Varghese は、競合企業である FlyingProxy の創設者であり、自分自身を「パフォーマンス愛好家」と名乗っています。 彼は、ユーザーが一般的なパフォーマンス テスト ツールを使用してサイトをテストするときに JavaScript ファイルが読み込まれないようにすることで、このプラグインが「Pagespeed やその他のツールをごまかしている」と非難しました。 このコードは、難読化された一連のテスト ツールの名前を使用しており、これが彼の疑念を引き起こしました。
Varghese は彼のツイートで、Minify > JS の下にあるプラグインの設定の 1 つが JavaScript を延期するように設定されている場合に何が起こるかについて言及することを怠っていました。 ラジオ ボタンの設定は 2 つありますが、わかりにくいです。
最初のラジオ ボタンを使用すると、ユーザーは選択した JavaScript ファイルを延期できます。 ファイルは非同期でロードされる (遅延とは異なります) と書かれており、ページ速度テストからスクリプトを除外したい場合は、ユーザーが最初のラジオ ボタンを選択する必要があるとも書かれています。 ユーザーまたはテスト サイト用にスクリプトがどのように読み込まれるかは明確ではありません。 除外は延期と同じではないため、この場合、設定 UI はやや誤解を招くものであり、より明確にする必要があります。
2 番目のオプションは、単にすべての JavaScript を延期することを検討しているユーザー向けです。 「JavaScript を使用して延期する (古いブラウザーのサポートが必要な場合は、この方法を使用してください)」を選択した場合は、リンクに記載されているとおりに実行する必要があります。
defer属性が設定されている場合は、スクリプトがページの解析と並行してダウンロードされ、ページの解析が終了した後に実行されることを指定します。
UI はすべてのファイルを延期していると言っていますが、WP-Optimize はパフォーマンス テスト サイトの JavaScript をロードしません。 この 2 番目のオプションでは、ユーザーの許可なしにテスト サイトの除外が行われます。 ユーザーがそれを望むなら、前のラジオ ボタンを選択して、除外するスクリプトを明示的に指定していたはずです。
Varghese は、彼の最初のレポートでいくつかの重要な詳細を省略しましたが、特定の設定が実際に何をするかについて誤解を招くという点で正確でした。 彼は、除外するスクリプトを手動で入力する必要がなく、2 番目のラジオ オプションがチェックされているフォローアップ ビデオでこれを示しました。
「彼らは、ユーザーがテスト ツールをだますためのオプションを提供しています」と Varghese 氏は述べています。 「また、Lighthouse の「ighth」や GTmetrix の「tmetr」などの名前を使用することで、彼らが何をしようとしているのかが明確にわかります。
「ほとんどのユーザーは、さまざまな機能を無効にしたり有効にしたりして、テストツールでどの機能が速度/スコアを上げているかを確認しています。」
Varghese 氏は、サイトの所有者を混乱させる可能性があるため、テスト ツールと人間に対して異なることを行う必要はないと主張しています。 彼の主張は重要な詳細を省略しており、これらすべてがコードに隠されていることを暗示しています。 これは設定の 1 つに使用されますが、他の設定には使用されません。 インターフェースは、テストから除外するには手動でスクリプトを入力する必要があることを暗示していますが、これも誤解を招く可能性があります。
WP-Optimize は本日、申し立てに対する公式の回答を公開しましたが、完了したコード調査の結果は明らかにしていません。 代わりに、同社は、Divi Engine の Peter Wilkinson によって作成されたビデオを引用しました。彼は、ユーザーがスクリプトを手動で入力して、テスト サイトがそれらを除外するようにする必要があると主張しています。
Wilkinson は、この問題を Twitter で一般に公開する際に、「Gijo Varghese は、Flying Pages と Flying Press を宣伝するために欺瞞を使用した」と結論付けたと引用されています。
「実際には (私の調査によると) WP-Optimize は、JavaScript をインストールまたは縮小するときに Pagespeed ツールを「ごまかす」ことはありません」と Wilkinson 氏は述べています。
「ツールを「だます」には、非同期ロードする JS ファイルを、「完全に独立したスクリプトがある場合、またはページ速度テストからスクリプトを除外したい場合は、これを使用する」というラベルが明確にある設定に手動で追加する必要があります ( PageSpeed Insights、GTMetrix…)」
これはそうではありません。 テストする最も簡単な方法は、プラグインをインストールし、「すべての JavaScript を延期」をオンにしてから、ソースを表示してパフォーマンス ツールが除外されていることを確認することです。
この問題に対する WP-Optimize の公式の回答には、コード調査からの情報が含まれていなかったため、再度連絡を取りました。 彼らの副リーダーである Venkat Raj は、プラグインの他の設定がラジオ ボタンをクリックするだけでパフォーマンス テスト ツールの JS をサイレント モードで削除する理由について、回答を得ることができませんでした。 同社の戦略責任者である Joe Miles 氏は、Venkat Raj からこの問題について受け取った最後の情報を次のように共有しました。
「主張で使用されている高度な設定は、重要な js/css ファイルが実際に Web ページの速度を低下させているかどうかを確認するのに役立ちます。 この機能はデフォルトで「オフ」になっており、何をしているかを理解している上級ユーザーのみが有効にできます。
「完全に独立したスクリプトがある場合、またはページ速度テスト (PageSpeed Insights、GTMetrix など) からスクリプトを除外したい場合は、この機能を使用できます。
「独立したスクリプトは、たとえば「分析」または「ピクセル」スクリプトです。 ウェブサイトが機能するために必要ではありません。 '完全に独立したスタイルシートがある場合、またはスタイルシートをページ スピード テスト (PageSpeed Insights、GTMetrix など) から除外したい場合に使用します。
これは、最初のラジオ ボタンに適用されます。 2 番目のボタンには、テスト ツールの使用時にすべてのスクリプトをオフにするという表示はありません。また、WP-Optimize のチームは、ラジオ ボタンをクリックするだけで使用できることを認識していないようです。
Miles は、これが意図した動作なのか、それともバグなのかを確認できませんでした。 彼はまた、人気のあるテスト サイトの名前がコードで難読化された理由を説明できませんでしたが、元の開発者は「他の場所から転用されたオープン ソース コードであるため、私たちには適していません」と述べました。
「しかし、これは虚偽の主張から気をそらすものであると考えています。重要なのは、ユーザーがだまされないように、設定の UI が非常に明確であることです」と Miles 氏は述べています。
WP-Optimize がコードをコピーしたプラグインである Fast Velocity Minify (FVM) の作成者である Raul Peixoto 氏は、このコードが FVM の一部であることは確認できるが、同じようには使用されていないと述べています。
FVM でのこのようなコードの目的は、WP Optimize での目的とは完全に異なり、さらに、ユーザーが wp-admin を介してこのオプションを手動で有効にする必要がありました (デフォルトでは無効になっていました)。
このコードの目的は、新しいスクリプトやプラグインのパフォーマンスへの影響を選択的にテストし、開発者が重いプラグインやスクリプトをリファクタリング、削除、または置換する必要があるかどうかを判断できるようにすることでした。
これは、次のような質問に答えるために FVM に存在していました。
「私は生産現場を持っていますが、私のパフォーマンスは低いです。 このプラグインが単にここになくても、通常のユーザーのためにサイトから実際に削除しないと、パフォーマンスはどうなるでしょうか?」
「実際にすべての人に変更を加える前に、すべてのスクリプト、または現在 defer と互換性のない特定のスクリプトを延期できたら、パフォーマンスはどうなるでしょうか?」
FVM での使用に関する公式の説明は、今朝の時点でプラグインのサポート フォーラムにあります。
「WP Optimize に雇われた開発者は、これが FVM やどのような設定で何をしているのかを理解していなかったか、ハッキングとして使用したいと思ったのかもしれません」と Peixoto 氏は述べています。
「また、当時はまだ Web Vitals のメトリクスが公開されていなかったことを注意深く覚えておく必要があります。このようなものを使用すれば、より優れた「測定可能な」結果が得られ、製品の利点が得られたはずです。」
Piexoto 氏は、2 年前にこのコードを削除することを「やむを得ないと感じた」と述べました。これは、クライアントのテストで不正行為を行っていた開発者によって頻繁に悪用されたためです。
少し時間を早送りすると、一部の開発者が実際にこれを使用してクライアントのテストでチートを行っていることに気付きました。そのため、FVM 3 (すでに 2020 年後半) でこの機能を削除するという決定を下さなければならないと感じました。クライアントがスコアが下がったと不平を言い始めたとき、怒っている開発者の多くの抗議。
その時、私は良いスコアを持つことは良い Web Vitals メトリクスを持つことと同じではないことを説明しようとしましたが、実際のパフォーマンスよりもテスト結果を気にする人がいたため、最終的にはそれを断念しました。
FVM 3 のリリース後は、他のことに集中しなければならないので、基本的にはメンテナンスを行い、レポートがあれば小さなバグ修正を行っています。 私はその機能を削除し、バージョン 3.2.9 で保留されていたいくつかのバグを修正し、アップデートをプッシュしました。これを私に紹介してくれてありがとう。
何らかの理由で、UpdraftPlus は 2020 年にこのコードを WP-Optimize にマージすることを選択し、昨日報告されたように、それ以来コードに触れていません.
昨日白黒の問題のように見えたのは、より微妙な状況です。 FVM のコードの WP-Optimize の実装は、UI で十分に文書化されておらず、スクリプトがどのようにロードされるかについて誤解を招きます。 サイトの所有者が上級ユーザーでなくてもアクティブ化する可能性があり、歴史的に悪用される可能性が高くなります. Varghese がそれを発見したとき、コードが不可解に難読化されているため、不正行為を発見したと確信して、扇動的な方法でそれを公開しました。 これにより問題は複雑になりましたが、より広範で重要な会話が始まりました。
ユーザーは、パフォーマンス テスト ツールのスクリプトをオフにするために、この種の簡単なアクセス (2 回のクリック) を行う必要がありますか? 同じ業界の開発者が、他社の製品に見られるユーザーへの潜在的な害について、より適切に伝えるにはどうすればよいでしょうか? コードが何を意図しているかを調べるために数日にわたってコードを調査する必要があるこのような状況を防ぐために、政府機関はどのような種類のコード文書化要件を実装する必要がありますか?