OK educate me. Why would their be any difference in revenue between serving the ads via ASYNC delivery or SYNC delivery?
Why do you draw a distinction? It's just how the script loads.

I can't explain why, but after extensively doing A/B testing during a period of 6 months. I noticed that the SYNC code (on desktop) is having (in my case) a 20% higher performance than the ASYNC (same CPC but higher click rate). I have no idea why.

I also notice that using the SYNC code, I no longer have twice the same advertiser showing on two different spots. While , when using the ASYNC it happens frequently. May be this explains the better performance. I don't know.

I checked both codes again. Both of them create almost identical iframes (just different methods), both of which send almost identical request to googleads.g.doubleclick.net/pagead/ads

I think you're using wrong code for async. Google's async code doesn't use document.write, I believe you're using synchronous code's js url (pagead2.googlesyndication.com/pagead/show_ads.js) instead of async code's js url (pagead2.googlesyndication.com/pagead/js/adsbygoogle.js) for async.

@Peter_S a likely reason why non-sync performs better than ASYNC is that non-async blocks the page rendering while the ad code is requested. So the user sees nothing, or very little on the screen while the ad loads. Then once the ad is loaded and rendered the page continues to load. So again, the user then sees an ads with little to nothing on the screen. Finally the page loads and the user can scroll down the page and interact with it normally.

With the async ad, the page doesn't wait for the ad request. The page is loaded while the ad is requested. Should there be a delay in the request, then the page will be fully loaded before the ad is rendered. So the user will interact with the page and never see the ad. If the user never sees the ad, then the user can't click the ad and therefore you end up seeing a difference in performance.

But be weary, blocking the page rendering to load an ad will have a direct impact on page speed, a ranking factor. So you may perform better but this may be at the cost of a drop in ranking. Ideally, one should aim to provide ATF content that will keep the user focused on the viewable part of the page long enough for them to see the async ads.

@NickMNS, yes I know all this, but in practice I see no difference at all. I am using the throttling mode of Google Chrome to simulate all kind of bandwidth, and there is no different from a human perception point of view, between the SYNC and ASYNC code The only blocking part is the loading of the js code which then creates the iframe element. It's done in a fraction of second, nothing which can be noticeable by a human.

Same here as with Peter: from Analytics, I saw practically no difference in page load time, document complete time, or any other statistic. And none of my users have commented on the ads being slower or anything.

My ad management rep suggested that I change it, though, because I had been complaining about low revenue numbers, and I did so on 3/13/17. On 3/14/17, my revenue had increased 48%! And it stayed around there until 4/3/17.

As for the Javascript warning that I mentioned, I'm definitely loading it in the SYNC format (I'm loading the ads at the bottom of the page and moving the innerHTML; probably not how I'll do it when I go live, but there's hefty discussion here: [webmasterworld.com...] ). But in addition to the warning I posted before, I'm also seeing this one:

Uncaught Error: No ad ins element found
at V (impl_v38.js:9)
at hb (impl_v38.js:15)
at impl_v38.js:28
at xa (impl_v38.js:7)
at impl_v38.js:28
at impl_v38.js:29
at impl_v38.js:29

The "ins" element is used with ASYNC, too, so I'm very suspicious now.

@csdude55, if you are loading the ad code at the bottom of the page it comes to almost the same thing as you async. You're prioritizing the http requests. Is this the cause of the warning? I don't know but it can easily be tested, load the ad code at the top of the page and see what happens.

My guess is that your are seeing the uncaught error because you have script on the page that is looking for the ad code before it is loaded. Which could occur if you are only loading the ad code at the end of the page.

@Peters_s and csdude55 regarding my post above, that is the logic, what happens in practice depends on many factors, some may not be consistently repeatable.

Nick, I'll make that change tomorrow (moving the hidden banners to the top of the page). Right now I'm running a test... I moved my banners to ASYNC instead of SYNC, and I'll find out around midnight if my revenue went down. If not, I'll be almost positive that Google is now running SYNC as ASYNC, whether I like it or not.

@Peter_S, can you confirm whether you saw the same drop in revenue on April 3 or 4? If multiple people using the same criteria saw the same thing on the same date, it would mean it's not just a coincidence.

@csdude55 , my stats since the beginning of January are like roller coasters. So I can't tell if there is an "anormal" drop (or increase). As for the specific dates of April 3 & 4 , I don't see anything particular, in fact these two days were slightly higher than the days around. But again, my stats are fluctuating so much, that it might not mean anything at all. (using SYNC).

Now, the thing is , it seems you are using a complex method to integrate your ads into your page, with the loading at the bottom, and then placement elsewhere. May be at some point there can be some kind of conflict. I mean, with the javascript, etc...