GPT modes and tag types
When tagging your pages, we recommend using asynchronous rendering with single-request mode enabled. This combination offers the best page load experience and the ability to serve guaranteed roadblocks or competitive exclusions.
Ad tag coding styles
- Asynchronous: This tag type can decrease your site’s page load time by allowing your content to load while the ad is loading, instead of loading content after the ad has loaded. The way it works is that the ads render into frames that are reserved on the page until the ad is ready to display. We recommend this as the most user-friendly tagging option.
- Single-request mode: This option may allow for better page load performance in some cases. These kind of tags call all of the ads on a page at once in the header of your content, rather than requesting each ad separately.
- Synchronous: Synchronous tags load ads while blocking the rest of the content on your page from rendering. With synchronous tags, ads render into a div on the page. Depending on the creative, they may also ultimately render in an iframe inside of the div. We generally do not recommend using synchronous tags, but there are exceptions where synchronous mode is necessary.
Learn more about the different GPT modes and tag types below.
Character limits for GPT ad requests
Google Publisher Tags use the HTTP GET method to request ads, which limits the number of bytes that can be passed with each request. Ad tags using synchronous rendering are limited to 4096 characters per request. However, if the tag type is asynchronous and exceeds 4096 characters, GPT automatically uses the POST method, which increases this limit to 8192 characters.*
* The character limit increase with the POST method does not apply to ads rendering in IE versions 9, and below.
Asynchronous renderingWhat’s asynchronous rendering, and why is it recommended?
An asynchronous fetch means that the GPT code on your page does not block the HTML that follows it from loading. For example, if you have a rich content leaderboard that takes some time to render, with asynchronous tags the rest of the page will load while the creative is rendering rather than wait for it to finish, resulting in a better user experience and less perceived latency.
Asynchronous rendering supports video companion dynamic allocation, which does not work with synchronous rendering (see Create companion tags for more information). Additionally, the ability to refresh ad slots using
pubService.refresh(slots) only works in async mode (see the Google Publisher Tag API reference guide for more information).
There are two levels of asynchronous loading with GPT:
<head>tag) means that the
- Asynchronous rendering of the creatives in the
<body>section of the document. This allows HTML elements to load without waiting for the creatives before them to render.
We recommend that you load both the library and the creatives asynchronously in order to get the greatest performance benefit. This is the default setting used by the DFP Tags Generator.
We recommend using SafeFrames and creatives compatible with SafeFrame for expansion instead of friendly iframes. SafeFrame is supported in DFP and enabled by default when using GPT tags. It enables transparent and rich interactions between page content and ads, while preventing external access to sensitive data and providing more granular control over which creatives are rendered. Learn more about rendering creatives using SafeFrame
Reservations serve into SafeFrames by default, but you can disable this setting at the creative level and use friendly iframes instead.
- Convert custom templates to work with friendly iframes and work with your rich content providers to establish or obtain proper iframe-ready ad tags.
- Read the IAB's list of best practices for helping create iframe-friendly rich content ads. If these best practices are followed, most rich content ads should render properly, even in asynchronous mode.
- Implement one of two common methods for enabling expanding and floating creatives to work properly with iframes: friendly iframes (recommended) and iframe busting files, both of which are described below.
|Iframe busting file not needed.||Supported by a limited number of rich content vendors.|
|IAB has published recommendations for friendly iframes.|
|Supported by GPT async.|
GPT asynchronous mode uses iframes that are on the same domain as the main page. When the main page and the iframe are on the same domain, the iframe is a friendly iframe. Some rich content vendors, such as DoubleClick Studio, can escape friendly iframes directly, without an iframe busting file.
Before implementing asynchronous GPT you should check with your rich content vendor to make sure they support escaping friendly iframes directly. If the vendor does not support this variation, it is still possible to use an iframe busting file with friendly iframes, which is described below.
Iframe busting file
|Supported by most rich content vendors.||Publisher needs to host an iframe busting file for each rich content vendor.|
|Supported by GPT async.|
A common workaround you can use when the rich content vendor (e.g. Eyeblaster, Pointroll, DoubleClick Studio) doesn't support friendly iframes is for each vendor to provide you with an HTML iframe busting file. This HTML file needs to be placed on your server, usually the same one that serves your web site. In general, once the file is on the server, it can be used for all ads from that rich content vendor.
With this implementation, the creative is in the top frame and is able to access the page content. This is a security or privacy concern for some publishers.
When the ad serves inside of an iframe, it creates an additional iframe. The additional iframe calls the iframe busting file. The ad then uses the iframe busting file to place the creative into the top frame. The end result is the creative is on the page, outside of the iframe used to serve the ad code.
Most rich content vendors support this workaround; ask yours if they do.
Single-request architecture (SRA)Single request architecture (5:54) What is single-request mode and why is it recommended?
Single-request mode loads all ads defined in the header when the first
display() function is called, rather than requesting each ad separately inline with the ad slot. We recommend using single-request mode because grouping all ad calls into a single request allows you to guarantee roadblocks (serving all creatives from a line item together on the same page). Additionally, your page load performance may benefit from a reduced number of requests.
If you've enabled single-request mode, you can also enable guaranteed roadblocks for your network. This feature enhances the Display creatives setting in your line items by giving you the option to display 'All'. When you select 'All', DFP only serves the line item if an ad request contains enough ad slots to display all of that line item's creatives. You can enable Guaranteed roadblocks by clicking the Admin tab and choosing Features in the column on the left.
You can also set up master/companion roadblocks that guarantee that all creatives are served together or that at least one companion creative is always served with the master creative.
These features will only work on pages tagged with GPT with single-request mode enabled.
View our example tags to learn how to enable single-request mode.
All DFP creative types and line item types are supported by single-request mode. However, DoubleClick Rich Media Dynamic ads are not compatible.
We do not recommend the use of synchronous tags, because they block content from loading on a page until after the ad has loaded, which can result in increased latency and a poor user experience. Also, unlike asynchronous tags, synchronous rendering doesn't support video companion dynamic allocation or the ability to refresh ad slots using
document.write()can delay the display of main page content for tens of seconds. This is another reason why we recommend using asynchronous tags instead of synchronous rendering. Learn more about issues with 2G and
However, synchronous tags are still necessary in certain cases:
- Prestitials, which are used to render an ad before the rest of the content on a page loads, guaranteeing the ad is shown before anything else on the page. However, we discourage use of prestitials and recommend using interstitials instead, which can be loaded asynchronously and then shown between page navigations for less disruption to users.
- Pages with multi-size ad requests, where the rendering of the rest of the page's content depends upon knowing the size of the creative that is returned.
- Passback tags always use synchronous mode. However, passbacks are never the primary ad server tag on a page, so they should never block the rest of a page's content from loading.
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.
Here are some examples of synchronous and asynchronous tags.