WP-Optimize는 성능 도구의 부정 행위 혐의를 부인합니다.

어제 우리는 WP-Optimize의 제작자인 UpdraftPlus에 대한 Gijo Varghese의 주장을 발표했습니다. Varghese는 경쟁 회사인 FlyingProxy의 창립자이며 자신을 "성과 매니아"라고 밝힙니다. 그는 사용자가 인기 있는 성능 테스트 도구를 통해 사이트를 테스트할 때 JavaScript 파일이 로드되지 않도록 숨김으로써 "속임수 Pagespeed 및 기타 도구"의 플러그인을 비난했습니다. 코드는 테스트 도구에 대해 난독화된 이상한 이름 세트를 사용하여 의심을 불러일으켰습니다.

Varghese는 자신의 트윗에서 Minify > JS 아래의 플러그인 설정 중 하나가 JavaScript를 연기하도록 설정되어 있을 때 발생한다는 언급을 무시했습니다. 두 개의 라디오 버튼 설정이 있지만 혼란스럽습니다.

첫 번째 라디오 버튼을 사용하면 선택한 JavaScript 파일을 연기할 수 있습니다. 파일이 비동기식으로 로드된다고(지연과 동일하지 않음) 사용자가 페이지 속도 테스트에서 스크립트를 제외하려면 첫 번째 라디오 버튼을 선택해야 한다고 말합니다. 사용자 또는 테스트 사이트에 대해 스크립트가 로드되는 방법은 명확하지 않습니다. 제외하는 것은 연기하는 것과 같지 않으므로 이 경우 설정 UI가 다소 오해의 소지가 있고 더 명확해야 합니다.

두 번째 라디오 옵션은 단순히 모든 JavaScript를 연기하려는 사용자를 위한 것입니다. "JavaScript 사용 연기(이전 브라우저에 대한 지원이 필요한 경우 이 방법 사용)" 을 선택하면 링크에 설명된 대로 정확하게 수행해야 합니다.

defer 속성이 설정되면 스크립트가 페이지 구문 분석과 병렬로 다운로드되고 페이지 구문 분석이 완료된 후 실행되도록 지정합니다.

UI가 모든 파일을 연기한다고 표시하더라도 WP-Optimize는 성능 테스트 사이트용 JavaScript를 로드하지 않습니다. 이 두 번째 옵션에서는 테스트 사이트의 제외가 사용자의 허가 없이 발생합니다. 사용자가 원했다면 이전 라디오 버튼을 선택하고 제외할 스크립트를 명시적으로 식별했을 것입니다.

Varghese는 원래 보고서에서 몇 가지 중요한 세부 사항을 생략했지만 특정 설정이 실제로 수행하는 작업에 대해 오해의 소지가 있다는 점에서 정확했습니다. 그는 제외할 스크립트를 수동으로 입력하지 않고 두 번째 라디오 옵션이 선택되어 있는 후속 비디오에서 이를 시연했습니다.

Varghese는 "사용자가 테스트 도구를 속일 수 있는 옵션을 제공하고 있습니다. “또한 Lighthouse에 'ighth', GTmetrix에 'tmetr'과 같은 이름을 사용하는 것은 그들이 무엇을 하려는지 명확하게 보여줍니다.

"대부분의 사용자는 테스트 도구에서 속도/점수를 높이는 기능을 확인하기 위해 다양한 기능을 비활성화 및 활성화하려고 합니다."

Varghese는 사이트 소유자에게 혼란을 줄 수 있으므로 도구와 사람을 테스트하기 위해 다르게 할 필요가 없다고 주장합니다. 그의 주장은 중요한 세부 사항을 생략했으며 이 모든 것이 코드에 숨겨져 있음을 암시했습니다. 설정 중 하나를 위한 것이지만 다른 것은 아닙니다. 인터페이스는 테스트에서 제외하려면 스크립트를 수동으로 입력해야 함을 의미하지만 이것은 또한 오해의 소지가 있습니다.

WP-Optimize는 오늘 혐의에 대한 공개 답변을 게시했지만 완료한 코드 조사 결과는 공개하지 않았습니다. 대신 회사는 Divi Engine의 Peter Wilkinson이 만든 비디오를 인용했는데, 그는 테스트 사이트에서 스크립트를 제외하려면 사용자가 수동으로 스크립트를 입력해야 한다고 주장합니다.

