El asombroso caso del código que ralentizaba mi web más de 5 segundos – No imaginas lo que pasó después…

¿Te acuerdas que ayer te contaba que descubrí lo de WooCommerce Analytics buscando solución a otro problema? Pues hoy te contaré de qué iba la cosa.

El misterioso caso de 4 webs iguales pero una era más lenta que el resto

Resulta que tengo varias webs asociadas al blog que son donde ofrezco los distintos servicios WordPress. Pues todas tienen el mismo tema (Divi, sí, lo uso mucho y me encanta), prácticamente el mismo diseño unificado y casi los mismos plugins, pero una de ellas destacaba por ser excesivamente lenta, la web de servicios de consultoría y desarrollo web.

He de decirte que en alguna de las otras, como en la de mantenimientos WordPress, hay incluso más plugins y más consumidores de recursos, pero todas estas webs suelen cargar en torno a 1 segundo, a veces incluso menos, pero no la de servicios, que tardaba más de 6 segundos en cargar, algo que sin ser terrible no es mi ideal, todo sea dicho.

Huelga decir que en todas aplico las mismas estrategias de optimización, así que por ahí no había diferencias.

Pero lo más sorprendente es que la cosa no era de siempre, había sido algo repentino, a partir de una fecha concreta.

Es más, si te fijas en la captura los tiempos de carga se habían disparado pero la web pesaba lo mismo y generaba la misma cantidad de peticiones, raro raro.

Anteriormente a esa fecha los tiempos de carga eran muy similares al resto de webs, incluso a la de cursos WordPress, que además de WooCommerce tiene todo un LMS, Sensei, y varios plugins más para ofrecer una academia online a mis alumnos.

Llamando al C.S.I.

Pues bien, revisando las webs en detalle caí en la cuenta de que la única diferencia entre ambas era que en la web de servicios tengo activo JetPack para usar su módulo de formularios, pues me facilitaba mucho las cosas.

Luego, un repaso al informe de rendimiento en GTMetrix, me confirmó que todo el problema venía de un JavaScript que cargaba JetPack, y el solito generaba hasta 2 instancias, cada una de más de 1 segundo de tiempo de carga.

Sin saber aún de la existencia de WooCommerce Analytics, investigué un poco y encontré en el GitHub de JetPack un informe de este problema, en el que se daba una solución para evitarlo.

Y es que parece ser que el dichoso JavaScript, de nombre s-202026.js, perteneciente a las estadísticas de JetPack, incluso había provocado errores 500 en algunas webs.

¡Espera! ¿He dicho «perteneciente a las estadísticas de JetPack»? En este momento no me di cuenta de ello, pero luego si caí, más abajo te cuento.

Bueno, llegado a este punto probé el siguiente código, añadido a mi plugin de personalizaciones (también funciona en el archivo functions.php del tema activo):

/**
 * Fix the path of Woo script.
 *
 * @param string $url The URL to the file.
 * @param string $min_path The minified path.
 * @param string $non_min_path The non-minified path.
 */
function jetpackcom_fix_woo_script_path( $url, $min_path, $non_min_path ) {
	if ( wp_startswith( $min_path, 'https://stats.wp.com/s-' ) ) {
		return $min_path;
	}
	return $url;
}
add_filter( 'jetpack_get_file_for_environment', 'jetpackcom_fix_woo_script_path', 10, 3 );

Y el cambio de rendimiento fue bastante bueno, no constante, pero sí se notaba que bajaban los tiempos, aunque a veces el mismo JavaScript daba errores en alguna de sus instancias de carga, pero sobre todo, seguía cargándose.

Así que, aunque algo había mejorado el rendimiento, estaba aún lejos de mis estándares, sobre todo del más importante: comprender por qué pasan las cosas que pasan.

JetPack y la madre que lo parió

Así que, a lo tonto, se me encendió la lucecita y, repasando la página de GitHub caí en que esto venía de un módulo llamado WooCommerce Analytics, que ni sabía que existía porque en ninguna actualización se había pedido consentimiento alguno para esta recogida de datos, y esto te lo puedo asegurar porque JetPack lo traduzco a cada versión.

Lo más gordo del asunto es que a ti, como propietario de una tienda online no te aporta nada, ese módulo solo sirve para enviar información de tu Ecommerce, de tus productos, comportamiento de los usuarios y procesos de compra, a Automattic.

Dicho y hecho, miré en la instalación de JetPack, y al no encontrar el módulo en los ajustes «normales» (visibles más bien) busqué en la lista completa de módulos ocultos de JetPack, y ahí estaba el bicho.

Pero, me extrañaba haber leído que era algo que tenía que ver con las estadísticas de JetPack, que nunca activo, pero bueno, me puse a ello y desactivé el maldito módulo.

Dicho y hecho, probé la carga de la página, y a simple vista ya se notaba la diferencia, así que volví a analizarla y el cambio era sorprendente…

Haciendo una comparación con los resultados de justo antes de desactivar el módulo de WooCommerce Analytics se hacía más patente aún.

Y, por supuesto, ni rastro ya del JavaScript s-202026.js de las estadísticas de JetPack.

Repasando los cambios realizados, había pasado la web de cargar en más de 6 segundos a menos de 1 segundo.

¿Qué aprendo yo de esto?

No se tú, pero yo he aprendido algunas cosas de esta experiencia:

  1. Tengo que repasar todas las webs en las que tenga JetPack para desactivar cagando leches el módulo de WooCommerce Analytics. A mi no me aporta nada, solo sirve para enviar datos a Automattic.
  2. Nunca actualizar ningún plugin sin comprobar si la actualización ha afectado de algún modo a los tiempos de carga de la web. Es algo que hacía de vez en cuando pero ahora lo hago siempre, nada más actualizar.
  3. No volver a fiarme de JetPack, y por extensión de Automattic, y su no cumplido compromiso con la privacidad.
  4. Se confirma una vez más que el compromiso de las empresas no europeas con la privacidad de los usuarios es mero postureo, a la que te descuidas te meten en un lío legal con los visitantes y clientes de tu web, recopilando datos sin informarte, y en consecuencia sin que tú puedas informar a los usuarios de TU web.

Nota: Si quieres saber las implicaciones de privacidad del módulo WooCommerce Analytics de JetPack te recomiendo leer este otro artículo que publiqué.

VALORA Y COMPARTE ESTE ARTÍCULO PARA MEJORAR LA CALIDAD DEL BLOG…
(17 votos, promedio: 4.8)

¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!

3 comentarios en “El asombroso caso del código que ralentizaba mi web más de 5 segundos – No imaginas lo que pasó después…”

  1. José Ramón Padrón

    Menos mal que te fijaste y te gusta analizar. Mucha gente habría pasado de largo. Yo le habría echado la culpa al hosting 😉

  2. Interesante, lo que tenías a favor es que podías comparar varias webs casi iguales, yo tambien intento usar siempre el mismo tema y los mismos plugins en todos los sitios web.
    Saludos Fernando.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

 

Ir arriba Ir al contenido