WP-Optimize niega las acusaciones de trampas en las herramientas de rendimiento

Ayer publicamos acusaciones de Gijo Varghese contra UpdraftPlus, los creadores de WP-Optimize. Varghese es el fundador de FlyingProxy, una empresa competidora, y se identifica a sí mismo como un "entusiasta del rendimiento". Acusó al complemento de "engañar a Pagespeed y otras herramientas" al ocultar los archivos JavaScript para que no se carguen cuando los usuarios prueban sus sitios a través de herramientas populares de prueba de rendimiento. El código utiliza un conjunto extraño de nombres ofuscados para las herramientas de prueba, lo que despertó sus sospechas.

Varghese olvidó mencionar en su tweet que esto es lo que sucede cuando una de las configuraciones del complemento en Minify> JS está configurada para diferir JavaScript. Hay dos configuraciones de botones de opción, pero son confusas.

El primer botón de radio permite a los usuarios diferir los archivos JavaScript seleccionados. Dice que los archivos se cargarán de forma asíncrona (no es lo mismo que aplazar), y luego también dice que los usuarios deben seleccionar el primer botón de opción si quieren excluir los scripts de las pruebas de velocidad de página. No está claro cómo se cargarán los scripts para el usuario o para los sitios de prueba. Excluir no es lo mismo que diferir, por lo que en este caso la interfaz de usuario de configuración es algo engañosa y debería ser más clara.

La segunda opción de radio es para usuarios que simplemente buscan diferir todo JavaScript. Si uno selecciona "Aplazar el uso de JavaScript (Use este método si necesita soporte para navegadores más antiguos)" , debería hacer exactamente lo que se describe en el enlace:

Si se establece el atributo defer , especifica que la secuencia de comandos se descarga en paralelo al análisis de la página y se ejecuta después de que la página haya terminado de analizarse.

Aunque la interfaz de usuario dice que está aplazando todos los archivos, WP-Optimize nunca carga el JavaScript para los sitios de prueba de rendimiento. En esta segunda opción, la exclusión de los sitios de prueba ocurre sin el permiso de los usuarios. Si los usuarios hubieran querido eso, habrían seleccionado el botón de opción anterior e identificado explícitamente qué secuencias de comandos excluir.

Varghese omitió algunos detalles significativos en su informe original, pero fue preciso en el sentido de que ciertas configuraciones son engañosas sobre lo que realmente hacen. Demostró esto en un video de seguimiento donde no hay entrada manual de ninguna secuencia de comandos para excluir y se marca la segunda opción de radio.

“Están brindando una opción para que los usuarios hagan trampa en las herramientas de prueba”, dijo Varghese. “Además, usar nombres como 'ighth' para Lighthouse y 'tmetr' para GTmetrix muestra claramente lo que están tratando de hacer.

"La mayoría de los usuarios intentan deshabilitar y habilitar diferentes funciones para ver cuál aumenta la velocidad/puntuaciones en las herramientas de prueba".

Varghese sostiene que no hay necesidad de hacer las cosas de manera diferente para las herramientas de prueba y los humanos, ya que esto puede resultar confuso para los propietarios de los sitios. Su acusación omitió detalles significativos e insinuó que todo esto está oculto en el código. Es para una de las configuraciones pero no para la otra. La interfaz implica que debe ingresar scripts manualmente para excluirlos de las pruebas, pero esto también es engañoso.

WP-Optimize publicó hoy una respuesta pública a las acusaciones, pero no ha revelado ninguno de los resultados de la investigación del código que completaron. En cambio, la compañía citó un video creado por Peter Wilkinson de Divi Engine, quien afirma que los usuarios deben ingresar manualmente los scripts para que los sitios de prueba los excluyan.

Se cita a Wilkinson concluyendo que "Gijo Varghese ha usado el engaño para promover Flying Pages y Flying Press" al llamar la atención del público sobre este tema en Twitter.

"En realidad (según mi investigación), WP-Optimize no 'engaña' a las herramientas de Pagespeed cuando instala o minimiza su JavaScript", dijo Wilkinson.

"Para 'engañar' a las herramientas, debe agregar manualmente los archivos JS que desea cargar de forma asíncrona a una configuración que claramente tenga la etiqueta 'Use esto si tiene un script completamente independiente o desea excluir los scripts de las pruebas de velocidad de página ( PageSpeed ​​Insights, GTMetrix…)'”

Este no es el caso. La forma más fácil de probar es instalar el complemento, activar "aplazar todo JavaScript" y luego ver la fuente para ver que las herramientas de rendimiento están excluidas.

Dado que la respuesta pública de WP-Optimize al problema no incluía nada de su investigación de código, me comuniqué con ellos nuevamente. Su líder adjunto, Venkat Raj, no estaba disponible para responder por qué otras configuraciones en el complemento eliminan silenciosamente JS para las herramientas de prueba de rendimiento con solo hacer clic en un botón de opción. Joe Miles, jefe de estrategia de la empresa, compartió la última información que recibió sobre el tema de Venkat Raj:

“La configuración avanzada utilizada en la acusación es realmente útil para averiguar si los archivos js/css esenciales realmente están ralentizando la página web o no. Esta función está desactivada de manera predeterminada y solo la habilitan los usuarios avanzados que saben lo que están haciendo.

