Download edition

About the Author: Tim Vereecke

This technical paper was written by community member Tim Vereecke. Tim is the owner of a large website about scale modeling, called Scalemates. The ads on the site are managed and delivered using Revive Adserver. Based on his extensive expertise and years of hands-on experience since December 2010, in this tech paper he presents his findings, recommendations, and best practices for Lightning Fast Display Banners.

Introduction

Performance is important! Improving the following KPIs not only leads to faster loading banners, but also increases publisher revenue and advertisers benefit from more effective campaigns:

Core Web Vitals (CWV):
Faster banners have a positive impact on the Core Web Vitals of a website and are a ranking factor for SEO (Google); More organic traffic via search leads to additional page views and thus to an increase in banner impressions. We will focus on Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS).

In an ideal world, a page with fast banners loads according to this pattern:

Due to the reserved space, no content was pushed down or to the side when loading the banners (CLS=good).

Looking at the performance problems raised by the Revive Adserver community, we see suboptimal patterns which can be categorized into four key areas:

Delayed page content:
The banners delay the actual content, including LCP.

A separate section is dedicated to each of these four problem areas, in which we present additional background, recommendations and best practices for solving the problem. Use one of these four buttons to jump to the releant section on this page.

Problem 1: Delayed Time To Ads

Problem description: The page itself is fast, but banners load slowly.

It is positive that the header (dark blue), the text (gray) and the hero image (light blue) are displayed after only two seconds. However, we have to wait patiently for another 3 seconds before the two banners (black) finally become visible.

The solution to this problem is complex and we will share tuning options for the ad server, the publisher and the advertiser.

Before we get into the tuning options, it is important to go one level deeper and understand the three phases required to reach TTA.

We do this by analyzing the waterfall diagram of a page that loads ads. A waterfall diagram shows what resources have been loaded by your browser to display a web page (with the horizontal axis representing the increasing time and the vertical axis representing the order of resources loaded from top to bottom).

Take this sample HTML code for a page having 4 zones and the Asynchronous Javascript Zone Invocation Tag (asyncjs.php).

The waterfall diagram for the above page (www.example.com) looks like this (For the sake of simplicity we do not show css, fonts, scripts, images, etc. and replaced them with three dots):

On this waterfall we can identify 3 distinct phases to reach TTA:

Phase #3: The time between DCL and Time To Ads (TTA)

• Only when DomContentLoaded (DCL) is triggered, asyncjs.php continues its work and triggers the zone request (asynspc.php?A,B,C,D) for all 4 zones at once.
• The response from asynspc.php arrives and four <img> tags are added to the corresponding zones in the DOM.
• The browser triggers requests for the 4 inserted <img> tags hosted on media.example.com and renders them accordingly.

Note: If you want to visualize the three phases for your own site you can run a speed test on WebPageTest.org. The output of this free tool is a waterfall diagram like the below. Here you see a diagram for a site having two banner zones:

You can speed up the TTA by accelerating one or more of the three delivery phases. The responsibility for a fast TTA lies with all three parties in the delivery of the banners. If one of them slows down, your TTA is suboptimal.

Ad Server Tuning Options

The ad server’s main responsibility is serving its resources with the smallest delay possible. This is achieved by reducing network latency, origin latency and reducing the connection overhead to the domains.

Reduce network latency

Reducing network latency has a positive effect on the TTFB and the download time of the resources; this can be achieved by the following measures:

• Use a CDN that supports the following:
  • Caching static content (e.g., Javascript, images)
  • Acceleration of requests that cannot be cached (e.g., zone requests)
• Set up your infrastructure close to your viewers
• Use a distributed setup that supports multiple regions

Reduce origin latency

A prerequisite for fast loading of resources is a fast and scalable infrastructure. Make sure to follow Revive Adserver’s system requirements and use the latest versions of the software as well as the corresponding newer versions of PHP and MySQL.

