Ensighten's Approach to Caching

Ultimately Ensighten is designed to optimize on multiple fronts, notably caching, security, and scalability.

Bootstrap.js

As with all tag management systems we begin with the core Bootstrap.js, which has a cache life of 5 minutes. After 5 minutes, a request will be made to the Ensighten servers to determine if the file has change and download a new copy or continue to pull from cache for the next five minutes (this is optimized on the server side, rather than having a hard-set 5 minute cache).

serverComponent

The next piece of the TMS flow is the serverComponent for which we make an asynchronous call to our serverComponent that is dynamically generated for each page request. This is an optimal approach over fully-client side for several reason, two key items are: cachability and user experience.

If all the logic for every tag you have implemented is placed in the core file of your system any change to a tag requires an update of that file and any tags that have changed. This means that if you have a 100KB base file and are actively tagging your site you will be continuously requiring your users to download that file over and over severely impacting the page load time.

Also by moving the logic to a secondary call we’ve actually optimized the page for user experience; placing tag logic in the client side means that every condition in the system has to execute synchronously before the page will render, rather than making a single asynchronous call to a server that will handle the logic for you. This means if you have 100 different conditions (not uncommon for large enterprise sites) all of that logic has to be executed and then asynchronous calls initiated to the appropriate files, rather than a single asynchronous call being initiated in our case.

Tagging Files

The last piece touched on is that our tagging files are optimized by condition rather than tag, which means we aren’t loading a single file per tag but one file with many tags to decrease the number of calls made. This is particularly important for large enterprise websites because browsers have limits to the maximum number of calls allowed to be made at any given time as well as maximum number of requests to a single server allowed.

For example, Internet Explorer 8 only allows 6 concurrent connections per server at any given time, this means that if you are running 10 tags on a page and each is stored in a separate file (as some of our competitors do) only six are allowed to download at a time, making the others wait until one completes and a connection becomes available. Also, each file is cached for its lifetime; we use a hash of the code in the file to name it.  This means that any change to the code results in a change to the filename, which prevents the browser from accidentally pulling a cached version of a tag from cache.