Fast Lane!

Here is what we do, at a high level.  We are fairly optimized but there are many alternate routes that can obtain great performance.  Ezoic is a good example.  Avoid passbacks -- use header/server-server bidding.  Passbacks kill CPM.
We leverage Google Ad Manager as our ad server (previously known as DFP).  We use header bidding via the opensource prebid.js script.  We have roughly 5 header bidding partners in the stack.  You have to negotiate these deals one by one and can get better splits with them (20-25%).  In addition to this we fold server-server bidding into the prebid header via both Amazon (UAM in this case, https://aps.amazon.com/aps/index.html) and Media.net.  Google adsense competes with everything on a price priority level.  Basically, Adsense has incredible fill (every impression almost always filled) but not always the highest rates (and they take a ~32% cut).  ref: https://support.google.com/adsense/answer/180195?hl=en
If you are not familiar with header bidding (or server to server) it works like this.  On every page load the header bidding code (prebid.js for example) will query all your header bidding ad partners for them to "bid" on your on-page inventory in a "blind" fashion (best bid without knowing what anyone else bids).  As a part of your header, the server-server auction occurs as well where those ad networks/partners will provide their bids.  After a set time (typically you set to around 700ms or so) the auction ends and all bids are passed back to Google Ad Manager.  Google also then bids on your inventory (blind to the other bids).  The highest bid wins.  Since your header bidding ad partners typically pay more but have less "fill" you end up with a situation where they win say 10-30% of the time and pay you a lot more on a CPM basis (and you may negotiate a cut of 20-25% with them versus 32% to Adsense).  The rest of the time adsense will win and fill the remaining inventory.  The net effect is you make more.
If I had to pick one network to use if you don't have time for many others, then I'd probably pick Amazon UAM in concert with Admanager, with adsense set up in price priorty.  AUM has a solid set of ad networks they pull in, and they also allow direct Amazon ads (re-targeting, yay!) to your users which convert and hence pay well.  There are no pass-backs since in this config its actually all server-server bidding w/ Admanager and adsense competing on price priority.
So back to the forum.  Some ideas.
Mobile:
320x50 (or 100) ad above the topic but under the topic title.  300x250 ad under post 1.  Another 300x250 ad somewhere around post 8 (assume 15 posts per page).  300x250 ad under the last post but before the reply box.  On the index and forums pages, put a 320x50/100 at the top and one at the bottom.  On the forum index if you have tons of forums then place an ad in the middle between categories.
Desktop:
Do the above, but use 728x90 ads instead of 320x50/100 and 300x250.  Also ad a 160x600 ad unit on topic pages on the right.  Make sure (this is important) that in the Admanager code you have custom ad sizes for each browser width. This is important so when someone shrinks the screen and IPB hides the right column in the responsive view, that ad is not called on a page load.  That can be a major no no. You do this as follows in the page header (ref Google docs for more info.. this is just the key code elements):
for browsers wider than 980 pixels show the 160x600 pixel ad.  Else show nothing (no ad)
var mapping_skyscraper = googletag.sizeMapping(). addSize([980, 200], [160, 600]). addSize([0, 0], []). build(); googletag.defineSlot('/123456/Forums-Topic-Side', [160, 600], 'div-gpt-ad-123456-1').defineSizeMapping(mapping_skyscraper).addService(googletag.pubads()); Also, to show mobile ads versus desktop it is as simple as mapping like below, where above 768 pixels wide will show the 728x90 ad and below that will show a 300x250 ad unit (on page load):
var mapping_leader_rectangle = googletag.sizeMapping(). addSize([768, 200], [728, 90]). addSize([0, 0], [300, 250]). Now more advanced, you can do things like put conditional statements in the templates to not show certain ad units to members with post counts higher than some amount.  I find that useful to reward frequent posters.  Or you can filter by groups.  This is all custom but not that hard.
Hope that helps some.  I didn't proof my above notes too well so pardon any short hand or typos!
 
 
Note, I'm not sure on the UAM minimum page views to be accepted.  If they don't let ya in then you can certainly find many header bidding partners that will let you in.  
https://www.google.com/search?q=best+header+bidding+partners

Here is what we do, at a high level.  We are fairly optimized but there are many alternate routes that can obtain great performance.  Ezoic is a good example.  Avoid passbacks -- use header/server-server bidding.  Passbacks kill CPM.
We leverage Google Ad Manager as our ad server (previously known as DFP).  We use header bidding via the opensource prebid.js script.  We have roughly 5 header bidding partners in the stack.  You have to negotiate these deals one by one and can get better splits with them (20-25%).  In addition to this we fold server-server bidding into the prebid header via both Amazon (UAM in this case, https://aps.amazon.com/aps/index.html) and Media.net.  Google adsense competes with everything on a price priority level.  Basically, Adsense has incredible fill (every impression almost always filled) but not always the highest rates (and they take a ~32% cut).  ref: https://support.google.com/adsense/answer/180195?hl=en
If you are not familiar with header bidding (or server to server) it works like this.  On every page load the header bidding code (prebid.js for example) will query all your header bidding ad partners for them to "bid" on your on-page inventory in a "blind" fashion (best bid without knowing what anyone else bids).  As a part of your header, the server-server auction occurs as well where those ad networks/partners will provide their bids.  After a set time (typically you set to around 700ms or so) the auction ends and all bids are passed back to Google Ad Manager.  Google also then bids on your inventory (blind to the other bids).  The highest bid wins.  Since your header bidding ad partners typically pay more but have less "fill" you end up with a situation where they win say 10-30% of the time and pay you a lot more on a CPM basis (and you may negotiate a cut of 20-25% with them versus 32% to Adsense).  The rest of the time adsense will win and fill the remaining inventory.  The net effect is you make more.
If I had to pick one network to use if you don't have time for many others, then I'd probably pick Amazon UAM in concert with Admanager, with adsense set up in price priorty.  AUM has a solid set of ad networks they pull in, and they also allow direct Amazon ads (re-targeting, yay!) to your users which convert and hence pay well.  There are no pass-backs since in this config its actually all server-server bidding w/ Admanager and adsense competing on price priority.
So back to the forum.  Some ideas.
Mobile:
320x50 (or 100) ad above the topic but under the topic title.  300x250 ad under post 1.  Another 300x250 ad somewhere around post 8 (assume 15 posts per page).  300x250 ad under the last post but before the reply box.  On the index and forums pages, put a 320x50/100 at the top and one at the bottom.  On the forum index if you have tons of forums then place an ad in the middle between categories.
Desktop:
Do the above, but use 728x90 ads instead of 320x50/100 and 300x250.  Also ad a 160x600 ad unit on topic pages on the right.  Make sure (this is important) that in the Admanager code you have custom ad sizes for each browser width. This is important so when someone shrinks the screen and IPB hides the right column in the responsive view, that ad is not called on a page load.  That can be a major no no. You do this as follows in the page header (ref Google docs for more info.. this is just the key code elements):
for browsers wider than 980 pixels show the 160x600 pixel ad.  Else show nothing (no ad)
var mapping_skyscraper = googletag.sizeMapping(). addSize([980, 200], [160, 600]). addSize([0, 0], []). build(); googletag.defineSlot('/123456/Forums-Topic-Side', [160, 600], 'div-gpt-ad-123456-1').defineSizeMapping(mapping_skyscraper).addService(googletag.pubads()); Also, to show mobile ads versus desktop it is as simple as mapping like below, where above 768 pixels wide will show the 728x90 ad and below that will show a 300x250 ad unit (on page load):
var mapping_leader_rectangle = googletag.sizeMapping(). addSize([768, 200], [728, 90]). addSize([0, 0], [300, 250]). Now more advanced, you can do things like put conditional statements in the templates to not show certain ad units to members with post counts higher than some amount.  I find that useful to reward frequent posters.  Or you can filter by groups.  This is all custom but not that hard.
Hope that helps some.  I didn't proof my above notes too well so pardon any short hand or typos!
 
 
Note, I'm not sure on the UAM minimum page views to be accepted.  If they don't let ya in then you can certainly find many header bidding partners that will let you in.  
https://www.google.com/search?q=best+header+bidding+partners

My vote is to follow the web standard versus having a "heavy" native/custom solution. It's easier on IPB to maintain and better for speed overall. 

That's pretty awesome.  We have a fairly tech neutral audience and chrome is nearly 50% of our users.

Agreed.  Native is better than custom.

UserPhoto template... these changes will ad it for basic user photos across the suite.  In post images are TBD on updating...
{{if $member->member_id and \IPS\Member::loggedIn()->canAccessModule( \IPS\Application\Module::get( 'core', 'members' ) )}} {{$memberURL = ( $warningRef ) ? $member->url()->setQueryString( 'wr', $warningRef ) : $member->url();}} <a href="{$memberURL}" {{if $hovercard}}data-ipsHover data-ipsHover-target="{$memberURL->setQueryString( 'do', 'hovercard' )}"{{endif}} class="ipsUserPhoto ipsUserPhoto_{$size}{{if $classes}} {$classes}{{endif}}" title="{lang="view_user_profile" sprintf="$member->name"}"> <img src='{$member->photo}' loading='lazy' alt='{$member->name}'> </a> {{else}} <span class='ipsUserPhoto ipsUserPhoto_{$size} {{if $classes}}{$classes}{{endif}}'> <img src='{$member->photo}' loading='lazy' alt='{$member->name}'> </span> {{endif}}  

My competitors are always listing above us for these and it builds credibility (for them). You can limit the except sizes top help. 
 
In general I disagree on it hurting you.  Here is a quick example where the only things above the fold is the rich snippet Google grabbed.  All other listings are below the fold -- which is becoming common.  The only thing that competes is video (a big push for Google... and popular for users these days).
 

 
and another example:

Yeah, I mean the reality is Google will just get the info from a different site if you don't supply it. Your strategy isn't going to help your site overall.
I, for one, will say that while I browse the snippets Google shows like anyone else, I almost always also click into the site if the information seems relevant. The short snippet in a search result is rarely enough to answer whatever it is I'm searching for.

Do we know when 4.4.5 will be released? I've been tracking many comments by IPB staff that mention upgrades to improve mobile page speed. At least for me, my mobile performance is abismal compared to desktop. Too many uneeded JavaScript and stylesheets being loaded. Also just a DOM heavy pageload. Small things like the notification sound Js/audio loading when it doesn't need to. 

I'll state the obvious. We can complain (Google doesn't care) and get less visibility or jump on board.  If you don't rank on the rich snippets then you are even farther down the page with less clicks. I'm pragmatic.
You will note that the URL is in plan site below the snippets which are only partial info.  It's not that bad. 

Hi there.  I was invited to Google several times over the last year as part of a group of Publishers and one of my major take aways is that AMP is a big deal in the Google sphere. Both for SEO and monitization. 
Does IPB have any intention to make topics linked from Google Search on Mobile, AMP friendly?  It would be a huge win speed wise and SEO ranking wise, relative to their mobile first approach. Same comment on Pages.
WordPress is killing us since they have a plug-in to bring AMP to their pages with relative ease. Many of my competitors use both that and YOAST quite successfully. 
 
 

@bfarber
Any comments from IPB Staff?

Bump. 
@bfarber

Hi there.  I was invited to Google several times over the last year as part of a group of Publishers and one of my major take aways is that AMP is a big deal in the Google sphere. Both for SEO and monitization. 
Does IPB have any intention to make topics linked from Google Search on Mobile, AMP friendly?  It would be a huge win speed wise and SEO ranking wise, relative to their mobile first approach. Same comment on Pages.
WordPress is killing us since they have a plug-in to bring AMP to their pages with relative ease. Many of my competitors use both that and YOAST quite successfully. 
 
 

Hi there.  I was invited to Google several times over the last year as part of a group of Publishers and one of my major take aways is that AMP is a big deal in the Google sphere. Both for SEO and monitization. 
Does IPB have any intention to make topics linked from Google Search on Mobile, AMP friendly?  It would be a huge win speed wise and SEO ranking wise, relative to their mobile first approach. Same comment on Pages.
WordPress is killing us since they have a plug-in to bring AMP to their pages with relative ease. Many of my competitors use both that and YOAST quite successfully. 
 
 

To double down, I'm not talking about an interactive page... just page 1.  You can "click to read more:" and go to page 2 or more.  Since page 1 gets all the link juice we want it to be as fast as possible == AMP.

Hi there.  I was invited to Google several times over the last year as part of a group of Publishers and one of my major take aways is that AMP is a big deal in the Google sphere. Both for SEO and monitization. 
Does IPB have any intention to make topics linked from Google Search on Mobile, AMP friendly?  It would be a huge win speed wise and SEO ranking wise, relative to their mobile first approach. Same comment on Pages.
WordPress is killing us since they have a plug-in to bring AMP to their pages with relative ease. Many of my competitors use both that and YOAST quite successfully. 
 
 

Hi there.  I was invited to Google several times over the last year as part of a group of Publishers and one of my major take aways is that AMP is a big deal in the Google sphere. Both for SEO and monitization. 
Does IPB have any intention to make topics linked from Google Search on Mobile, AMP friendly?  It would be a huge win speed wise and SEO ranking wise, relative to their mobile first approach. Same comment on Pages.
WordPress is killing us since they have a plug-in to bring AMP to their pages with relative ease. Many of my competitors use both that and YOAST quite successfully. 
 
 

Do we know when 4.4.5 will be released? I've been tracking many comments by IPB staff that mention upgrades to improve mobile page speed. At least for me, my mobile performance is abismal compared to desktop. Too many uneeded JavaScript and stylesheets being loaded. Also just a DOM heavy pageload. Small things like the notification sound Js/audio loading when it doesn't need to. 

The mobile version can become very fast if IPS changes the concept of CSS rules.
If CSS basic rules are created for mobile version, the responsive design  only contains changes to the desktop, for example ...
.ipsRule {....} @media screen and (min-width:768px) {.ipsRule {...}} @media screen and (min-width:980px) {.ipsRule {...}} @media screen and (min-width:1280px) {.ipsRule {...}} @media screen and (min-width:1440px) {.ipsRule {...}} etc using a media query with only min-width will shorten the volume of CSS and improve the performance of browsers while processing CSS rules.
But, in this version 4.5, I think this will not be done.

Agreed we should have more focus on this area. Would help a lot. 

I have figured out that there is no meta description for the links with /page/XXX at the end
topics http://www.example.com/forums/topic/17589-whatever/page/XXX article comments http://www.example.com/articles/category/article/page/XXX blog entry http://www.example.com/blogs/entry/17589-whatever/page/XXX and so on I have lot of pages where Sign in... and menu structure is taken into description by Google instead of the content of the page. It looks messy in search results and does not attract users to click. 

Up vote x100. For this if us that send millions of emails a month... this is a HUGE savings. 

Just to chime in on "monetization" (which I hope we all agree is important).  I was over at Google the other week for a publisher meeting and the topic came up.  BLUF, PWAs are challenging to monetize well.  In the end, this is a serious consideration for any publisher and not something to be ignored (or risked) chasing trends.  They were supportive of PWA but urged caution.

I think IP Pages should have an option to allow AMP pages. That or at least allow a customer header element to point to an alternate AMP page manually.  The Pages product directly competes with WordPress which has this already.
Be the way. I totally am not a fan of a stand alone web app. It would likely leave out a TON of my community built around IP Pages and custom areas. Folks would not discover them on the app. Also, advertising revenue and customization would take a huge hit.