New Choice for Ad Type

Synchronous or Asynchronous?

[Sally Stitts]

I just created a new ad. There is now a new choice just above the last step - "get ad code".

You must select Synchronous or Asynchronous (beta).
It defaults to Synchronous.

Which one are you gonna pick?

Synchronous because that is what it has always been (safe, conservative)?
Or be adventurous, and try Asynchronous (beta), at the risk of beta failure?


Seems to me, that I recall the wish that, "If only it were asynchronous."
That is to say, that it would load hastily, without delay, and not based upon other goings on.
Is that correct?
Isn't that always the best option, assuming that the Asynchronous option WORKS. Do they really need to ask us? Shouldn't they just do it?

Should we all go back, and convert ALL our old ad codes to "Asynchronous" (assuming it works, of course). Why would it NOT work? Is beta really required for something like this? Either it works, or it doesn't, right? (I am nowhere near an expert at coding, or how it works - I am just speculating).

I would appreciate feedback from those that DO understand coding, to get some guidance.

I have learned to be a late adapter (saves my hide), so I just defaulted to "synchronous", until I see extensive feedback to the contrary.

[levo]

Holly sh.t! This is big!

Edit: You can remove the inline dimensions and define the ad size via external css. Perfect for responsive design.
Edit 2: You can add data-ad-channel="0000" for custom channel

@Sally Stitts - The method is very similar to asynchronous DFP code. It should work. I think it's beta because of the endless variations of websites. For example if your website already has a styling that overwrites the dimensions of the adsense tag (ins), the ad won't render.

[netmeg]

Hunh, I don't see that in my account. Maybe it's not all rolled out yet?

(Removing the inline dimensions is actually how I'm doing the responsive ads right now - but only on half a dozen sites)

[MrSavage]

Thanks for making this post because I was confused about this while making an ad today. Okay what I liked in the "?" explanation, is something alone the lines that this code helps the ad display on mobile. I'm boiling it down, but the way I interpret what they are saying is that some ads have trouble displaying on mobile because of slow internet and this new code cuts through the mess and "guarantees" that it will display on those devices. Did I misread this? I have no reason not to use this code on all my units. First a few trial runs but at first look, when they say guarantee? I'm going to believe the Google. Based on impressions, I really get the feeling that my ads aren't always displaying. I hope that in of itself isn't jeopardizing my adsense account. Thoughts?

[ken_b]

This isn't showing yet for me.

Anyone know if this can be applied to existing ad codes via editing in the control panels?

I need to build a new ad, but maybe should wait until this shows up if we can't edit existing ad codes?

.

[levo]

You can select the asynchronous code for existing ad units.

[support.google.com...]

This help page has example code

[support.google.com...]

@MrSavage It says that because the new code doesn't block page loading, you can see "a noticeable difference on mobile browsers"

[edited by: martinibuster at 10:59 pm (utc) on Jul 1, 2013]
[edit reason] Fixed URL. [/edit]

[MrSavage]

After think about this, I'm wondering if someone with greater expertise would have a thought.

It's true that some ads on your site took a long time to get there? Isn't that true? The longer the ad unit is there, over time, it should become valuable real estate and better clicks. Am I right on that?

My point is, if you have a site with long standing ads, if you suddenly change over to this new code, is that going to sink all the good you had going on your site with the existing ads.

What I'm reading is that Google suggests that you switch over your entire site/all ads. Is it save to say that you're risking good paying ads you currently have?

I'm quite curious on this. I'm just not smart enough about the subject and I can admit that.

[netmeg]

Nobody knows for sure, but I'd think if you use the same channels, you're probably ok.

[hannamyluv]

Anyone know if this can be applied to existing ad codes via editing in the control panels?

I don't think so. When you switch from one to the other, the code in the box changes completely. By coincidence, because I was redoing a couple of ads' sizes (due to the change that they will now backfill larger ad spaces with smaller ads) I saw this and updated all the ads on my site with asynchronous.

While I have not had any problems in the past 5 days, I have also not seen any appreciable improvement in loading speed or bounce rate.

I'd think if you use the same channels, you're probably ok

It has been my experience as well that this is true. I never have any problem changing ad sizes or codes as long as I use the same channels.

[yaashul]

Is this async code w3c validated? It uses script without "type" means no support for HTML 4 and uses async. Can't be used in XHTML.

[thedonald123]

If you are using DFP asynchronous tags, be careful with switching to the new Adsense async code. In my very limited experience combining 2 asynchronous tags can cause problems

[jojy]

Quick question, if I have 3 ad units on a page do I have to include this line every time with an ad?

<script async src="http://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>

[NavyCS]

Edit: You can remove the inline dimensions and define the ad size via external css. Perfect for responsive design.

Is this tested to the point you trust it? For example, if I have a 160x600 ad on my desktop version, does Google render a 320x50 mobile ad if that is the CSS height/width I provide for the responsive Smartphone version? I really hope that is the case, but sounds too good to be true :)

[levo]

For example, if I have a 160x600 ad on my desktop version, does Google render a 320x50 mobile ad if that is the CSS height/width I provide for the responsive Smartphone version?

Yes, it works. Just like DFP, Adsense renders the correct size based on element's dimension. But you have to remove inline styling and set it via css. When the ad unit has an inline styling, css overriding doesn't work.

BTW, I've no idea if Google will let us use it in this way.

[NavyCS]

