Como impedir que tus herramientas de analítica perjudiquen el rendimiento de tu web
Un Delay en JavaScript podría considerarse como una forma "hack" de realizar una carga diferida para mejorar el WPO.
La diferencia principal de esta práctica con otras como el Defer y el Async es la posición de ejecución. Aunque el artículo de carga diferida es más completo al respecto, para que se pueda entender bien el Delay de JavaScript, es necesario repasar de manera básica estos conceptos. Esto no solo te permitirá aplicar esta técnica de manera efectiva, sino también entender por qué funciona.
Entonces para introducirlo, el delay en JS lo que hará será descargar y ejecutar el JavaScript como normalmente, pero este no funcionará hasta que termine el tiempo designado. En ocasiones, además de la descarga, afecta la propia carga y ejecución de un elemento, ya que realiza cambios en el DOM y en el usuario que pueden afectar al rendimiento. Entonces lo que consigue el Delay es ejecutarse, pero no hacer la función que puede consumir muchos recursos, ya que el Script permanecerá "inactivo" hasta que pase el tiempo designado. Así que vamos a revisar esos básicos.
Aclaración, cuando me refiero a Script y JavaScript me refiero al mismo concepto.
El comportamiento normal de un archivo .js cuando lo llamamos desde el HTML es que se descarga el archivo, mientras se descarga el archivo no se descarga nada más de la web y cuando se ha descargado el archivo, este se ejecuta y continua la descarga normal de la web con el resto de elementos que componen dicha página.
Cuando aplicamos un async o una carga asíncrona, lo que le estamos diciendo al navegador, es que no se ejecute dicho archivo de JavaScript hasta que este no se ha descargado por completo en segundo plano. Es decir, la diferencia con el comportamiento normal, es que mientras se está descargando, se aprovecha dicho tiempo para seguir descargando el resto de elementos de la web. Y entonces cuando se ha terminado de descargar el archivo de JavaScript, se para momentáneamente la descarga del resto de elementos y el script se ejecuta y realiza la acción para la que está programado.
El riesgo del Async, es que no siempre se ejecutará en el mismo punto, ya que dependiendo del usuario, la conexión y otros factores, se terminará de descargar en un punto u otro.
En el caso del Defer, hace una descarga en segundo plano, al igual que lo hace el async. Pero con la diferencia de que no se ejecuta al descargar en el navegador del usuario el script. Sino que espera a que se descarguen el resto de elementos web, y se ejecuta al final, cuando se ha descargado todo, por lo cual, su comportamiento es más predecible que con el async.
Lo que se puede observar con este tipo de prácticas, es que lo que se altera es el momento en el que se ejecuta el JavaScript en la descarga.
En el ejemplo de este código insertado, se puede apreciar que dos Scripts iguales funcionan de forma distinta. En este caso, como estamos haciendo un innerHTML (que es cambiar el código que hay dentro de la etiqueta HTML que hayamos seleccionado), se puede apreciar que sólo funciona el JavaScript cuando está debajo de la etiqueta HTML. Quiere decir, que tiene que haberse leído antes dicha etiqueta, para poder funcionar. Es por este motivo que el primer div no funciona y el segundo sí. A pesar de que sea el mismo código.
Es por este motivo, que muchos SEO se han cargado históricamente efectos como la barra de navegación, sliders y otros cuando han utilizado algún plugin de WPO sin conocimientos básicos de JavaScript. Al intentar comprimir todos los archivos y unificarlos en uno solo.
Para poder optimizar esto de una forma adecuada, hay que entender qué se está realizando.
Así que como se puede apreciar, el orden afecta en el comportamiento de la página. Y de hecho, hay Scripts que por su funcionamiento, les ocurre exactamente lo contrario, pues necesitan cargar al inicio. Esto suele ocurrir por ejemplo con las propias herramientas de analítica, que necesitan cargar cuanto antes para comprobar el comportamiento del usuario, y de hecho en sus instrucciones se especifica una posición que es al inicio de la página.
Para entender cómo se comporta el JavaScript, os expongo un pequeño experimento que mejorará vuestra comprensión acerca del mismo.
Cabe decir que la mayor parte de veces, los Scripts deben posicionarse después del elemento en cuestión para poder funcionar. Pero hay excepciones como funciones y ciertas librerías. Como no me quiero perder en detalles, prefiero explicar lo básico.
Para entender el experimento, he creado 2 Scripts con el mismo comportamiento que arrojan mensajes distintos (para distinguirlos) y así comprobar de forma simple el comportamiento de este lenguaje de programación en un navegador moderno.
A igualdad de condiciones, el comportamiento de JavaScript, dicta que un script que se encuentra más abajo, es el que "gana" o funciona.
Con Async el comportamiento dependerá de lo que tarde en descargar el archivo, así que directamente realizo la prueba con un Defer.
Como se puede observar, aunque el Script esté arriba, por la forma de actuar del Defer, es como si el elemento estuviese abajo aunque se haya descargado antes:
Aplicar un delay por javascript, es un "gamechanger", es decir una forma de darle la vuelta.
Advertencia: En promedio Google renderiza la página y hace un Snapshot del DOM en 5 segundos, quiere decir que si se pone un retraso posterior, es posible que Google no renderice dicha acción. ¿Positivo o negativo? Se puede utilizar a nuestro favor, pero con cuidado.
Lo que consiste la carga pospuesta por tiempo, es que el script se descargue y se ejecute donde tenga que hacerlo. Pero aunque haya descargado y ejecutado, no funcione hasta cierto tiempo. Esto no afectará en absoluto a la descarga. Pero si que a la carga, ya que si habrá ejecutado, pero no comenzará a funcionar a partir de cierto tiempo. Por lo que (dependiendo lógicamente del archivo y funcionalidad), podemos conseguir un Hack, donde sin alterar donde debe funcionar, se retrase esa acción un poco.
Expongo distintos ejemplos:
Aquí podemos comprobar, que aunque tardase más en ejecutarse, no consigue la prioridad que si que tendría con el Defer, o posiblemente con el Async. Por lo que sí que afecta al tiempo que tarda en estar activo dicho Script, pero no al comportamiento de la página una vez se ejecuta:
No obstante, podemos observar que si le aplicamos el defer, o lo ponemos en el footer, no afecta al comportamiento (sigue retrasando la ejecución 5 segundos).
Aquí está el código del delay por si quieres experimentar:
function saludar() {
var currentTime = new Date().getTime();
var delay = startTime + 5000;
if (currentTime >= delay) {
alert("¡Hola desde el script en el head!");
}
}
var startTime = new Date().getTime();
Yo por ejemplo lo tengo así con Clarity:
<script>
document.addEventListener('DOMContentLoaded', function() {
// Verifica el User-Agent para excluir Google/Bing bots
var userAgent = navigator.userAgent;
if (/Google|yahoo/i.test(userAgent)) {
console.warn('Microsoft Clarity tracking está deshabilitado para bots de Google/yahoo.');
return;}
// Verifica si el script ya se ejecutó antes usando localStorage
var clarityScriptLoaded = localStorage.getItem('clarityScriptLoaded');
var delay = clarityScriptLoaded ? 0 : 5000;
setTimeout(function() {
// Crear y configurar el elemento script
var script = document.createElement('script');
script.type = 'text/javascript';
script.text = `
(function(c,l,a,r,i,t,y){
c[a]=c[a]||function(){(c[a].q=c[a].q||[]).push(arguments)};
t=l.createElement(r);t.async=1;t.src="https://www.clarity.ms/tag/"+i;
y=l.getElementsByTagName(r)[0];y.parentNode.insertBefore(t,y);
})(window, document, "clarity", "script", "TU-ID");
`;
document.head.appendChild(script);
// Establece una bandera en localStorage para indicar que el script ya se cargó
if (!clarityScriptLoaded) {
localStorage.setItem('clarityScriptLoaded', 'true');
}
}, delay);
});
</script>
Además le pongo un condicional de aceptación de Cookies por como lo tengo instalado:
if (isset($_COOKIE['accept_cookies']))
Sin necesidad de abusar de esta práctica, es simplemente una técnica cuando toca ir al detalle de un proyecto, donde se pueden rascar un poquito de rendimiento "sin afectar" del todo a la funcionalidad.
Cabe decir, que si se realiza esta práctica por ejemplo con un Script de Analítica, existe el contra de que se falsearán las métricas del porcentaje de Rebote, algo especialmente importante si se trabaja el SEA (mal llamado SEM) en una web.
Para concluir, estas prácticas son interesantes y pueden ser socorridas para casos específicos. Pero no valen para todas las webs. Además nunca este tipo de implementaciones debe sacrificar la experiencia del usuario.
Te falta mi máster. Accede a una formación avanzada que te permitirá aplicar e implementar SEO en cualquier tipo de WEB
¡Accede al Máster de SEO Técnico!