What's it done to your page load time and user engagement metrics?

It's hard to say with any degree of certainty. This week compared to the same week a month ago, I've had 18% fewer pageviews and 12% fewer sessions. But my site focuses on a local demographic and we've had warm weather for the last week, along with the Daylight Savings Time change (both of which could mean that people are spending more time outside), so I'm not comparing apples to apples.

Average page load time of those 2 weeks increased by 24%, but in real numbers that's only 6.9 to 8.56. So while I'm tempted to chalk the drop in traffic up to the weather, I also know that every second I can shave off of load time turns in to more pageviews.

This is why I'm thinking about the idea of loading ATF banners Async, and BTF banners Sync... maybe that will give the best of both worlds? But I keep getting mixed information on whether it's allowed, or a bad idea, or what.

Found the original article that I mentioned:

[thedev.blog...]

Sorry, I got it backwards: he suggested making the ATF Sync, and the rest Async.

In terms of user experience the more interesting metrics are Document Content Loaded Time and/or Document Interactive Time. Loading ads synchronously is likely to slow down the loading of your content in favor of the ads, so it makes sense for the ads to be getting more attention. A 35% increase is quite significant and I would make sure the user experience isn't impacted to the point where you may be at risk of violating the AdSense terms of service. You can certainly take an idea from an article like that (i.e. a poorly written one with many unsupported claims) but don't just run with it; run your own tests.

I should add that it's unlikely you're violating AdSense TOS just by switching to the synchronous code; my point is more that the impact is apparently high, so you'll want to make sure you understand the exact cause.

I think the first thing is to understand what async does. Async applies to external javascript functions, in this case the ad code. Without the async, rendering of the page is blocked while page waits for the server request to return the code. Once the code is loaded the code is executed and the page is rendered. What async does is simply allows the page to render while the js code request is being carried out, once the code is received it will pause the rendering, execute the js-code and continue rendering.

Using async is not actually slowing the loading of the ads in any significant way. It might slow it by milliseconds as it waits for the rendering task in process to complete before allowing it to pause, but this is likely insignificant. By not using async, you are putting the breaks on everything and telling the page to wait, load and render the first ad then proceed rendering the page.

So why would you not want to load ads async? It seems obvious that stalling the page load is a bad idea, just to wait for an ad, specially when you realize that it does not load the ads any faster.

But there may be a good reason to do this, specifically on mobile and for above the fold ads. Users are impatient. If the page loads, without the ad the user will see some content and immediately begin scrolling. By the time the ad is rendered the user has passed it by. By blocking page rendering, you are essentially telling the user wait here, look at this ad, then proceed to the content. I admit this is not the best user experience, but ads in general are not a great user experience. But they are the cost the users pays. How much can you afford to annoy your users? This is a question only you can answer.

But it is not that simple, because as others have explained above, blocking a page from rendering will impact your page speed and page speed is a ranking factor. More users generally out weighs any benefit of optimized ad placements. So I think there is a fine line to be navigated here between ux, ranking and ad revenue. One thing that is for sure is that below the fold ads should be async ad units.

For desktop I don't think this issue is as critical since, there is usually sufficient content in view of the user that they will not start scrolling before the ad has rendered.

So another solution to consider, is simply pushing the first ad unit down the page on mobile, such that it is at or below the fold, then the user can get the above the fold content quickly (meets page speed time requirements) then scrolls to the ad, if loading is fast the ad is already displayed. otherwise consider making the first ad non-async.

FYI, Rob, the only thing I could find on this that "sounded" official was this:

[productforums.google.com...]

I don't think that the contributor is an official representative from Google, but he said "No, you cannot mix asynchronous and synchronous tags on the same page. This can result issues in delivering creatives."

But, that was also a year and a half ago, so...

Nick, I really appreciate your input, that was helpful and insightful.

@csdude55, from my experience the AdSense "experts" on the product forums usually have no clue whatsoever when it comes to policy. I wouldn't consider it a reliable source of information.

As far as I know there is absolutely nothing wrong with mixing sync and async on one page. There's no reason for it to be a violation, since no one is modifying the code in any way, just using what G is giving us

Well if there are "issues in delivering creatives", I suppose you'll notice soon enough :-)

As far as I know there is absolutely nothing wrong with mixing sync and async on one page. There's no reason for it to be a violation, since no one is modifying the code in any way, just using what G is giving us

I finally found the reference on the Google support page about it:

Mixing asynchronous and synchronous ad tags in the same web page is NOT recommended.

[support.google.com...]

That was pretty vague and didn't say WHY it's not recommended :-( But I don't think it's a violation, it's just not recommended for some unexplained reason.

Well if there are "issues in delivering creatives", I suppose you'll notice soon enough :-)

I thought that, too, but then had another thought.

When I first started using an ad management company, they were able to approve me having 5 banners instead of 3. But then there was a problem with the same creative being on the page twice, so I had to modify my code by adding:

data-ad-skip="4" data-skip="4"

and changing the ().push statement to:

<script>(adsbygoogle = window.adsbygoogle || []).push({ params: { google_skip: 4 } });</script>

Now that they allow unlimited banners per page this isn't an issue any more, but it crosses my mind that I might still have to do something like this if I mix Sync and Async... like, keep up with a count and push that count to all of the Async banners?

>> Sync, Async, or Async above-the-fold only

I think the best solution would be to only load the adsense unit that is currently visible in the view port. This improves page load performance by only displaying the ad unit that matters. i.e. lazy loading.

But I don't have found a technique for the doing this yet. Is anyone doing this?

Expat, I haven't really explored it yet or anything, but this is something I was thinking about implementing:

[css-tricks.com...]

It's worth checking out... at the very least, it might be a starting point.

Google Doubleclick has something on their site, too, about setting up lazy loading (someone posted that for me on here awhile back), but I don't use Doubleclick so I haven't looked at it too closely. It might be more "official", though, if you have that option.