Wilkinson은 "Gijo Varghese는 Flying Pages와 Flying Press를 홍보하기 위해 속임수를 사용했다"고 결론지어 이 문제를 Twitter에서 대중의 관심을 끌었습니다.

Wilkinson은 "실제로 (내 연구에서) WP-Optimize는 JavaScript를 설치하거나 축소할 때 Pagespeed 도구를 '치트'하지 않습니다."라고 말했습니다.

"도구를 '치트'하려면 '완전히 독립적인 스크립트가 있거나 페이지 속도 테스트( PageSpeed ​​Insights, GTMetrix…)'”

그렇지 않다. 테스트하는 가장 쉬운 방법은 플러그인을 설치하고 "모든 JavaScript 연기"를 켠 다음 소스를 보고 성능 도구가 제외되었는지 확인하는 것입니다.

문제에 대한 WP-Optimize의 공개 응답에는 코드 조사 결과가 포함되어 있지 않았기 때문에 다시 연락했습니다. 그들의 대리인인 Venkat Raj는 플러그인의 다른 설정이 라디오 버튼을 클릭하여 성능 테스트 도구에 대해 자동으로 JS를 제거하는 이유에 대해 대답할 수 없었습니다. 회사의 전략 책임자인 Joe Miles는 이 문제에 대해 Venkat Raj로부터 받은 마지막 정보를 공유했습니다.

"고발에 사용된 고급 설정은 필수 js/css 파일이 실제로 웹 페이지 속도를 늦추는지 여부를 알아내는 데 실제로 유용합니다. 이 기능은 기본적으로 '해제'되어 있으며 자신이 하는 일을 알고 있는 고급 사용자만 사용할 수 있습니다.

"완전히 독립적인 스크립트가 있거나 페이지 속도 테스트(PageSpeed ​​Insights, GTMetrix...)에서 스크립트를 제외하려는 경우 이 기능을 사용할 수 있습니다.

“독립적인 스크립트는 예를 들어 '분석' 또는 '픽셀' 스크립트입니다. 웹 사이트가 작동하는 데 필요하지 않습니다. ' 완전히 독립적인 스타일시트가 있거나 페이지 속도 테스트(PageSpeed ​​Insights, GTMetrix…)에서 스타일시트를 제외하려는 경우 사용하십시오. '

이것은 첫 번째 라디오 버튼에 적용됩니다. 두 번째 버튼에는 테스트 도구를 사용할 때 모든 스크립트가 꺼진다는 표시가 없으며 WP-Optimize 팀은 라디오 버튼을 클릭하여 사용할 수 있다는 것을 인식하지 못하는 것 같습니다.

Miles는 이것이 작동하도록 의도된 것인지 또는 버그인지 확인할 수 없습니다. 그는 또한 인기 있는 테스트 사이트의 이름이 코드에서 난독화된 이유를 설명할 수 없었지만 원래 개발자는 "다른 곳에서 용도가 변경된 오픈 소스 코드이므로 우리에게 적합하지 않습니다"라고 말했습니다.

"그러나 우리는 이것이 잘못된 주장으로부터 주의를 산만하게 하고, 중요한 것은 UI가 설정에 대해 매우 명확하므로 사용자가 속지 않는다는 것입니다."라고 Miles가 말했습니다.

WP-Optimize가 코드를 복사한 플러그인인 FVM(Fast Velocity Minify)의 작성자인 Raul Peixoto는 이 코드가 FVM의 일부임을 확인할 수 있지만 동일한 방식으로 사용되지는 않았다고 말했습니다.

FVM에서 이러한 코드의 목적은 WP Optimize의 것과 완전히 다르며 사용자가 wp-admin을 통해 수동으로 이 옵션을 활성화해야 했습니다(기본적으로 비활성화되어 있음).

이 코드의 목적은 성능에 대한 새 스크립트 또는 플러그인의 영향을 선택적으로 테스트하고 개발자가 무거운 플러그인 또는 스크립트를 리팩토링, 제거 또는 교체해야 하는지 여부를 결정하는 데 도움이 되는 것입니다.

