For amp-ad, provide placeholder animation while ad is loading

[jasti]

Ads can take longer to render compared to content in the article. When ad is loading, there is no indication to the user and AMP will simply show a blank when loading. We should show a placeholder animation while ad is loading. Apply same animation as #3830.

One issue is that we have no idea how long it takes to load the ad. We use the onload event of the ad iframe, but that often fires within milliseconds.

Possible solution is to have the ad overlay on top the animation (if possible) and hence avoiding the need to dismiss animation when ad begins to actually render.

Looking for other suggestions.

CC @cramforce

[cramforce]

@jasti The idea is a good one, except that I'd be worried that we keep paying the price of the animation when it is no longer visible.

[cramforce]

It would also mean that iframe would need to be transparent, which may or may not work; and that if no ad ever loads but also doesn't tell us, it would keep spinning.

[jasti]

@cramforce Sounds like worth experimenting with a different solution then.
The case where "if no ad ever loads but also doesn't tell us, it would keep spinning." - suggestion to set a reasonable timeout and replace with pub or default fallback.

Still think deterministically showing something, animation or fallback is better than blank white space.

[ericlindley-g]

@cramforce @jasti — slotting this in Backlog, given this is under discussion, but please correct/update as needed

[zhouyx]

with the render-start event from ad-server, it is possible to add a loading animation for ad when loading. What's our plan for this feature? two main concerns:

1. we would still need to deal with the issue

   if no ad ever loads but also doesn't tell us, it would keep spinning.

2. Not all ads support the render-start event, which makes the behavior differs on different ad type.

[jasti]

@zhouyx Does it make sense to experiment with loading with an animation with a set timeout, so we don't incur the cost of the animation if there is no fill? (start with 2 seconds maybe and we can experiment?)
Is there literally no way to "paint" over the animation with the ad response from the ad server? This way, the max amount of time the animation will ever run is about 2 seconds.
@lannka FYI - looking for other ideas.

[lannka]

A non-related question: do you think it will be a better UX if the placeholder indicates that this is a place for ad? As a user, quite often I found myself waiting on a blank area for seconds and expect to see an image, but it ends up with an ad. @jasti

Back to this thread, I would prefer we keep the "default" simple and fast. To me, it's probably not that important to show a GIF animation for a loading ad. We can provide an override though, if publisher really think it's an important UX improvement to have animation, they can do it with their own cost. In that case, 2s timeout sounds good. We can tune this number when we have number.

[zhouyx]

@lannka LOL. I saw a lot publishers put something like 'this is an ad, continue reading' above an ad though.

As a user, quite often I found myself waiting on a blank area for seconds and expect to see an image, but it ends up with an ad.

You mean we provide them with an attribute or let them customize through CSS? (hmm Not a big fan of making everything customizable)

We can provide an override though, if publisher really think it's an important UX improvement to have animation, they can do it with their own cost

[lannka]

You mean we provide them with an attribute or let them customize through CSS? (hmm Not a big fan of making everything customizable)

I think we already do. Pub can customize an loading indicator using placeholder:

  <amp-ad width=300 height=200
      type="doubleclick"
      data-slot="/4119129/doesnt-exist">
      <div placeholder>
        <img src="/loading.gif">
      </div>
  </amp-ad>

[dvoytenko]

Not sure if that'd help, but AMP already provides a standard loading animation for some of it's elements, e.g. images. You can try it with a bigger image or a low-bandwidth simulation to see it. We could possibly extend it to ads as well. So far, however, our thinking was that we only show animations for things that actually part of content - e.g. a part of content that the reader needs to wait to read. Ads are more ancillary in this sense.

[jasti]

@dvoytenko that's exactly what we are behind actually. The current state is that ads are just blank, which leaves the user guessing -> bad experience. We should apply the same animation as currently for images/ other elements on the page.
The problem is, we don't know how long it takes to load an ad. onload event is not reliable - triggers too fast.

[dvoytenko]

I'd sum it up as we have two problems:

1. UX to show while ad is loading.
2. Recognize when the ad is loaded enough to actually show something.

I'd still argue that showing animation on ad loading is not a right approach - it's not part of main content and should not distract the reader. I'd rather look into a canonical and easily customizable background color. Also, background color partially solves the second problem: it will be visible until the ad naturally paints itself.

[jasti]

I see your point. However, by treating ads differently than rest of the content, we train users to gloss over whatever loads in that different colored box (causing lower viewability). If you asked publishers, I suspect they'd want to treat loading all elements of the page the same way because loading resources differently could be considered distracting to the user. Although popular opinion- Ads shouldn't be treated like some sort of punishment to the user - we only accentuate the problem :). I'm working on another proposal to clearly label all ads in AMP (even before the actual ad loads), which I will share with you separately.

Having said all of this, @dvoytenko's approach does sound more straight forward to implement, so if you don't agree with above, we should move forward with it.
The one issue we might face is when ad returned is not the exact same size as the background we draw - in which case there'll be a weird diff between the ad and the background image. (I don't know if this can happen on AMP, but seen this on other platforms).

[dvoytenko]

@jasti Gray space around an ad can indeed happen - but the ad is always able to do something about it because we give the ad the full control of the space. It comes down to whether or not the ad sets its background color on its <body>. I think most of time this will work well. So, there's no reason for us not to try this out - under an experiment, of course.

Overall, I believe we need to work out some spec for UX for ads in AMP and it's variations and proceed with experiment-based approach for each variation.

[dvoytenko]

@jasti It does apply to our standard loader as well for ads. We can enable it under the experiment.

[jpettitt]

You can do this with CSS

amp-ad { background-image: url("https://storage.googleapis.com/relay-scratch-storage/spinner.svg")}
iframe {background: #fff}

throw in a transition to make it go away after a timeout, not as pretty as a custom built solution. But doable in less time that it took to read this thread.

[jasti]

@jpettitt yea, pubs can do it automatically using the placeholder approach too but not many pubs choose to customize.

<amp-ad width=300 height=200
      type="doubleclick"
      data-slot="/4119129/doesnt-exist">
      <div placeholder>
        <img src="/loading.gif">
      </div>
  </amp-ad>

The discussion here is about the default experience.

[rudygalfi]

@zhouyx Is there any other issue being used to track ad loading improvements, or is this the main one? (Mainly asking because this hasn't been touched for 3 months.)

[rudygalfi]

Ah, I think I found it. Part of #5918.

[jasti]

Launched.