WP-Optimize, Hile Performans Araçları İddialarını Reddetti

Dün, WP-Optimize'ın yapımcıları UpdraftPlus'a karşı Gijo Varghese'nin iddialarını yayınladık. Varghese, rakip bir şirket olan FlyingProxy'nin kurucusudur ve kendisini bir "performans tutkunu" olarak tanımlar. Eklentiyi, kullanıcılar sitelerini popüler performans test araçlarıyla test ederken JavaScript dosyalarının yüklenmesini engelleyerek "Pagespeed ve diğer araçları aldatmakla" suçladı. Kod, test araçları için şüphesini çeken garip bir dizi karışık isim kullanıyor.

Varghese, tweet'inde, eklentinin Minify > JS altındaki ayarlarından biri JavaScript'i ertelemeye ayarlandığında bunun olacağını söylemeyi ihmal etti. İki radyo düğmesi ayarı vardır ancak bunlar kafa karıştırıcıdır.

İlk radyo düğmesi, kullanıcıların seçilen JavaScript dosyalarını ertelemesine olanak tanır. Dosyaların eşzamansız olarak yükleneceğini söylüyor (erteleme ile aynı değil) ve ardından, komut dosyalarını sayfa hızı testlerinden çıkarmak istiyorlarsa kullanıcıların ilk radyo düğmesini seçmeleri gerektiğini söylüyor. Kullanıcı veya test siteleri için scriptlerin nasıl yükleneceği belli değil. Hariç tutma, erteleme ile aynı şey değildir, bu nedenle bu durumda ayarlar kullanıcı arayüzü biraz yanıltıcıdır ve daha net olmalıdır.

İkinci radyo seçeneği, tüm JavaScript'i ertelemek isteyen kullanıcılar içindir. “JavaScript kullanarak ertele (eski tarayıcılar için desteğe ihtiyacınız varsa bu yöntemi kullanın)” seçilirse, tam olarak bağlantıda açıklanan şeyi yapmalıdır:

defer özniteliği ayarlanmışsa, komut dosyasının sayfanın ayrıştırılmasına paralel olarak indirildiğini ve sayfanın ayrıştırılması tamamlandıktan sonra yürütüldüğünü belirtir.

Kullanıcı arayüzü tüm dosyaları ertelediğini söylese de, WP-Optimize, performans testi siteleri için JavaScript'i asla yüklemez. Bu ikinci seçenekte, test sitelerinin hariç tutulması, kullanıcıların izni olmadan gerçekleşir. Kullanıcılar bunu isteseydi, önceki radyo düğmesini seçer ve hangi komut dosyalarının hariç tutulacağını açıkça belirlerdi.

Varghese, orijinal raporunda bazı önemli ayrıntıları dışarıda bıraktı, ancak bazı ayarların gerçekte ne yaptıkları konusunda yanıltıcı olması doğruydu. Bunu, hariç tutulacak herhangi bir komut dosyasının manuel girişinin olmadığı ve ikinci radyo seçeneğinin işaretlendiği bir takip videosunda gösterdi.

Varghese, "Kullanıcılara test araçlarını aldatma seçeneği sunuyorlar" dedi. “Ayrıca Lighthouse için 'ighth' ve GTmetrix için 'tmetr' gibi isimler kullanmak, ne yapmaya çalıştıklarını açıkça gösteriyor.

"Kullanıcıların çoğu, test araçlarında hangisinin hızı/puanları artırdığını görmek için farklı özellikleri devre dışı bırakmayı ve etkinleştirmeyi deniyor."

Varghese, site sahipleri için kafa karıştırıcı olabileceğinden, araçları ve insanları test etmek için farklı şeyler yapmaya gerek olmadığını iddia ediyor. İddiası önemli ayrıntıları dışarıda bıraktı ve tüm bunların kodda gizli olduğunu ima etti. Bu ayarlardan biri içindir, diğeri için değildir. Arayüz, testten hariç tutmak için komut dosyalarını manuel olarak girmeniz gerektiğini ima eder, ancak bu aynı zamanda yanıltıcıdır.

WP-Optimize, bugün iddialara yönelik bir kamu yanıtı yayınladı, ancak tamamladıkları kod soruşturmasının sonuçlarını açıklamadı. Bunun yerine şirket, Divi Engine'den Peter Wilkinson tarafından oluşturulan ve kullanıcıların test sitelerinin bunları hariç tutması için komut dosyalarını manuel olarak girmesi gerektiğini iddia eden bir videoya atıfta bulundu.