For optimal performance, it is important that you update your systems to the latest versions of Revive Adserver, PHP and the database. With PHP 8, for example, a Just-In-Time (JIT) compiler has been introduced, which dramatically lowers execution time. If you are using an older version of PHP, you are leaving a significant amount of performance on the table.

Reduce Connection Overhead

Before the browser can send a request to https://media.example.com it needs to set up a connection.

This requires a DNS lookup, setting up a TCP connection and securing the connection using TLS. Each of these steps takes some time and delays the download of the banners.

An ad server can shorten the DNS overhead with these methods:

• Increase DNS TTL
• Reduce CNAME chains
• Use of a fast (global) DNS provider

To reduce the TLS and TCP overhead, the ad server can perform the following optimizations:

• Enable TLS 1.3
• Use OCSP stapling
• Use ECDSA certificates
• Increase the keep-alive timeout: Avoid reconnecting within the same session
• Use HTTP/3 (with 0-RTT)
• Use a CDN

Remove Connection Overhead

An alternative approach for the previous point is removing the overhead to media.example.com entirely.

You can achieve this by serving all advertising-related resources from the same domain. This eliminates any DNS, TCP and TLS overhead when requesting the banners and therefore they will load faster.

Alternatively, if you do prefer different domains for scalability and/or security reasons and want to separate your static and dynamic content, you can ask the publisher to preconnect to your static domain (see the next section).

Publisher Tuning Options

The publisher has a big influence on and responsibility for TTA.

A fast delivery of the HTML, a page structure which triggers DCL quickly and optionally pre connecting to the domain serving the banners.

Preconnect

Using the <link rel=”preconnect”> resource hint a publisher can instruct the browser to connect to media.example.com in advance.

The browser resolves the DNS, opens the TCP connection and secures the connection (TLS) before the actual banner request is made. This leads to a shortened phase #3, as the loading of the banner can start immediately.

The syntax for pre-connecting in the <head> of the HTML:

Note: This is an alternative in case the ad server can not serve all content from the same domain, see the Ad Server Tuning options section.

Speed up DOMContentLoaded

The asynchronous version of the Javascript tag only triggers the zone request when the DOMContentLoaded event fires.

DOMContentLoaded fires when the HTML document has been completely parsed and all deferred scripts (<script defer src=”…”> and <script type=”module”>) have been downloaded and executed. It doesn’t wait until other things such as images, subframes and asynchronous scripts have finished loading.

DOMContentLoaded mainly depends on the publisher’s page structure and resources. A slow DOMContentLoaded significantly delays the zone request.

While a fast DOMContentLoaded event is crucial, the tweaks and optimisations are not specific to Revive Adserver and therefore out of scope for this blogpost. Publishers can use the techniques explained in this excellent blog post: Optimizing DOMContentLoaded.

This real-world example shows the devastating impact a slow DCL can have on TTA.

This waterfall diagram from WebPageTest.org shows asyncjs.php is already available at the 1.5 second mark, asyncspc.php is not triggered until DOMContentLoaded, which happens more than 4 seconds later on this page.

Improve HTML delivery

Speeding up HTML delivery brings forward DOMContentLoaded and thus TTA.

Publishers should ensure that the Time to First Byte (TTFB) of their HTML is as fast as possible.

We refer to this blog post that publishers can use to Optimize their Time to First Byte.

Advertiser Tuning Options

While options for advertisers to improve TTA are limited to their banners and those are typically not the core problem they do have a few options at hand to improve TTA performance.

Reduce banner weight

Advertisers can influence banner delivery performance by delivering appropriately sized images.

Some options to consider are:

• Avoid very large animated gifs
• Upload images in the right size
• Use modern image formats such as WEBP and AVIF, which are generally smaller than the well-known JPG, PNG and GIF formats
• Find a better balance between banner quality and banner weight

HTML Banners

When using HTML banners, advertisers can influence performance by reducing their HTML, <scripts>, <style>, fonts, images, domains, requests, 3rd parties, etc.

