Fast Lane!

Not filling every impression is not great. AdSense (or if they are large, AdX) should always cover your fill.

You need to make sure the ad is not called and shown (but hidden by css). Do you know what folks are in your header bidding stack? I'm sure they gave you an ads.txt so you should be able to see it there -- if not directly in the header. They are likely taking a cut of the revenue is my guess.

Note 2: I directly edit the templates and don't use IPBs ad features. It only slightly slows down upgrades but gives you more control IMO. You most certainly need to do this to add anything to page headers, which is required for Ad Manager and prebid. Set it not to show when the width is too small. Also set the ad not to show (see my above note).

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

How many page views do you have per month? AdSense is the obvious place to start but there are much more advanced options including serving your ads via DFP (now called admanager). Getting that set up in the beginning will greatly facilitate future scaling for direct sales as well as header bidding and more advanced features. Put ads at the bottom of your topics. That will perform well. 728x90 on desktop. 300x250 on mobile. On the desktop view ad 160x600 on the right (sticky only if allowed by network).

Lazy load is only for images; not ads. Google would never torpedo their core product.

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.

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.

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:

Has the IPB staff seen this. Looks like a huge boon to forums in a world where we often don't get the best attention: https://www.google.com/amp/s/searchengineland.com/google-confirms-new-faqs-qa-and-how-tos-for-search-results-snippets-303116/amp

FYI. My sitemap doesn't include all my topics and is often days behind because I'm told of a known issue for large sites where the task process is too slow.

@bfarber Any comments from IPB Staff?

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}}

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.

Bump. @bfarber

Google disagrees. And they provide $$ to keep the lights on for the Publishers that run the sites. That matters. A lot. Oh and they rank you better too with AMP.

Bum bump. This would be huge! IPB is sooo heavy on mobile. This would help a lot.

How significant is this change?

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.

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.

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.

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

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

Interesting. How about revenue? Any net improvements that make the loss in speed worth it?