Wilkinson, bu konuyu Twitter'da kamuoyunun dikkatine sunarken "Gijo Varghese, Flying Pages ve Flying Press'i tanıtmak için aldatma kullandı" sonucuna varıyor.

Wilkinson, "Gerçekte (benim araştırmamdan) WP-Optimize, JavaScript'inizi kurarken veya küçülttüğünüzde Pagespeed araçlarını 'hile yapmaz', dedi.

“Araçları 'dolandırmak' için, asenkron yüklemek istediğiniz JS dosyalarını, açıkça 'Tamamen bağımsız bir komut dosyanız varsa veya komut dosyalarını sayfa hızı testlerinden hariç tutmak istiyorsanız bunu kullanın' etiketine sahip bir ayara manuel olarak eklemeniz gerekir ( PageSpeed ​​Insights, GTMetrix…)'”

Durum bu değil. Test etmenin en kolay yolu, eklentiyi yüklemek, "tüm JavaScript'i ertele"yi açmak ve ardından performans araçlarının hariç tutulduğunu görmek için kaynağı görüntülemektir.

WP-Optimize'ın soruna verdiği genel yanıt, kod araştırmalarından hiçbir şey içermediğinden, onlarla tekrar iletişime geçtim. Yardımcı lider Venkat Raj, eklentideki diğer ayarların neden bir radyo düğmesine tıklama ile performans testi araçları için JS'yi sessizce kaldırdığını yanıtlayamadı. Şirketin strateji başkanı Joe Miles, konu hakkında Venkat Raj'dan aldığı son bilgileri paylaştı:

“İddiada kullanılan gelişmiş ayar, temel js/css dosyalarının web sayfasını gerçekten yavaşlatıp yavaşlatmadığını öğrenmek için gerçekten kullanışlı. Bu özellik varsayılan olarak 'kapalı'dır ve yalnızca ne yaptığını bilen ileri düzey kullanıcılar tarafından etkinleştirilir.

“Tamamen bağımsız bir komut dosyanız varsa veya komut dosyalarını sayfa hızı testlerinden çıkarmak istiyorsanız bu özelliği kullanabilirsiniz (PageSpeed ​​Insights, GTMetrix…)

“Bağımsız komut dosyaları örneğin 'analitik' veya 'piksel' komut dosyalarıdır. Web sitesinin çalışması için gerekli değildir. ' Tamamen bağımsız bir stil sayfanız varsa veya stil sayfalarını sayfa hızı testlerinden hariç tutmak istiyorsanız bunu kullanın (PageSpeed ​​Insights, GTMetrix…) '

Bu, ilk radyo düğmesi için geçerlidir. İkinci düğme, test araçlarını kullanırken tüm komut dosyalarını kapatacağına dair herhangi bir belirtiye sahip değil - WP-Optimize ekibi, bir radyo düğmesine tıklandığında kullanılabilir olduğunun farkında değil gibi görünüyor.

Miles, bunun böyle olup olmadığını veya bir hata olup olmadığını teyit edemedi. Ayrıca popüler test sitelerinin adlarının kodda neden gizlendiğini de açıklayamadı, ancak orijinal geliştiricinin "başka bir yerden yeniden tasarlanmış açık kaynak kodu olduğu için bizim için çalışmadığını" söyledi.

Miles, "Ancak, bunun yanlış iddialardan dikkati dağıtan bir şey olduğuna inanıyoruz ve önemli olan, kullanıcı arayüzünün ayarlar için çok net olması, bu nedenle kullanıcıların aldatılmaması" dedi.

WP-Optimize'ın kodu kopyaladığı eklenti olan Fast Velocity Minify'ın (FVM) yazarı Raul Peixoto, bu kodun FVM'nin bir parçası olduğunu doğrulayabileceğini ancak aynı şekilde kullanılmadığını söyledi:

FVM'deki bu kodun amacı WP Optimize'dakinden tamamen farklıydı ve ayrıca kullanıcıların bu seçeneği wp-admin aracılığıyla manuel olarak etkinleştirmesi gerekiyordu (varsayılan olarak devre dışıydı).

