google analytics

Optimiza el Leverage Browser Caching para Google Analytics

Si eres de los que te preocupa el WPO, probablemente te hayas encontrado con un aviso de un problema de rendimiento si utilizas google analytics. Algo del estilo:

leverage browser caching google analytics

¿Qué significa esto? Nada grave, simplemente que estamos cargando un script de terceros (Google Analytics) y que este recurso tiene declarado un tiempo de expiración de 2 horas. Y para pasar este filtro, debería ser al menos de 2 semanas.

Si tienes una estrategia para cachear los recursos estáticos en el navegador del cliente, sabrás que no podemos configurar el tiempo de expiración de los recursos cargados por terceros.

Por lo tanto, si un visitante entra en tu web, y repite visita en un tiempo superior a dos horas, se le volverá a descargar el JS de analytics, que pesa 43,4 KB. Y cualquier descarga, cualquier transferencia de datos… tarda, y hace que tu web vaya más lenta.

Tienes más información sobre cómo especificar la caché de navegador en un artículo que escribí hace un par de años.

¿Cómo optimizamos el tiempo de expiración de recursos de terceros?

Como te he dicho antes, no podemos optimizar el tiempo de expiración declarado en un recurso que se carga en nuestra web desde un tercero. Por lo tanto, si queremos optimizarlo, tendremos que descargarlo en nuestro servidor, y servirlo desde allí, para así tener control sobre él.

Esto tiene un inconveniente claro, y es que una vez en nuestro servidor, perdemos las posibles actualizaciones, mejoras, corrección de errores y/o vulnerabilidades… que haga un tercero. De hecho, si el propio Google establece un tiempo de expiración tan corto para el script de analytics, probablemente sea porque sufre muchos cambios.

Y no vamos a estar descargando en nuestro servidor el archivo cada dos por tres para tenerlo actualizado…

Por lo tanto, lo ideal sería montar un «sistema» que automatice la descarga de este recurso en nuestro servidor, y que lo sirvamos nosotros estableciendo un tiempo de expiración más elevado y pasando el corte de los tests de WPO.

Y a ello vamos, la idea es tener un cron que nos ejecute una petición donde obtendremos el recurso del servidor de google analytics y lo almacene en una carpeta local de nuestro servidor.

<?php

register_activation_hook( __FILE__, 'ga_register_cron' );

function ga_register_cron() {
    // Si no existe el evento, lo registramos
    if ( ! wp_next_scheduled( 'ga_daily_cron' ) ) {
        wp_schedule_event( current_time( 'timestamp' ), 'daily', 'ga_daily_cron' );
    }
}

function update_ga_js() {
    $remoteFile    = 'https://www.google-analytics.com/analytics.js';
    $localFilePath = ABSPATH . 'ga/';
    $localFile     = $localFilePath . 'local-analytics.js';

    if ( ! file_exists( $localFile ) ) {
        wp_mkdir_p( $localFilePath );
    }

    if ( ! is_writable( $localFile ) ) {
        $stat  = @ stat( dirname( $localFile ) );
        $perms = $stat['mode'] & 0007777;
        $perms = $perms & 0000666;
        chmod( $localFile, $perms );
        clearstatcache();
    }

    $response = wp_safe_remote_get(
        $remoteFile,
        array(
            'timeout'  => 10,
            'stream'   => true,
            'filename' => $localFile,
        )
    );
}
add_action( 'ga_daily_cron', 'update_ga_js' );

Lo primero es registrar el cron que, en nuestro caso, diariamente actualizará el script de Google Analytics. El registro del cron ha de realizarse una única vez.

En este ejemplo con fines didácticos, vamos a realizarlo bajo el evento que se dispara al activar un plugin. Si lo haces así, recuerda desactivar el cron al desactivar el plugin.

Registramos el evento ga_daily_cron que se ejecutará una vez al día. A continuación hookeamos un método (update_ga_js) a este evento.

En este método tenemos por un lado la URL del recurso remoto que queremos descargar, y establecemos la ruta específica donde guardarlo en nuestro sitio.

Lo primero es comprobar si existe el fichero, si no existe creamos la carpeta. A continuación comprobamos los permisos, y si no tiene los permisos de escritura necesarios, se los establecemos para poder almacenar el archivo allí.

Por último obtenemos el fichero con wp_safe_remote_get (básicamente es una petición CURL utilizando la HTTP API de WordPress) y lo almacenamos en la ruta que hemos definido. Así de simple.

¿Cómo cargamos el script de analytics desde «local»?

Sólo nos queda un último paso, y es modificar el código que google analytics nos facilita para que cargue el script desde nuestro servidor local en lugar de hacerlo desde el servidor de Google:

<script>
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','https://YOURDOMAIN.COM/ga/local-analytics.js','ga');

  ga('create', 'UA-XXXXXXX-X', 'auto');
  ga('send', 'pageview');
  ga('set', 'anonymizeIp', true);
</script>

Si… hay plugins que «te lo hacen», pero como siempre a tu parecer queda el saber el cómo o el porqué o el saber hacer click en un botón…

¿Te ha resultado útil esta información? 🍺

Si este post te ha resuelto un problema, invítame a un café o a una cerveza. Con este pequeño gesto me animas a seguir escribiendo.

Comentarios

Deja un comentario

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

  • El fin del tratamiento es únicamente la moderación de comentarios para evitar spam
  • La legitimación es tu consentimiento al comentar
  • No se comunicará ningún dato a terceros salvo por obligación legal
  • Tienes derecho al acceso, rectificación y eliminación de los comentarios