이것은 다음과 같은 질문에 답하기 위해 FVM에 존재했습니다.
“생산 현장이 있는데 성과가 낮습니다. 이 플러그인이 여기에 있지 않고 일반 사용자를 위해 사이트에서 실제로 제거되지 않은 경우 성능은 어떻습니까?”
"모든 스크립트 또는 현재 defer와 호환되지 않는 특정 스크립트를 모든 사람에 대해 실제로 변경하기 전에 연기할 수 있다면 성능은 어떻습니까?"

FVM에서의 사용에 대한 공식 설명은 오늘 아침 플러그인의 지원 포럼에서 확인할 수 있습니다.

Peixoto는 "WP Optimize에 고용된 개발자는 이것이 FVM에서 또는 어떤 설정에서 수행되는지 이해하지 못했거나 해킹으로 사용하고 싶은 유혹을 느꼈을 것"이라고 말했습니다.

"또한 그 당시에는 공개적으로 사용할 수 있는 웹 바이탈 메트릭이 없었으므로 이와 같은 것을 사용하면 더 나은 '측정 가능한' 결과를 얻을 수 있으므로 제품 이점을 제공할 수 있다는 점을 주의 깊게 기억해야 합니다."

Piexoto는 2년 전에 클라이언트 테스트에서 부정 행위를 하는 개발자들이 얼마나 자주 이 코드를 남용했는지 때문에 이 코드를 제거해야 한다고 "강요를 느꼈다"고 말했습니다.

시간이 좀 더 지나면 일부 개발자가 실제로 이를 사용하여 클라이언트 테스트를 속이는 것을 깨달았습니다. 그래서 저는 FVM 3(이미 2020년 후반)에서 이 기능을 제거하기로 결정해야 한다고 느꼈습니다. 고객이 점수가 떨어졌다고 불평하기 시작했을 때 화난 개발자들의 많은 항의가 있었습니다.

나는 그 당시에 좋은 점수를 갖는 것이 좋은 웹 바이탈 메트릭을 갖는 것과 같지 않다는 것을 설명하려고 노력했지만 일부 사람들은 실제 성능보다 테스트 결과에 더 관심이 있기 때문에 결국 그것을 포기했습니다.

FVM 3 릴리스 이후에는 기본적으로 유지 관리하고 보고되면 작은 버그 수정을 하고 있습니다. 다른 일에 집중해야 하기 때문입니다. 해당 기능을 제거하고 버전 3.2.9에서 보류 중이었던 몇 가지 버그를 수정하고 업데이트를 푸시했는데, 이 부분을 언급해 주셔서 감사합니다.

어떤 이유에서든 UpdraftPlus는 2020년에 이 코드를 WP-Optimize에 병합하기로 결정했으며 어제 보고된 대로 그 이후로 코드를 건드리지 않았습니다.

어제 흑백 문제로 보였던 것이 더 미묘한 상황입니다. WP-Optimize의 FVM 코드 구현은 UI에 제대로 문서화되어 있지 않으며 스크립트가 로드되는 방식에 대해 오해의 소지가 있습니다. 이는 사이트 소유자가 고급 사용자 없이 활성화하도록 유도할 수 있으며 역사적으로 악용 가능성이 높습니다. Varghese가 그것을 발견했을 때, 그는 코드가 설명할 수 없을 정도로 난독화되었기 때문에 자신이 잘못을 발견했다고 확신하면서 선동적인 방식으로 그것을 폭로했습니다. 이것은 문제를 복잡하게 만들었지만 더 광범위하고 중요한 대화를 시작했습니다.

사용자가 성능 테스트 도구에 대한 스크립트를 끄기 위해 이처럼 쉽게 액세스(두 번 클릭)해야 합니까? 같은 업계의 개발자가 다른 제품에서 볼 수 있는 잠재적인 피해에 대해 어떻게 더 잘 전달할 수 있습니까? 코드가 의도한 바를 알아내기 위해 며칠 동안 코드를 조사해야 하는 이와 같은 상황을 방지하기 위해 기관은 어떤 종류의 코드 문서 요구 사항을 구현해야 합니까?