coop182/jquery.dfp.js

Memory Leak when refreshing ads

Closed this issue · 19 comments

cauedotnet commented

Jquery.dfp.js is the best implementation of dfp i founded, and really fits my project, but this problem is killing me. After i implemented $.dfp, memory consume start growing a lot. I am measuring this using chrome's 'heap snapshot'. I will explain better.

I only have two ads on a page, and the code is very simple. Im using the following method to create the ads:

var createUnit = function (holder, unit, dim, dfpid) {
    $(holder).append('<div class="adunit" data-adunit="' + unit + '" data-dimensions="' + dim[0] + 'x' + dim[1] + '"></div>');
    $('.adunit:not(".display-block")').dfp({ dfpID: dfpid, enableSingleRequest: true }); // false don't fix my problem too.
};

This code works very well. But the problem starts when I try to refresh the ads, using the following code.

var refreshSpaAds = function () {
setTimeout(function () {
    $.dfp();
    refreshSpaAds();
    console.log('refreshSpaAds');

}, 30000);}; refreshSpaAds(); // Normally use 60 secs...

Every time I call $.dfp(); for refreshing the ads, my memory heap increases like 15-30mb. So, in 15 minutes or less, the page overflows and brake. Chrome show a bluescreen with a dead tab image, and asks for reload all page.

My tests:

  • If i dont call the $.dfp(), the problem reported dont happens. Heap size don't change nothing.
  • If i delete and build all objects/ads, instead of calling $.dfp(), same problem happens.

Why i need to refresh?

  • I am using angular.js, a SPA js framework. I need to refresh the ads on page changes, and i want to refresh every 60 seconds.

Anyone has passed for this problem? What should i do?

Thanks.

coop182 commented

Hi there,

I suspect this could be an issue with DFP itself... have you tried implementing DFP with out my script to see if it has the same issues?

cauedotnet commented

Yes. After a lot of tests, i can say that adsense code is causing the memory overload. A lot of objects like the windows used by the ad, the string containing adsense script, and others, remains in memory heap, locked by zombie variables that cannot be accessed.

I have tried to put DFP or ad sense code with any possible implementation, regular or scripted. Every time i got a new ad, the memory increases like 10mb. I have tried to manipulate dom to clean the objects, the containers, but nothing can resolve the problem. I have tested every possible solution that i founded on stackonverflow to clean dpf iframe memory heap.

The only way the problem stops is putting the ad code in an iframe from a cross domain. Otherwise, the memory will increase dramatically. I only don't know if this is forbidden or not, since a lot of ad parters like kontextua, etc.., uses ads in iframes.

Jacketbg commented

Hey I know this is closed, but I was wandering if you (@cauedotnet) have any progress on this. I'm struggling with the same issue on a single page application, where ads are loaded via ajax in iframes. I am using Revive AdServer, but I don't think it matters. Every time I load an AdSense code inside an iframe, it injects a LOT of data into its parent (the main page) and I cannot find a way to scrape this data even after the iframe is removed... I was beginning to think I am the only one seeing this problem, but your issue gives me some hope that someone else fights with the same problem. Please tell me if you have any progress and I will try to share what I've tried so far.

jasongrishkoff commented

I'm also seeing this issue. Any updates from either of you? The memory usage just keeps climbing up and up and up.

Jacketbg commented

No progress here. Users are complaining and I've lost insane amount of time trying to counter this with no luck... There was a version of Google Chrome that lasted for about a month where the problem magically disappeared, but after the next major update it was back again :(

jasongrishkoff commented

Okay, so I think I've figured this out. I put my tags into a simple .html page, and loaded those via an iframe that I embedded on my main page. Then I set an interval to reload the contents of that iframe. However, I noticed that the memory was still climbing and climbing and climbing...

That got me thinking: what if I set that iframe source to be from a different origin? If it's cross-origin, then my understanding is that the contents of the iframe can't write anything to the parent container...

Lo and behold, using that technique has resulted in stable memory usage -- no climbing, and two ad units refreshing every 30 seconds without any problem. So yeah, problem solved???

Jacketbg commented

So you mean you are serving the iframe content from a different domain, right?

jasongrishkoff commented

A subdomain, yes. Main site is http://www.website.com, with iframe coming from http://sub.website.com/

Jacketbg commented

Sounds like a simple but effective solution, kudos!

I'm just not sure if Google will like this, because AdSense injects trackers, beacons and other analytics into the parent and if you completely block them, I think this might trigger an alert somewhere. I can also be paranoid about this, who knows :)

jasongrishkoff commented

I share your concern. I'm checking with my ad guy on this. Those trackers, beacons and other analytics are the root cause of the memory leak so uhh... yeah. I hate ads -- wish I didn't need to use them as the revenue source on this site :(

soreng commented

Hi,

Just read the terms of use, and you will find your solution is not valid or allowed by Google :-(

On 4. aug. 2016, at 16.51, Jason notifications@github.com wrote:

I share your concern. I'm checking with my ad guy on this. Those trackers, beacons and other analytics are the root cause of the memory leak so uhh... yeah. I hate ads -- wish I didn't need to use them as the revenue source on this site :(

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

jasongrishkoff commented

Could you please expand on that? And what if they're actually from the same domain (www and www), but you use an Nginx header to prevent same-origin policy on the iframe content?

halajohn commented

Hi, you are not alone, I saw this problem, too. I have tried to "undefine" or "remove" any resources I can find in the parent html, but the memory usage of the refreshed ads are higher and higher. I also tried to not refresh the ads, but destroy the ads slots, and recreate all the stuffs from scratch periodically, but the problem is still there. The final solution of mine is to not refresh the ads, just use non-refreshed ads, and that will definitely decrease the incomes from ads. I hope Google can fix that ASAP, after all, both products (chrome, ads) are made by them.

jasongrishkoff commented

Update: loading your ads inside an iframe is indeed a violation. The solution was working amazingly to eliminate the memory leak issue; now I'm left trying to figure out an alternative.

I'm exploring their "sandbox" tag: googletag.pubads().setSafeFrameConfig({sandbox: true});

So far, doesn't seem to be doing much to stop the memory leak. Will report back.

mctaggaj commented

@jasongrishkoff Did you have any success with the SafeFrame approach?

jasongrishkoff commented

Nope, but I settled on a solution that has been really effective:

  1. Set up your ad tag on a simple .html page
  2. Host that .html page on a subdomain
  3. Load it on your root domain using an iframe

The logic is that the reason there are memory leaks is because the ad scripts write a whole bunch of content to the DOM of the root domain. However, if they are loaded within an iframe on a different subdomain, they are unable to write to the root domain because of cross-origin restrictions. As such, they can't inject any of their tracking software into the main page.

When you want to reload the iframe, simply 1) set src to "about:blank"; 2) remove the iframe; 3) re-append the iframe with the src set to your sub-domain .html page. This should clear the DOM of any memory footprint left by the ad.

Have been using it for a couple months now and it seems to do the trick :)

josephfoulds commented

Hey @jasongrishkoff,
We too are experiencing a similar issue with memory leakage in DFP refresh inventory. Doesn't your proposed solution here violate Google TOS?

I'm wondering if anyone else has made any progression in this area?

jasongrishkoff commented

It might. I'm not positive. It has also caused issues for me with one or two advertisers cutting me off because they couldn't plaster their cookies and tracking code all over my users. Currently exploring alternatives, but so far coming up short.

Deleted user commented