“Puede usar esta función si tiene un script completamente independiente o desea excluir scripts de las pruebas de velocidad de página (PageSpeed ​​Insights, GTMetrix…)

“Los guiones independientes son, por ejemplo, los guiones de 'análisis' o de 'píxel'. No son necesarios para que el sitio web funcione. ' Úselo si tiene una hoja de estilo completamente independiente o desea excluir las hojas de estilo de las pruebas de velocidad de página (PageSpeed ​​Insights, GTMetrix...) '

Esto se aplica al primer botón de opción. El segundo botón no tiene ninguna indicación de que apagará todas las secuencias de comandos al usar herramientas de prueba, ni el equipo de WP-Optimize parece saber que está disponible con el clic de un botón de opción.

Miles no pudo confirmar si así es como se pretende que funcione o si se trata de un error. Tampoco pudo explicar por qué los nombres de los sitios de prueba populares estaban ofuscados en el código, pero dijo que el desarrollador original "no funciona para nosotros, ya que es un código fuente abierto reutilizado desde otro lugar".

“Sin embargo, creemos que esto es una distracción de las acusaciones falsas, y lo que importa es que la interfaz de usuario es muy clara para las configuraciones, por lo que los usuarios no se dejan engañar”, dijo Miles.

Raúl Peixoto, autor de Fast Velocity Minify (FVM), el complemento desde el cual WP-Optimize copió el código, dijo que puede confirmar que este código era parte de FVM pero dijo que no se usó de la misma manera:

El propósito de dicho código en FVM era completamente diferente al de WP Optimize y, además, requería que los usuarios habilitaran manualmente esta opción a través de wp-admin (estaba deshabilitada de forma predeterminada).

El propósito de ese código era probar selectivamente el impacto de los nuevos scripts o complementos en el rendimiento y ayudar a los desarrolladores a decidir si deberían refactorizar, eliminar o reemplazar los complementos o scripts pesados.

Esto existía en FVM para responder preguntas como estas:
“Tengo un sitio de producción y mi rendimiento es bajo. ¿Cuál sería el rendimiento si este complemento simplemente no estuviera aquí, pero sin eliminarlo del sitio para los usuarios regulares todavía?
"¿Cuál sería el rendimiento si pudiera diferir todos los guiones, o guiones específicos que actualmente no son compatibles con diferir, antes de hacer ese cambio para todos?"

Una explicación oficial sobre su uso en FVM está disponible en el foro de soporte del complemento a partir de esta mañana.

“Supongo que los desarrolladores contratados por WP Optimize no entendieron qué estaba haciendo esto en FVM o bajo qué configuraciones, o tal vez, se sintieron tentados de usarlo como un truco”, dijo Peixoto.

"También debemos recordar cuidadosamente que en ese momento, todavía no había métricas web vitals disponibles públicamente, por lo que usar algo como esto habría arrojado mejores resultados 'medibles', ofreciendo así una ventaja de producto".

Piexoto dijo que "se sintió obligado" a eliminar este código hace dos años debido a la frecuencia con la que los desarrolladores abusaban de él y hacían trampa en las pruebas para sus clientes:

Avance rápido un tiempo y me di cuenta de que algunos desarrolladores en realidad estaban usando esto para hacer trampa en las pruebas de sus clientes, por lo que me sentí obligado a tomar la decisión en FVM 3 (ya a fines de 2020) para eliminar esta función, que se cumplió con un muchas protestas de desarrolladores enojados cuando sus clientes comenzaron a quejarse de que sus puntajes bajaron.

En ese momento traté de explicar que tener una buena puntuación no era lo mismo que tener buenas métricas web vitals, pero finalmente me rendí, ya que a algunas personas les importaban más los resultados de las pruebas que el rendimiento real.

Después del lanzamiento de FVM 3, básicamente solo lo mantengo y corrijo pequeños errores cuando se informa, ya que tengo que concentrarme en otras cosas. Eliminé esa función y solucioné un par de errores que estaban pendientes en la versión 3.2.9 y publiqué una actualización, así que gracias por remitirme esto.

Por alguna razón, UpdraftPlus decidió fusionar este código con WP-Optimize en 2020 y, como se informó ayer, no ha tocado el código desde entonces.

Lo que ayer parecía ser un problema en blanco y negro es una situación más matizada. La implementación de WP-Optimize del código de FVM está mal documentada en la interfaz de usuario y es engañosa sobre cómo se cargan los scripts. Puede llevar a los propietarios de sitios a activarlo sin ser usuarios avanzados e históricamente tiene un alto potencial de abuso. Cuando Varghese lo descubrió, lo expuso de una manera incendiaria, sintiéndose seguro de que había encontrado un delito debido a lo inexplicablemente ofuscado que está el código. Esto agravó el problema pero inició una conversación más amplia e importante.

¿Deberían los usuarios tener este tipo de acceso fácil (dos clics) para desactivar los scripts de las herramientas de prueba de rendimiento? ¿Cómo pueden los desarrolladores de la misma industria comunicar mejor los daños potenciales a los usuarios que ven en los productos de otros? ¿Qué tipo de requisitos de documentación del código deberían implementar las agencias para evitar una situación como esta en la que el código debe investigarse a lo largo de varios días para averiguar qué pretende hacer?