Bu kodun amacı, yeni komut dosyalarının veya eklentilerin performans üzerindeki etkisini seçici olarak test etmek ve geliştiricilerin ağır eklentileri veya komut dosyalarını yeniden düzenlemeye, kaldırmaya veya değiştirmeye karar vermelerine yardımcı olmaktı.

Bu, aşağıdaki gibi soruları yanıtlamak için FVM'de vardı:
“Bir üretim yerim var ve performansım düşük. Bu eklenti sadece burada olmasaydı, ancak henüz normal kullanıcılar için siteden gerçekten kaldırmadan performans ne olurdu?”
"Tüm komut dosyalarını veya şu anda erteleme ile uyumlu olmayan belirli komut dosyalarını gerçekten bu değişikliği herkes için yapmadan önce erteleyebilseydim performans ne olurdu?"

FVM'de kullanımına ilişkin resmi bir açıklama, bu sabahtan itibaren eklentinin destek forumunda mevcuttur.

Peixoto, "WP Optimize tarafından işe alınan geliştiricilerin, bunun FVM'de veya hangi ayarlar altında ne yaptığını anlamadığını veya belki de onu bir hack olarak kullanmaya cazip gelmiş olabileceğini düşünüyorum." Dedi.

"Ayrıca, o zaman, hala kamuya açık hiçbir web vitals metriği olmadığını dikkatlice hatırlamalıyız, bu nedenle böyle bir şey kullanmak daha iyi 'ölçülebilir' sonuçlar verecek ve böylece bir ürün avantajı sunacaktır."

Piexoto, müşterileri için testlerde kopya çeken geliştiriciler tarafından ne sıklıkta suistimal edildiği için bu kodu iki yıl önce kaldırmaya "kendini mecbur hissettiğini" söyledi:

Bir süre ileri sardım ve bazı geliştiricilerin bunu müşterileri için yapılan testlerde hile yapmak için kullandığını fark ettim, bu yüzden FVM 3'te (zaten 2020'nin sonlarında) bu özelliği kaldırmak için bir karar vermek zorunda hissettim. Müşterileri puanlarının düştüğünden şikayet etmeye başladığında öfkeli geliştiricilerin birçok protestosu.

O zaman, iyi bir puana sahip olmanın iyi web vitals metriklerine sahip olmakla aynı şey olmadığını açıklamaya çalıştım, ancak bazı insanlar gerçek performanstan çok test sonuçlarını önemsediği için sonunda bundan vazgeçtim.

FVM 3'ün piyasaya sürülmesinden sonra, başka şeylere odaklanmam gerektiğinden, temelde sadece onu koruyorum ve bildirildiğinde küçük hata düzeltmeleri yapıyorum. Bu işlevi kaldırdım ve 3.2.9 sürümünde bekleyen birkaç hatayı düzelttim ve bir güncelleme gönderdim, bu yüzden bunu bana bildirdiğiniz için teşekkür ederim.

Hangi nedenle olursa olsun, UpdraftPlus 2020'de bu kodu WP-Optimize ile birleştirmeyi seçti ve dün bildirildiği gibi o zamandan beri koda dokunmadı.

Dün siyah beyaz bir mesele gibi görünen şey, daha nüanslı bir durum. WP-Optimize'ın FVM kodunu uygulaması, kullanıcı arayüzünde yetersiz şekilde belgelenmiştir ve komut dosyalarının nasıl yüklendiği konusunda yanıltıcıdır. Site sahiplerini ileri düzey kullanıcılar olmadan siteyi etkinleştirmeye yönlendirebilir ve tarihsel olarak yüksek bir kötüye kullanım potansiyeline sahiptir. Varghese bunu keşfettiğinde, onu kışkırtıcı bir şekilde ifşa etti ve kodun ne kadar açıklanamaz bir şekilde karıştırıldığı için yanlış bir şey bulduğundan emindi. Bu, sorunu daha da karmaşık hale getirdi, ancak daha geniş ve önemli bir konuşma başlattı.

Kullanıcılar, performans testi araçları için komut dosyalarını kapatmak için bu tür kolay erişime (iki tıklama) sahip olmalı mı? Aynı sektördeki geliştiriciler, diğerlerinin ürünlerinde gördükleri potansiyel zararlar hakkında kullanıcılara nasıl daha iyi iletişim kurabilir? Kodun ne amaçladığını bulmak için günler boyunca araştırılması gereken böyle bir durumu önlemek için ajanslar ne tür kod dokümantasyon gereklilikleri uygulamalıdır?