I hope G does allow it to work that way. I am sure Google will come out with more instructions fairly soon -- actually surprised they haven't at least done a blog post on it yet. Until then, I will stand by.

I have been using this code, works, but it seems more cumbersome than it needs to be;

<script src="//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js">
</script>
<script type="text/javascript">
google_ad_client = "ca-pub-xxxxxxxxxxx";
if ($(window).width() >= 730) {
google_ad_slot = "xxxxxxxxx";
google_ad_width = 728;
google_ad_height = 90;
} else {
google_ad_slot = "xxxxxxxxx";
google_ad_width = 320;
google_ad_height = 50;
}
</script>
<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>

Thank you!

[levo]

Confirmed!

The ad block size is based on the width and height of the <ins>, which can be set inline, as shown here, or via CSS.

[googledevelopers.blogspot.com...]

[motorhaven]

Well, I've tried it and it's not ready by a long shot.

First, I took out the old code and pasted in the new async code. No ads showed up in the ad slot. Doubled checked to make sure it was pasted properly, and checked the HTML output.

So I took out the code and restored the old. No ads show up! Tried with several browsers, and a different computer on a different IP. No ads. So by trying to implement this it appears that it's killed display of all ads in this ad slot, both sync and async.

So based on my experience I recommend you try this with a test ad slot, not an existing slot.

[levo]

So I took out the code and restored the old. No ads show up!

Probably noting to do with new/old code. I think Google just ratelimited your IP.

The old code stops page rendering, inserts an iframe and than continues, while the new code finds the ad unit and inserts the almost very same iframe - without stopping.

[motorhaven]

As noted I also tried from a different different IP - not even close to the other range, from a completely different PC. After posting, I called a friend up (different state) and asked him to browse. Couldn't see it either, verified it was in the HTML. Other pages not using that ad slot displayed ads okay.

But here's the kicker, about 10 minutes after this problem... the ads started showing up again in this slot. I couldn't resist trying again, changed ALL ad slots to ASYNC and they work.

A side note: like Google DFP you only need one of these even if you have more than one slot on the page:
<script async src="http://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>

So my experience is it worked, but temporarily seemed to hiccup the first ad slot I tried it on. Pretty busy site with a good advertiser and I've never seen it display blanks until this, thankfully just for a few minutes.

[netmeg]

New ads typically take at least ten minutes to start showing, and last week when I created some new ads (old style) it took over half an hour. So Google might just be running slow.

I definitely intend to start playing with this after I get past my busy season; don't wanna mess with anything right at the moment, but if it ends up causing mobile ads to load fast, I'm all about that.

[NavyCS]

Mine is working great -- make sure if you are using CSS that you specify the correct ad size you want displayed or it seems nothing will show up.

[synthese]

Not sure whether you can use external css. Although I suspect this is the long term plan. Looking at the Adsense JS code, it interrogates the element.style.width and element.style.height, and then constructs the ad call from that.

So you would have to remove the inline styles and add your own class...

Will try it out...

[levo]

Not sure whether you can use external css. Although I suspect this is the long term plan. Looking at the Adsense JS code, it interrogates the element.style.width and element.style.height, and then constructs the ad call from that.

The code looks for the inline style to be foolproof - if the webmaster didn't remove it, external styling is ignored..

[synthese]

External CSS seems to work fine, and is useful for a responsive site. So, for example you could add a class to the INS. Then you could set this class to width:320px; height:50px for your mobile layout, and width:728px; height:90px for your desktop layout. Just make sure you remove the inline width and height settings.

It seems to work fine.

Reporting is not so easy as its all coming out of a single ad unit. It would be useful to set different channels for each of the different CSS size settings.

There is no noticeable difference in performance. The new adsbygoogle.js code still makes the same calls that the old show-ads.js did. So you still get that latency as all the ads show up (typically well after the page is rendered).

However I guess the thinking is that because the new script is no longer blocking, if there was a slow adsense server or it was down, then it won't stop your page from rendering anymore.

[synthese]

@levo according to the google blog post

The ad block size is based on the width and height of the <ins>, which can be set inline, as shown here, or via CSS.

It seems they allow setting via external CSS (my emphasis added).

[NavyCS]

I know the ads show well in all the desktop browsers so far, and they show on the iPhone -- has anyone confirmed the ads show on Android devices? I know it should be a no-brainer, but I do have to ask (I don't have an Android phone).

Oh, and I have the single instance of the

<script async src="http://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>

in the head section -- works great as I said.

[motorhaven]

I have async working fine on the desktop. On my Android browser with a mobile skin the ads stack on top of each other where the last is on the page. I tried every combination of absolute, relative, clear, in and out of other DIVs, etc that I could throw at it, even went as fubar as wrapping it in a table.... 1st ad still stacked on top of the last ad.

So for now I'm sticking with the old code for mobile, but the new code is working fine on my desktop skin. Naturally YMMV depending on your template. Already scoring 94 with Pagespeed Insights with the mobile skin so it's not a show stopper for me to stick with the old for now.

[NavyCS]

lol, I don't know why I find it funny that it doesn't seem to work with the Android, but seems to work fine with everything else.

Thanks for the feedback!

[levo]

has anyone confirmed the ads show on Android devices?

Search for manymo and launch an emulator ;)

There is no noticeable difference in performance.

Move the javascript to the end of the body tag. If it is at the top, it creates the iframes when document is ready, and iframe loading delays the onload event.

[NavyCS]

Levo -- outstanding stuff. Manyno works great, Thanks!