Typically a word like lazy loading is something most people have come across. Lazy loading is the process of waiting to load certain resources (ads) until we really need them. Doing this will make sure you're not loading stuff you don't need and you improve the overall performance of your site/app.

More control

When dealing with ads, lazy loading delays the whole process of requesting ads. This means you have 1 parameter to control. But what if you want even more control?

Why would i need that?

Because loading ads nowadays is a bit more complicated than it used to be and might require multiple steps. If you're using Prebid you are basically doing the following

1. Loading the site
2. Requesting bidders
3. Send the best bid to your ad server
4. Wait for a response from your ad server
5. Loading the actual creative (your ad)

Depending on your setup each step might be more or less resource-heavy. Typically the network connection is the bottleneck when loading ads, which is why we might want to use strategies that can help with the limitations of our network connection.

To mitigate some of the network heavy stuff we can differentiate between fetching an ad (2, 3, and 4) and loading the actual creative (5). This will break up the network-intensive task of finding the correct ad (which happens most on servers) and loading the actual ad (which happens on the client).

We can call the first part for fetching and the second part for rendering .

Prebid and GAM

Since Prebid and GAM is a very "normal" stack when talking about ads, I will give a few inputs as to how one could go about setting up these fetching and rendering stages.

If you're using GAM as your ad server you might be in luck. They actually have this built into their library. It looks something like this:

googletag.pubads().enableLazyLoad({
    // Fetch slots within 5 viewports.
    fetchMarginPercent: 500,
    // Render slots within 2 viewports.
    renderMarginPercent: 200,
    // Double the above values on mobile, where viewports are smaller
    // and users tend to scroll faster.
    mobileScaling: 2.0,
});

For most cases, the above settings will give enough flexibility to control the two stages correctly.

With the above settings, you can start fetching ads before the users scrolls them into view. But this is where our potential problem comes in. The devil is in the detail, and to be honest most people don't need to keep reading this article, but a few people will have requirements that are not satisfied by the setup above.

There are use cases where you want to control very specifically when each of their stages is started. So what then? — built your own!

Build your own

Building your own version of features usually comes with tradeoffs. Most times you should use the features already available, but there will be cases where a specific implementation is required that only a custom version can handle. This could in this case be

• You want a different rendermargin for different ads
• You don't want to rely on viewports as a measurement, but maybe another event
• You don't use GAM as your ad server, and you need the functionality

Working on top of another library will give certain limitations when trying to implement this feature, but using service workers might be one way to do this. The idea is something like this:

1. Do your normal "lazy loading" which will give you the fetcher stage
2. Use a service worker to intercept the GPT request.
3. Use custom logic to decide when the GPT request should be resolved and start the rendering stage.

Final thoughts

Adjusting lazyloading, fetching, and rendering all come with tradeoffs. Loading things too fast (bad for your network) will result in unviewed impressions.

On the other hand, loading this too slowly (good for your network) will cause users to scroll by your ads before they are loaded, ultimately giving fewer impressions.

You might like