Do tag management systems (TMS) make web sites faster? Yes!
Does this differentiate them? Sometimes, but not a whole lot.
Has a customer ever left one of the major TMSs on the basis of poor site performance (or better performance from a competitor)? Not to my knowledge.
How much should site performance influence my TMS decision? NOT AT ALL (not if you’re comparing the top-tier providers, which I’d expect you are).
It’s incredible to me all of the talk about site performance coming from TMS vendors. The truth is this: among the top 3-4 vendors, the real-world differences in site speed are probably negligible (there are differences, which I’ll talk about below). Each of these vendors has customers raving about site speed improvements, so doesn’t it stand to reason you’ll be happy with any of them, when it comes to this [completely tangential] measure of potential success with a TMS?
If we think for a moment about why we are buying a TMS in the first place, the answer is simple. We are buying one because we have users (whole/segments/individuals), data, and actions/events (those users doing things on our sites or in our apps) that we care to know about and act upon with our marketing tool set. That’s it. Tag management, from the bottom up, is designed to identify when users go places, click things, provide information, etc., and allow us to react to those stimuli with the appropriate responses, including collecting data, delivering chats, surveys, A/B tests, etc. That’s it.
The trouble with this simple stimulus/response formula, historically speaking, is that it involved technical people in different departments. We would say, “When the customer goes to page X or does thing Y, I want tool Z to do A, B and C.” Replicate that ask hundreds or thousands of times, with varying complexity in the individual question and you end up with a mess where IT can never get it all done, get it all right, or stop breaking it as they work on requests from other stakeholders in the organization.
THAT is the problem TMS is solving. Not site speed. TMS solves for the issue where a stakeholder has to rely on an outside department or agency to do work they are uniquely qualified for (picture a pilot relying on a second person to steer the plane, and the only person who knows about flying is the pilot, who has to teach this person as much as possible while in mid-air so they don’t crash). TMS puts power directly in the hands of the stakeholders, so the pilots can steer the planes themselves.
When a business is thinking about investing in, structuring around, and realizing the potential of a TMS, they need to think about how, when, where and why they will use this tool day to day to complete their needed tasks.
Let’s talk about the mechanics involved in site speed
Site speed is a pretty basic concept. Browsers observe a specific set of laws, and maximizing site speed boils down to just a few key things.
The first part of site speed is simply downloading files. Most web pages are made up of dozens or hundreds of files that make up the copy, formatting, fonts, images, functionality, layout, etc. of the page. Certain files have to download sequentially (one must finish before the other can start), while other types of files can download in parallel (two or more files, up to 8 in most browsers, can download at the same time).
The two factors that make up the total time it takes to download these files are latency and size. Latency is kind of like how many times the telephone rings before the other side picks up, and size is the length of the conversation before you hang up.
So when we’re talking about making a site faster, we have a few things we can do:
- Reduce the number of files being downloaded
- Reduce the size of the files being downloaded
- Make the connections (phone ringing) faster to the sources of these files
- Make some files that used to load sequentially load in parallel
You’ll hear a lot of buzzwords like asynchronous thrown around in this space, but many of the sales people talking about these things struggle to explain them, or have the technical expertise to connect the dots in real world terms. The above 4 mechanisms are the ONLY ways we can improve a site’s speed, and the TMS vendors have all cooked up a few recipes that all work pretty well.
For #1 and #2, all TMSs strike a balance on this one. Platforms like Ensighten have a server-side process that hybridizes the approach and allows the platform to only send the necessary files and tags down to the browser, based on the page that visitor is on (or other criteria). This means that it sends a payload that is lighter and hypothetically faster. If Ensighten were to send all tags for the whole site to the browser at once, that file would be much larger, and therefore slower. Tools like Tealium and Adobe’s dynamic tag management take a different approach. Rather than having a server make the determination, these tools deliver a lightweight central set of logic, and then load specific branches from that central logic file based on decisions within that logic (like, again, what page the user is on, what data is present on that page, etc.).
BrightTag, too, has played their cards on these speed factors, and they do so in the form of server to server communication. Rather than loading 10 tags in the browser, they load 1 or 2 or 5, and load the others in the background from their servers. While this seems like the path to the chosen land, the truth is that many tags aren’t compatible with this type of approach, so it’s applicable in some cases and not others.
So in real world terms, what does this mean? How do they score?
Ensighten: Blazingly fast
Tealium: Super duper blindingly fast
Adobe/DTM/(Satellite): Slap your grandma fast
BrightTag: Yowza bo bowza fast
So what about the ideas of #3 and #4, where we improve responsiveness and parallelize these files? On #3, that is why all of the major TMSs serve their files from a CDN, multiple CDNs, or allow you to choose your own architecture or an architecture of choice (like Adobe DTM/Satellite). This ensures the telephone is answered instantly. But that’s not the whole story. Even if the TMS answers its phone quickly, that doesn’t mean your other vendors will, too. Will Google answer the AdWords or DoubleClick phone right away? Will Silverpop, Facebook, Google Analytics, Foresee, Opinionlab, Optimizely, Adobe, and every other vendor you’re delivering through your TMS pick up that phone like a tween expecting a call from their BFF? Probably not.
And that’s the last factor. BrightTag, as we discussed above, moves as many of those calls off the page as possible, while DTM, Tealium and Ensighten manage them directly on the page (which I like because that’s how these things were designed to be used). DTM, for example, has mechanisms that can parallelize these tags or calls, letting the phone ring on 8 calls at a time (or the maximum allowed in a browser), without letting one hold up the other. It and other tools have mechanisms to take calls that are never answered out of the queue, and time the calls to minimize or eliminate the impact on user experience (I have more experience with DTM than others, since I made it, but they all have powerful tools that will probably all converge and not differentiate from one TMS to another soon enough, if they haven’t already).
So where does that net out? The best TMSs are super fast themselves, load tags and tools smartly, and are growing in their capability set. In simple english: practically zero difference. I’m sure sales guys will try to tell a different story, but if you go with simple science, it’s pretty straightforward.
Take a look at the facts and gear yourself and your organization around real-world execution in the tool. Look at TMS as a chair that you and other stakeholders need to sit in practically every day in the future. Buy the chair for its recurring comfort, ergonomics and longevity, not for its tangential benefits that are mostly one-time things.