Your ads performance is your performance

When the performance of your website is out of your hands.

I wrote this story while I worked with performance in Ekstra Bladet Udvikling/Development, which maintains one of the biggest websites in Denmark. I’ve previously written about how ads are a major influence on performance — and how you can measure it:

Before that article, I wrote about our problems with not being able to measure the performance of the banner ads on our website:

This article is sort of an elaboration on that subject and is meant to further illustrate that if you are running/maintaining a website with ads and want to work with performance, you need to address those ads.

In our office we have various graphs (dating back two weeks) from SpeedCurve displayed on a television screen. Today, as I was walking past the screen, I noticed something weird in the front page graphs:

Notice those fluctuations. Up and down and up and down and up and down. On a website, you want stable (and good) performance. These graphs indicate that we do not have that.

On the top graph you can see that our ‘Start Render’ and ‘SpeedIndex’ (which says something about how fast the first viewport is loaded) values are pretty stable. But the ‘Visually Complete’…oh my.

Then the television screen switched to the ‘Third party’ view in SpeedCurve:

The blue graph is the amount of requests our code/technology does and how many kilobytes that take up. The brown graph is the same thing, but for third party technology/code. In our case, this is mostly ads, since we are looking at measurements of our front page — and not articles where video players, embedded stuff and so on might appear.

You immediately notice that there might be some correlation between the various graphs. What better way to find out (and illustrate) by pasting the various graphs on top of each other:

Now look at the same image, the same graphs, with lines indicating the biggest drops in third party content requests (and content sizes):

It’s obvious that the number of requests on our website for a very large part rely on how many requests there are in the banner ads on our site.

Some banner ads are heavy, others are light. And since we have programmatic ads on our site, some are found quite fast while others won’t be found and rendered after a small, but crucial, period of time. This is essentially what these graphs are showing.

This is technology and ways of doing web development that we in the Development department have no influence on.

(There are still changes in the measured performance (look at the ‘Rendering’ graph on top) where the performance varies without it having something to do with the ads. Some of these might stem from smaller drops in third party requests, though.)

What to do, what to do?

While there aren’t a lot of things we can do right now, there are some things we can do in the long term — and the medium term.

We can, and do, continue the great cooperation we have with our Sales department, the Back Office team in particular. They have various products they use to monitor ad performance (which is obviously important for them as well) and they can reach out to where these ads are coming from, call out those ads that are performing poorly and hopefully, we will surely but safely change the world of ad performance for the better.

My guess is that most of the advertisers as well don’t want to see their names and brands on the ads that are slowing a particular website down — not to mention the increased risk of not being seen by the users if you ad is to slow to load.

We all want better performance but to get there we have to reverse several years of “Let’s do this and that because we can”. Poor performance doesn’t happen out of malice. It happens because of neglect.

I strongly recommend that you watch this video on the subject of ads and performance: