GPT request and rendering modes
Google Publisher Tags offer flexibility in how you request ads from DFP and then render those ads on your page. Developers can view example tags to learn how to enable each mode in your code.
- Single request architecture (SRA): All ad requests for a page view are sent to DFP at one time from the header of your content, which can improve your page’s loading speed and makes it possible to guarantee roadblocks. All DFP creative types and line item types are supported by SRA, except DoubleClick Rich Media Dynamic ads. This is the recommended request mode.
Trafficking nonexistent networks using SRA causes the entire ad request to fail.
- Multi-request: Each ad request defined is sent to DFP separately from the body of your content. Unlike with SRA, multi-request tags do not guarantee roadblocks or exclusions (including competitive, same advertiser and same creative). This is the default request mode. Learn more about roadblocks
- Asynchronous: Allows your content and ads to load independently, instead of loading content and ads together in sequence. Each ad renders within an iframe that’s reserved on the page until the ad is ready to display. If a creative is slow in loading, your content does not need to wait. This is the recommended rendering mode.
- Synchronous: Loads ads in sequence with the rest of your content. Each ad renders directly on the page, rather than in an iframe, which can be useful for prestitials or passbacks but also slows your page’s loading time.
- Video companion display is not supported.
- Cannot dynamically refresh ad slots with the
- Might significantly slow down your webpages or affect mobile ad serving. Learn more
Mixing asynchronous and synchronous ad tags in the same web page is not recommended. You can use asynchronous tags on some pages of your website and synchronous tags on others, but avoid combining these rendering modes on the same page.
This combination offers the best page load experience and the ability to serve guaranteed roadblocks or competitive exclusions.
SafeFrames and friendly iframes
SafeFrame is a cross-domain iframe that enables transparent and rich interactions between page content and ads, while preventing ads from accessing publisher data. We recommend using SafeFrames and creatives compatible with SafeFrame for expansion instead of friendly iframes. Learn more about rendering creatives using SafeFrame
To minimize the chances of malicious creatives serving, we recommend enabling SafeFrame whenever possible, in conjunction with the HTML5
sandbox attribute to prevent top-level navigation. Learn more about the
SafeFrame is supported in DFP and enabled by default when using Google Publisher Tags. Ad Exchange line items from dynamic allocation also serve into SafeFrames by default for security reasons, but this setting is not configurable.
Some creatives, such as expandable ads or creatives that access your page’s DOM elements, might not render correctly in SafeFrames or other cross-domain iframes. We recommend updating these creatives to make them SafeFrame-compatible, in order to retain SafeFrame’s security benefits. If this is absolutely not an option, there are a few things you can do to allow reservation ads of this type to render properly:
- Disable rendering in a SafeFrame and thus use a friendly iframe.
- Convert custom templates to work with friendly iframes.
- Follow the IAB's best practices for iframe-friendly rich content ads.
- Use an iframe buster to serve expandable creatives.