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.

The impact

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:

  • ECID service. The corresponding JavaScript must be at the top of the page and it must finish before any other Adobe tool. There is no way around it. We need to have a common ID before we run Audience Manager, Analytics or Target. However, in my experience, the call to dpm.demdex.net tends to be quite fast and has very little impact. Besides, this call does not happen on every page, only on the first page of a visitor, with some refreshes after some time (usually in the range of days).
  • Adobe Target. In my experience, this is where most of the problems with site speed teams happen. Target is quite CPU intensive, both on the server and the browser. For every page, the Target JavaScript needs to make a call to Target servers, Target servers evaluate whether there is an activity and an experience for that page, return the changes to be applied and, finally, Target JavaScript modifies the page accordingly. It is very tempting to move the Target call to the bottom of the page. However, this comes with a very big penalty: flicker. I think everybody agrees that flicker is worse than a slow site.
  • 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.

Compromise

When it comes to site speed, the first word that you should always be ready to use is “compromise”. We have to accept that, by adding Adobe tools, as I have summarised above, we are adding additional load time. If someone tells you to remove all non-functional JavaScript code from the website, it would be like running blind. Yes, you would have a website, but you would not be able to run any data-driven marketing activities. There needs to be a compromise between a fast website and a marketable website. Take all the time needed to explain it to your stakeholders.

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.

Solutions

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,

Do nothing

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.

Look elsewhere

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).
  • Remove unneeded JavaScript or CSS.
  • 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.

Server-side implementation

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

This tends to be one of the typical recommendations. Ideally, all JavaScript should be at the bottom of the page, so that it loads faster and, only when the page is loaded, JavaScript kicks in. However, as I have explained above, the ECID service and Target cannot be moved to the bottom. What you can do is play with the location of the ID sync iframe, loaded by the ECID service in recent versions. Analytics should already be at the bottom of the page.

Asynchronous loading

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:

 

Free Vectors via Vecteezy!

Related Posts