Frequently Asked Questions (FAQ) – Lazy Loading, Infinite Scroll, and Single Page Apps (SPA)

Frequently Asked Questions (FAQ) – Lazy Loading, Infinite Scroll, and Single Page Apps (SPA)

Lazy loading is where an article or page has numerous elements, maybe listicle parts, images, or article subsections, and as the user scrolls down, elements aren’t actually downloaded until the user is nearby on page.

Infinite scroll is when the user gets near the end of an article, and another article or piece of content that the user might like is immediately added to the page so the user can continue enjoying the site with minimal effort.

Single Page Apps (SPA) are where the user clicks an element of the page, and instead of the whole page refreshing, only parts of the page that change (usually the central content) are updated. This often results in a significantly faster website experience, but some search engines have problems indexing this content.

These three techniques are often combined to make seamless and very fast web experiences.

Ready to master your ad inventory like the pros? Become an ad ops guru with PubGuru University! FOR A LIMITED TIME, get access to our School Of AdSense, Ad Exchange, and Google Ad Manager courses for only $199! Click Here To Enroll

How do I know if Lazy/Infinite/SPA is right for me?

First off, you should have a regular developer on your team to execute these strategies properly. There are a handful of wordpress plugins that may offer such functionality, but we have frequently found their user experience to be very poor. If you don’t have a developer, these advanced techniques will be very difficult to implement properly.

Second, you need to consider that advertisers buy ads on a feedback loop. When you start shifting to lazy/infinite, most publishers see an immediate drop in session RPM. This is because their traditional units, especially those farther down the page, are much lower viewability. That ad performance is being imputed to the new lazy/infinite inventory. The feedback loop takes time for advertisers to adjust. We’ve seen it take 4-8 weeks before publishers start to break even.  If you do not have this amount of time in your revenue cycle to invest, you should not test lazy loading.

Third, some publishers rely heavily on organic search or organic social reach.  Many indexers of major search engines and social networks have a tough time indexing lazy/infinite/SPA content.  For some publishers, this means switching to lazy/infinite/SPA can reduce organic traffic.  With that said, Google and Facebook are pretty adept at properly indexing lazy/infinite/SPA when implemented cleanly with major javascript frameworks.  On the other hand, Google and Facebook heavily include page load speed in their organic reach algorithms, and drastically speeding up your page can result in a significant boost in organic traffic.  So pay attention — if your organic reach takes a nose dive after switching, you should strongly consider switching back to traditional setups.

Does lazy/infinite/SPA increase revenue?

The general idea on lazy/infinite/SPA is that the user only gets ads/content when they’re close to it. This drastically increases viewability and engagement with those ads, but reduces the sheer number of ad impressions. Most advertisers pay a disproportionate premium for higher viewability. Industry stats show doubling the viewability of a 35-40% viewability unit to 70-80% results in a 2.4x increase in revenue. This is another reason why publishers look to use lazy/infinite/SPA.

With SPA, can I refresh ads when the user goes to a new piece of content?

Obviously if the ads are in-content and the whole content pane is being loaded, you’ll want the ads to fire properly. As far as the page is concerned, these are completely new ads. If you have sidebar ads that do not change with SPA, you should only refresh them if they have been viewed.  Otherwise, you’re only hurting your own viewability stats.  You can contact your advertising operations specialist for assistance in setting up these viewed-impression refreshes.

When should I load lazy/infinite and how much content should I load?

When the user’s viewport gets down to about one viewport away from the bottom of the page, you should start loading content with lazy or infinite scroll. Do not wait until the user gets all the way to the bottom of the page, or you will get a very poor user experience as they’re constantly waiting for content to load. Instead of waiting, many just leave.

The amount of content that should be loaded with infinite scroll depends on your average pageviews per session. If your users regularly average 10 pageviews, then you should consider loading up to 10 articles maximum on a pageview (loading each one individually of course). After that, show a list of options where the user must actually click. It’s important to limit content pieces per page as there are plenty of online bots that will eat up tons of server resources just by scrolling until they get to the bottom of a page, and if your infinite scroll is truly infinite, you’re going to be wasting a lot of resources on such loads.

How many ads can we load on a single page with lazy/infinite/SPA?

