A Publisher's Guide To Latency
A Publisher's Guide To Latency
Yet Another Stupid Latency Article
Welcome
Disclaimer : this article is very pub-focused, and relatively technical (but I try to make it easy to understand). Might be a skipper if you’re interested in “industry wide stuff” – but still worth knowing what publishers care about for the curious. It’s also not written for engineers, and I probably get some of the tech stuff mildly wrong – but hopefully it sparks debate and gives folks language to make better choices in their monetization.
Latency is the biggest boogie man in pub side ad tech. Seriously. Bigger than identity, bigger than SPO, bigger than MFA. But latency – oh boy – if you tell a publisher you’re adding significant latency to the page, it doesn’t matter how much you’re willing to pay them – you’re getting the boot.
And this is understandable. In publishing, the core product is still a consumable media that has to be ostensibly consumed by an ostensible human. Interrupting that, or interfering with that, is highly problematic – publishers don’t want the users they have left coming to their sites to leave and go back to indulging their unhealthy tik tok habit.
But where there is fear there is opportunity – and a number of pundits, influencers, and less-than-responsible sales tactics have hijacked the latency boogeyman to their own end to sell products and shore up their moats. The goal of today’s article is to create a framework for publishers to understand latency, ask the right questions, and get a little bit closer to something remotely resembling actionable strategies for dealing with the relationship between your tech and your page.
New Latency Definitions
Let’s get started with definitions – what is latency? Dictionaries are worthless with web slang, so I’ll give it a shot – Latency means time. High latency, or large amounts of latency, imply that something is taking a long time – low amounts of latency, or low latency, means that things happen quickly. Google kind of corroborates this – the top search result is
Computer and OS latency is the combined delay between an input or command and the desired output. Contributors to increased computer latency include insufficient data buffers and mismatches in data speed between the microprocessor and input/output (I/O) devices.
This sounds about right – like when a video game has bad “lag” between input and action, or when a user asks a website to load (!) and it takes time for it to actually come up.
In the interest of the topic at hand, this computing concept actually applies in two ways to ad tech and publishing. These ways are not independent, but still need to be distinct :
Website Load Latency – how much time between when a user requests the website to do some kind of thing on there and the website actually loads/does the thing
Ad Load Latency – how much time between when the ads on a website start to load and when the ads render on the page
These two ways, for most people, are collapsed into one. If you look up latency moaning on linkedin, 9 times out of 10 they’re not distinguishing between the two, when they really, really, really should be. This is because their impacts are very different. One impacts user experience, and all the things that are downstream of that, like SEO and time on site, and the other impacts ad delivery, and all of the things that are downstream of that, like ad revenue and ad performance.
Website Load Latency
Website load latency is the primary topic in most articles about latency. The genesis for people caring about it is twofold – 1. There’s a supposition that there’s a relationship between user experience and revenue (ha ha ha), and 2. Organic search depends on sites loading quickly. We’re going to park #1 and not address it in this article, as I will address it in the future, but #2 really deserves examination.
The notion that your website’s latency affects your Search Engine Optimization isn’t conjecture – it comes straight from Google. Google even provides a framework by which they assess how well websites load, something called Core Web Vitals, documented at length here
https://support.google.com/webmasters/answer/9205520?hl=en
In their description, they make CWV sound like a panacea – with case studies like this :
When a site meets the Core Web Vitals thresholds, research showed that users were 24% less likely to abandon page load.
With each 100ms reduction in Largest Contentful Paint (LCP), web conversion rate for Farfetch increased by 1.3%.
Reducing Cumulative Layout Shift (CLS) by 0.2 led Yahoo! JAPAN to a 15% increase in page views per session, 13% longer session durations, and a 1.72 percentage point decrease in bounce rate.
Netzwelt improved Core Web Vitals and saw advertising revenues increase by 18% and page views by 27%.
Reducing CLS from 1.65 to 0 significantly uplifted domain rankings globally for redBus.
What publisher wouldn’t read these things and these google invented acronyms and make CWV their Bible? And there’s definitely something to it – a website that doesn’t load creates an unpleasant experience for users, and that should increase bounce rate.
The components of CWV (at the time of writing this article) are as follows :
Largest Contentful Paint (LCP): measures loading performance. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading. Layman’s terms : How fast do all of the parts of your site load?
First Input Delay (FID): measures interactivity. To provide a good user experience, pages should have a FID of 100 milliseconds or less. Layman’s terms : If I click a button, does stuff happen?
Cumulative Layout Shift (CLS): measures visual stability. To provide a good user experience, pages should maintain a CLS of 0.1. or less. Layman’s terms : How much does your site wiggle around after the initial load?
And another one called INP on the way that we don’t need to cover.
LCP / FID / CLS
So let’s start with layman’s terms for LCP – “how fast does your website load” – and things that break this will also probably affect FID and INP. This metric is built around content elements, so with this metric google is really concerned with the content of your website itself. This means that any advertising technology, or any technology in general, that slows down the rendering of your content will hurt your LCP score. For me, in my experience with websites, a few things jump to mind that are ad-tech relevant here :
Slow Delivery of stuff – don’t work with crappy hosting companies, compress whatever you can, your vendors that your website lives in are not a place to cheap out
Blocking javascript (this also impacts FID) – in the world of Ad Tech, all javascript from ad tech providers should be async. Nobody should be loading synchronous javascript on your page. What are sync and Async you ask? See below
Too much crappy javascript – a lot of crappy javascript will block up the main thread, which you can think of as the “brain” that’s making all the code on the page execute. This is what you get when you pay php developers on fiverr to add “more stuff” to your website.
Loading too much stuff – this is when you try to load too many things at once, or from too many different people.
All of these things are considerations when it comes to optimizing for LCP, FID, and INP as well. These are all “high level things” that will slow down your website in general. However, it is important to note, that all technologies contribute to these issues, not just ad tech. You can absolutely tank your CWV without any ad tech on the page at all by committing any of the above 4 sins in infinite creative ways.
Sync vs Async in Gareth’s horribly butchered non technical lingo
Synchronous javascript is javascript that has to execute in a particular synchronous order – ie. sync JS has to execute in order for things after it to execute. If it breaks, it breaks all the things after it. Old school header bidding was sync FYI
Async javascript can execute simultaneously, if it breaks it will not break the things loading after it.
As I prepare my inbox for a barrage of hate mail from developers, let’s try to finish this section.
CLS
Cumulative layout shift is a relatively self explanatory one – how much is stuff shifting around in your layouts when users are interacting with the page. I don’t need to dive too deep into this one – feel free to read in crazy detail – https://web.dev/articles/cls – but TLDR, don’t let your engineers make your pages wiggle when humans click buttons or let your ad tech vendors move your shit. Wiggling is bad, it makes people click things accidentally and get angry.
Ad Tech Questions
Now that we have an incredibly cursory understanding of CWV, let’s talk about it in the context of Ad Tech.
In summary, we don’t want vendors to unnecessarily damage our CWV score. Some damage is inevitable, as they are additional code on the page, but you can absolutely ask them questions that should minimize the damage or at least make you aware of it. Please find my question guide below :
Can I load you asynchronously / iframed / do you do anything that could block the page executing? They should let you run them on a friendly iframe, or they should guarantee they’re not going to block the page. That or they’ll just lie to you, but then you can get angry and ask for money. CWV bullet points 1+2
How many network requests do you expect to require? Tech providers need to call out to their servers or others to do stuff – but how many is an important question. Expect that the answer will sometimes/almost always be “we don’t know.”
Tech Providers – ie. utilities – should be able to tell you this on a per session basis. This will help you gauge the impact on CWV bullet point 4
Ad Tech Monetizers are going to need to call lots of people, with some of them outside of their control. They should however be able to tell you how many people they’re directly invoking. Is it 2? Is it 50? They need to be able to give you an answer, even though the direct invoking number will inevitably be lower than the final number as all of the programmatic hullabaloo kicks in. I could write an article about this one alone, maybe I will.
Are you going to add things to my page and move stuff around? This is for CLS – we can’t have people expanding ads up and down, popping things in and out of the page (*ahem* outstreamvideo providers), and ads moving divs up or down (I’m looking at you all “rich” media). These things will all hurt your CLS score, and make your pages look crummy. Don’t let people do this.
All of this being said, at the end of the day, how much you actually care about these things is up to you. Are you super dependent on organic traffic from Google specifically? A 10 point hit to your CWV score might materially damage your revenue. Are you a website with tons of direct and subscription traffic that doesn’t so badly depend on Google? Maybe you don’t care, and you reach out and grab that beautiful outstream butterfly.
This is not a one size fits all thing. Whether or not you care about page latency I actually don’t believe is an absolute – because there is one truth that’s hard to fight, and that’s that additional ad tech providers both add latency and make more money. The question is how much money is enough to justify a bunch of additional code and page-load – and that’s up to each publisher to answer.
What is Ad Stack Latency?
The second type of latency (and the one that I frankly know better) is ad stack latency. Ad stack latency, for the purposes of this article, refers to the speed with which ads render to the page. This used to be wildly variable – in the time of synchronous javascript tag waterfalls, it was anyone’s guess how fast ads would get to the page. Now, with the advent of Prebid.js, we have a wonderful centralized path to control our ad render speed (as long as you don’t add a bunch of stupid outside of prebid widgets to the page that wreak havoc, which I know you will).
A quick conceptual recap – Prebid is a javascript auctioning system for ads. Prebid commits every cardinal sin mentioned in the above web site latency list of warnings – well at least most of them, it’s not blocking javascript anymore (but it used to be!) – it has to load a giant resource file from a maybe external place, it issues a bunch of calls to third party servers, it has so much javascript in it that it requires a meaningful team of people just to wrangle old code – but goshdarnit, it’s the best thing we have!
And frankly, the alternative would be much worse. Having a single application to police, a single application to integrate with our existing site experience javascript and GAM, is actually wonderful compared to the alternative where we’re managing tons of different providers on the page. Prebid actually has rules about what third parties are about to load – and it polices them.
And this means that as long as all of our partners are running through prebid, or at least substantially all of them, we have a way to control the critical path by which ads get to our page. We can control the speed by controlling the participants in prebid and how they participate. We can also control the network requests on the page by adding players individually and observing their behavior.
Does Ad Stack Latency Matter?
That being said, I’m dubious that anyone is really doing a good job of measuring whether or not ad stack latency matters. People freak out when their “timeouts are set too high” or when their “auctions are too slow” – but why? A slow prebid auction, and bad ad stack latency really has two primary negative ramifications I can think of :
Breakage – ad units that don’t have time to render before the user navigates away. This leads to lost revenue due to fewer impressions
Decreased Ad Performance – whatever metric you want, if ads are slower to get there it’s probably going to be worse. Viewability, CTR, etc.
But that's it. And guess what – we can measure both of these things pretty easily by A/B testing our setups, and in my experience, you have to make major modifications and really fly off the handle to meaningfully affect these things with your ad stack. 9 times out of 10, these metrics are far more materially affected by bad Web Page Latency than they are by the ad stack itself. So as we walk through the different components of ad stack latency, specifically with regards to Prebid, let’s keep in mind that making a lot of these settings too long might not actually make that meaningful of a difference in your ad stack latency, while making timeouts too short can absolutely negatively affect monetization.
Ad Speed Latency Part 1 - Timeouts
Prebid gives its users lots of controls over the timing of things. Off hand, I remember at least 3 different timeouts :
Failsafe Timeout – hardcode JS timeout for the total auction, after this amount of time call GAM. Killswitch.
Real-Time Data Module (my favorite module) Timeout – how long are real time data providers allowed to respond. Real time data providers are companies that inject data into the auction, like user IDs or data providers.
Prebid/PBS Auction Timeout – how long are bidders in your auction allowed to respond
The sum of the latter 2 timeouts is your controlled “auction” timeout – these are the method by which you control how quickly ads get to your page. Make your timeouts short and auction participants will not get their data into the auction – more often than not, this means you make less money. Make your timeouts too long, and supposedly ad KPIs and ad impression counts will suffer.
I strongly, strongly, strongly recommend testing higher timeouts here. One of the top mistakes I see people make is arbitrarily selecting their timeout and then not A/B testing it or at least _trying_ a higher timeout and seeing if they make more money (you really should be A/B testing everything without hurting other ad KPIs (viewability, breakage). You might need different timeouts by device or geo – this is due to breakage on slow devices – but still test it, sometimes a slick website loads everywhere pretty well.
Ad Speed Latency Part 2 - Network Requests and Partner Count
In addition to your timeouts, which are the mechanics of your auction, publishers also have control over the number of participants in the auction. This is an important one – this ties directly back to website page speed, and it actually affects both web latency and auction latency at the same time. The number of participants maps not-so-cleanly at all to the number of network requests issued from the browser.
What is a network request? In layman’s terms, it's when your browser reaches out to a server to get some kind of information back. It could be data, it could be bids, it could be an image, it could be another website – but your browser is talking to someone. To put it in perspective, at the time of writing this article, on a random page load, cnn.com had over 600 requests in the first 10 seconds of the page loading, and they’re still comin’.
Web pages load a _ton_ of network requests. But people freak out about them – and the only explanation I can come up with is that they don’t understand how latency in auctions and on pages actually works.
To add an additional prebid participant, you are typically adding a single additional network request (now that everyone SHOULD be on single request architecture. Ask your bidders this. If they’re not running SRA, they should be, and they’re demons for not doing so). Ask your data providers this – how many requests will you add to my auctions? How fast do you respond on average?
If someone is adding 1 request to your ad stack, and they respond in under 500ms, the likelihood that they’re going to have a material negative impact on anything is incredibly low. Cnn.com, that blue chip fancy website, is now over 1500 network requests in the time between when I wrote the last set of requests and writing this sentence now. Adding a bidder who adds 1 request per prebid auction (and you should only have 1 global prebid auction per set of ads, more on this in a minute) is just not going to break the bank. If they’re a slow responder they might consume more of your timeout and slow down your ads by a few hundred ms – but modern tech players shouldn’t do this.
Ad Speed Latency Part 3 - Widgets and Third Parties
Everything I’ve written above is true for Prebid. You will get your ads to the page quickly, you have total control, and life is peachy when prebid is in charge of the ads on your page.
But there’s a pesky problem in publishing – not everything runs through prebid. This presents us with an issue. By hardcoding tags on the page, you have tech on your pages that is no longer subject to the code review by the prebid team, and my goodness do people do horrible things.
Wrap up their own instance of prebid and run another auction on your site? Yup, almost everyone does it.
Add blocking javascript to the page and kill CWV? Yup, it’s happening, and like, everywhere.
Issue a metric bazillion network requests in the course of trying to hold their auctions? You betcha.
Third party ad widgets that run outside of Prebid are the number one thing that I see break publisher pages. These always have some kind of shtick, they’re sometimes direct sold, and more often than not when something is direct sold it’s doing something invasive. So I would ask, if you’re a publisher, ask all of the questions above of every third party widget on the page. Who are you calling? How many calls? Was your code written by a high school junior in Jakarta? And what exactly do you do to monetize your widget.
Conclusion
Web Page latency is complex, difficult to understand, difficult to measure (Google’s CWV measurement tool hates Google’s own ad library gpt.js and says it’s slowing pages down meaningfully, lol).
It is possible to have a fast website that runs big ol’ ad stacks. More than possible.
Your prebid timeouts are probably shorter than they could be, and you could probably be making more money.
You could probably work with more partners with minimal negative latency impact, as long as you’re intelligent and ask them the right questions.
How your ad stack is integrated with your page is probably as important as the ad stack itself – don’t be sloppy with your JS.
Third party widget vendors might be wreaking havoc on :gestures widely:. Scrutinize them, make sure they’re adding real value and lots of money if they’re going to harm your pages.
Unless you’re worried about search traffic, it’s easy to measure the impact of additional latency on Viewability and Revenue – just a/b test and scope it out. Maybe your site can be a little slower than you think.