Choose a GPT mode and tag type
The primary decision you need to make when tagging your pages with Google Publisher Tags is whether to use asynchronous or synchronous rendering. You’ll also need to decide whether you want to fetch all ads in a single request and which ad units and targeting criteria to apply.
Generally, we recommend using asynchronous rendering with single-request mode enabled. This combination offers the best page load experience and guaranteed roadblocks.
Ad tag coding style options
- 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. This is the most user-friendly tagging option.
- Synchronous: This tag type is intended for ads that don't render properly into frames, including expandable or interstitial ads. Synchronous tags load ads simultaneously to the content of your page. Unlike asynchronous tags, synchronous mode doesn't reserve the ad space.*
- 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.
Learn more about the differences 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 and synchronous 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.
Another reason to use asynchronous rendering is if you want to implement video companion dynamic allocation, which does not work with synchronous rendering (see Create companion tags for more information). Still another is if you'd like to refresh ad slots using
pubService.refresh(slots), which 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. However, it is possible to load the library synchronously but render the creatives asynchronously.
- 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 on the main page 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 on the main page. 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.
You can use asynchronous tags on some pages of your website and synchronous tags on others. This might be desirable if, for example, you typically use asynchronous tags but are running a campaign that uses rich content ads that do not work well with friendly iframes. In that case, you could use synchronous tags only on the pages to which that particular campaign will serve, and asynchronous tags everywhere else.
Here are some examples of synchronous and asynchronous tags.
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.
* 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.