We have found some publishers get very aggressive with the number of ads loaded per page. Lazy loading and infinite scroll are not an excuse to run unlimited ads on a page. Publishers who cross certain boundaries see reduced social and search engine reach. We’ve confirmed that loading 75 units on a page violates the guidelines of popular social networks, reducing the publisher’s social reach drastically.

For mobile, there should only ever be a single unit on the screen; never two ad units at a given point in time. Anchor units are the exception to this, although some social platforms reduce reach for using anchors. In other words, include an ad, then fill in a full screen height’s worth of content, and then you can include another ad.

Can I use the same tags, ad units, or header bidding PIDs to split test lazy/infinite/SPA vs traditional setups?

No. If you do this, advertisers cannot differentiate between the two segments of inventory. Ad impressions on a lazy/infinite ad experience typically have significantly higher viewability and CTR because they’re much more likely to be seen (they’re not loaded until the user is close). Without giving advertisers the ability to differentiate the inventory, publishers will see limited or negligible gains in revenue.  This is why you must have different ad tags, different ad units, and different header bidding PIDs if testing or transitioning to lazy/infinite/SPA.

Why did my pageviews drop with lazy/infinite/SPA?

Most analytics platforms do not count lazy/infinite/SPA loads as a new pageview unless you’ve developed the code to specifically fire such an event. The result is your pageviews plummet. Instead, you should pay attention to sessions and session RPM as your primary KPI.

How fast can header bidding auctions fire and refire with lazy/infinite/SPA?

Some bidders do not support concurrent requests, so auctions are typically not fired concurrently. Additionally, excessive requests result in internal rate limiting by bidders. They will basically stop sending out bid requests to their DSPs and other ad partners. Further, repeatedly making numerous header bidding requests drives up latency and worsens the user experience for the user. For these reasons, we have a hard minimum of 10 seconds in between auctions, and we rarely move it under 30 seconds.

It should also be noted that a few demand sources are simply incompatible with multiple bid requests firing on the same pageview. If their code doesn’t throw an error, it responds with a null or zero bid. We make the initial request and do not make subsequent requests for these bidders.

For these reasons, lazy/infinite/SPA setups will often have 2-6 sets of header bidding PIDs for the exact same ad unit, so they can be used in comparative and analogous units down the page without the need for refiring an auction again.

How do I implement ads with lazy/infinite/SPA and PubGuru/MonetizeMore?

First, embed your config on page as normal:

<script src="https://m2d.m2.ai/path-to-config.js" type="text/javascript" async></script>

Then, your ad divs should properly reference not by div ID, but instead by data-gpt-parent.
<div class="pg-lazy" data-gpt-parent="leaderboard"></div>

<div class="pg-lazy" data-gpt-parent="right-rail"></div>

<div class="pg-lazy" data-gpt-parent="in-content"></div>

The data-gpt-parent must match any of the units in the config by slot or ad unit code (with or without the GAM network code).  This means if you have a unit of “/1234567890/atf-leaderboard” and the div id (slot) is “atf-lb” in the config, you can use any of the following values for your data-gpt-parent:

  • /1234567890/atf-leaderboard
  • atf-leaderboard
  • atf-lb

Just make sure the unit codes or div ids (slots) are unique in the config.  As the user scrolls or changes pages with lazy/infinite/SPA, you can keep referencing the same unit divs, and our code will take care of the rest. In the example code above, if the publisher has 5 copies of the “in-content” unit, our code will inherit settings from that unit for each of those copies.

For further support regarding PubGuru Header Bidding lazy loading and infinite scroll setups, sign up for a Professional account at MonetizeMore today!

Last update: October 24, 2019

Kean Graham

CEO and Founder at MonetizeMore

Kean is the resident expert in Ad Optimization covering areas like AdSense Optimization, DFP Management, and third-party ad network partnerships. Kean believes in the supremacy of direct publisher deals and holistic optimization as keys to effective and consistent ad revenue increases.

Get our latest ad optimization tips delivered to your inbox

Fill out my online form.

2 COMMENTS

  1. Billie

    Is there a way to prevent same ads showing up back to back with the infinite scroll?
    Thank you!

    Reply

Submit a Comment

Your email address will not be published. Required fields are marked *