Site Speed and Adobe Tools
11 Aug 2019 » Opinion
In a recent project I worked on, the client set a team up to analyse the site speed of the website. This resulted in some clashes between them and the Adobe team. Both sides had their own arguments and it was difficult to progress. Today I want to give you my point of view and tips of what you can do if you find yourself in the same situation.
It would be foolish to think that, by adding any Adobe tool, the site speed will not be affected. The only case where this could almost be true is with Adobe Analytics without the ECID service. In any other case, the impact will be noticeable, even if it is just a few milliseconds. Let me summarise what this impact is:
- Adobe Analytics. The AppMeasurement library usually makes a single call. Since it is at the bottom of the page and it is only an image request, the time it takes tends to be negligible.
Audience Manager. Originally, when we only had DIL code, it was a similar case as Analytics: it run at the bottom of the page. However, now it has been split in 2:
- The ECID service takes care of the ID syncs. Although they happen in an iframe, it will still add an additional delay.
- With server-side forwarding, the collection of the data happens in the Analytics call. In other words, data collection has no additional impact on load time.
You will have noticed that I have not given any times, as this will depend a lot on your setup. However, maximum times should be in the order of hundreds of milliseconds.
Since my blog is about Adobe, I am not including the competition. However, all digital marketing tools will add a delay.
Perceived load time
One of the worst decisions you can make is to measure site speed and take the total load time as the metric to optimise. Although this value can be useful, it is not, by far, the most important. What really matters is what the user perceives, not what the technology does.
In this context, you may come across the concept of first meaningful paint (FMP). FMP is the time it takes for a page’s primary content to appear on the screen. This is a more accurate measure. Think about it from the user perspective. What people hate is to wait on a blank screen. As long as the user sees progress, he tends to wait more patiently. Finally, when a user sees the page loaded (not necessarily in full) and functional, he will not care whether the code is doing additional things in the background. This is what is meant by perceived load time, as it is a perception. If you need to optimise something, reducing the FMP should be your aim.
Since I am not an expert in this matter, I will not get into more details, but you get the idea.
You can even think of this issue in monetary terms. If you need hard evidence, you should evaluate the following amounts:
- Additional revenue you generate thanks to your digital marketing activities.
- Lost revenue due to the increased site speed, in turn due to the Adobe tools.
- Cost to apply all needed optimisations (see below for potential solutions; spoiler alert: they do not come cheap).
I know these numbers are not easy to get, but if you manage to get them, I am pretty sure the revenue generated by your digital marketing activities will be more than the lost revenue due to a slower website. It could also well be that the cost to apply some optimisations is too high for your company or you do not have the resources to do it.
I am sure this is what you are really looking in this post. Here you have some potential solutions to apply to the Adobe Tools to increase your site speed,
Yes, I am not joking or crazy. If you have shown that the site speed does not affect too much your website but, on the contrary, the Adobe Tools are bringing a lot of value, why change? Or, if the costs of the optimisations are too high, you are definitely not going to do them.
In fact, in many cases, if I were involved in these conversations, this would be my recommendation.
In my experience, the delay added by all Adobe tools combined to the FMP is below 1s. So, if you only optimise the Adobe tools, you will only improve by a few hundred milliseconds. I encourage you to look at the website as a whole, to see what other areas could be improved. Optimisations in these other areas of the web could result in seconds of improvement.
Here you have some ideas:
- Image size: you would be surprised at how often people put huge images instead of scaling them to a minimum required size.
- Servers: Do you have enough servers to support the load? Is there enough RAM or bandwidth? Is the data compressed?
- Use content delivery networks (CDNs).
- Change or optimise the content management system (CMS).
- Client networks: if the client is on a slow network, like mobile networks, there is nothing you can do to improve the speed.
I have already written a lot on this topic. In summary, move as much as you can from the client to the server, when it comes to the Adobe tools. But beware of the limitations and the cost. The only client I am have worked with, which tried to go server-side, ditched the implementation, and kept the client-side code.
Move calls down
Another recommendation that you will always hear. DTM does not support it, but Launch does. However, this solution requires some changes from a synchronous loading:
- Target. Only at.js supports it. You also will need to add a pre-hiding snippet to avoid flicker. This snippet has to be added in the page code and before Launch.
- Analytics. You cannot use the bottom of the page rule; it has to be either on DOM ready or on page load.
Accelerated Mobile Pages
This only applies to mobile websites. A couple of things you should know:
- Analytics. Check these great articles from my esteemed colleague Jan Exner:
Free Vectors via Vecteezy!