This is a topic in itself and is beyond the scope of this technical paper.

Problem 2: A large banner becomes the LCP element

Problem description: The banner is identified as the LCP element.

When the very large banner is loaded (3 seconds), it replaces the already loaded hero image (2s) as the LCP element.

The core problem here is when a publisher configured a zone allowing too large banners.

Improve TTA

While the root cause can only be remedied by the publisher itself, all parties can indirectly reduce the negative effects of this problem by ensuring a fast TTA and therefore a faster LCP.

The options for this were discussed in detail in the previous section: Problem 1: Delayed Time To Ads

Problem 3: Visible Layout Shifts

Problem description: The content of a page is pushed in all directions the moment the banner arrives.

While it is positive that both the main content and the banners load quickly, the user experience is suboptimal due to the visible layout shifts (CLS=bad) at the 3-second mark.

The page was rendered at the 2-second mark, but without reserving space for the banners. As soon as the banners are loaded, they displace the already rendered content downwards (= layout shift).

The solution for this problem lies solely in the hands of the publisher and can be fixed with a few rules of CSS.

Define Zone Placeholders

Publishers can easily avoid Layout Shifts by specifying both a width and a height in their CSS. In this way, the expected space that the banner will ultimately occupy is reserved.

A custom zone that can serve banners with dimensions: 300×100, 300×250, 300×600, …

From a pure performance perspective, these should be avoided. Since the publisher cannot estimate the size of the actual banner, he cannot specify the exact width and height of the banner and must fall back on flexible placeholders.

By using min-height and min-width, a publisher can reserve a certain amount of space, which is then automatically enlarged as soon as a larger banner is loaded (The large banner in the sidebar at 3s).

Whatever value the publisher chooses, it’s always a trade-off between too much white space (the placeholder was too large), which detracts from the beautiful design, and a layout shift (the placeholder was too small), which has a negative impact on the CLS score.

Problem 4: Delayed page content

Problem description: The banners delay the actual content, including LCP.

The header is rendered quite quickly (2 seconds), but the user still has to look at a partially blank page for a few seconds before the rest of the main content (4 seconds) and the two banners appear (5 seconds).

This is a typical problem for publishers using the standard (synchronous) Javascript invocation tag.

Use asynchronous tags

Revive Adserver has offered support for asynchronous JavaScript tags since version 3.2.0, which was released in 2015. The advantage is that a website containing these asynchronous tags will still work even if the ad server is slow or unresponsive for some reason. It also avoids delayed rendering while the browser waits for the (slow) synchronous scripts

This filmstrip (captured using WebPageTest) shows the impact of a slower ad server on the rendering of pages with the older synchronous invocation tags. While the actual page is very fast and although most elements (css, images, fonts) are already present at the 1s mark, any further rendering of the page is stopped while waiting for the slow ad server.

Typically, the asynchronous variant should deliver better performance because it does not:

• Block rendering while downloading and executing each tag.
• Uses document.write().
• Degrades performance exponentially on slow connections.
• Degrades performance exponentially for slow ad servers.

Improve TTA

If the synchronous tag is preferred or the only option, the advertiser can reduce delay of the actual page content by implementing the exact same techniques discussed extensively in “Problem 1: Delayed Time To Ads”:

• Reduce network latency
• Reduce origin latency
• Reduce connection overhead
• Remove connection overhead

Trade offs

Although this technical paper has focused exclusively on the technical options for improving performance, it is your responsibility to consider whether these options actually make sense for your setup, your content and your business goals.

Before implementing them, you need to critically evaluate and understand the potential impact of each suggestion on your short, medium and long-term business goals.

Summary

We have solved 4 common performance challenges when delivering banner ads.

The solutions offered for lightning-fast banners are in the hands of the ad server, the publisher and the advertiser.

If you have any questions or remarks, feel free to ask them in the Performance, Scalability, and Reliability section of the Revive Adserver community forums.