New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 467709 link

Starred by 76 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Jun 2016
EstimatedDays: ----
NextAction: ----
OS: Android , All
Pri: 2
Type: Bug

Blocked on:
issue 476158
issue 487937
issue 490465
issue 493357
issue 493359
issue 501642

Sign in to add a comment

Swiffy-converted Flash to HTML5 animated Google AdSense ads cause terrible performance jank in Chrome for Android

Reported by, Mar 16 2015

Issue description

Steps to reproduce the problem:
1. Go to or another site that uses AdSense.
2. Observe an AdSense ad with animation (reload a few times in case all are static).
3. Experience the most awful page scrolling jank and freezes until the ad stops moving.

What is the expected behavior?
No performance hit to page scrolling when animated ads load and show.

What went wrong?
Swiffy-converted Flash to HTML5 animated Google AdSense ads cause terrible performance jank in Chrome for Android

I've been trying to figure out what's causing absolutely awful scrolling and general responsiveness performance issues in Chrome on lately, and my conclusion is that it's Swiffy that is powering some of Google's AdSense ads with animations. Recently, Google announced that they're now auto converting all Flash ads to HTML5, presumably with Swiffy, but it seems like their own browser takes a huge hit any time it sees them.

The animations themselves are very choppy. We're talking about 2fps.

The browser jank increases 1000%. I tried pausing the Chrome debugger attached to a mobile device via USB debugging and caught Swiffy code using touchstart and touchend, which are known for causing performance issues.

Any time a page loads without animated ads, the performance is fine.

We even tried to apply translateZ(0) to try to force ads to go to the GPU, but don't seem to have much success there.

Any ideas for optimizations that could force ad rendering on the GPU or help otherwise?

Did this work before? Yes Chrome 40 for Android (not 100% sure)

Chrome version: 41  Channel: stable
OS Version: 5.1
Flash Version: N/A

Cross-posted this to,!category-topic/chrome/report-a-problem-and-get-troubleshooting-help/android/Stable/WTm2NQVPz6k, and!category-topic/adsense/technical-errorsbugs/Hn0E2VsIdug.

A bunch of confirmations and further discussion here: Perhaps Chrome 41 (and not fixed in 42) introduced these bugs, since the site was relatively fluid until recently, which coincides with the 41 release.
Status: Assigned

Comment 2 by, Mar 16 2015

After polling several users of Chrome 40, apparently the issue is present there too, so please disregard the Chrome 40 regression note above.

Here's one user's observation:
"+Artem Russakovskii​​ I just tested this out and found the following behavior: 

-Performance was smooth immediately after loading up this article. Within 10 seconds, smooth scrolling degraded to around a 2 to 3 second delay in responding to inputs. It seemed to correspond to the loading of some of the ads, but the Comments section was also having trouble loading, so I don't feel confident pointing to one over the other

-It seems to happen on the main page as well, as performance took a heavy dip the instant one of the ads loaded

-In both cases, the ad seemed to be from Chevrolet. Not sure if that's relevant, but I did consistently see it begin to load each time things went to hell

-I am using Chrome for Android stable

Hope that all helps!"

Comment 3 by, Mar 17 2015

Just ran into the ad that's causing the described behavior when embedded on the page again. This time, I saved as much info about it as possible.

Screenshot, after it's done animating (extremely slowly):

The Swiffy object is here (mirror:

The full HTML of the iframe is here: (mirror:, but I'm not seeing the image if I just load it in the web browser. But hopefully, this is enough for you to go on.

Comment 4 by, Mar 17 2015

Thanks for the very detailed report.  I've managed to load the ad on my Nexus 5 by copy-pasting into a .html file, but I'm not seeing the jank when I try to pinch-zoom on it while it's animating.  Maybe it's device-specific -- what device are you seeing this on?

Comment 5 by, Mar 17 2015

FWIW, my current theory is that the blur effects on the ad <canvas> might be very slow to GPU-accelerate on your device.  If so, then setting "Disable accelerated 2D canvas" in chrome://flags might actually improve the performance.  (Let me know if that's the case.)  I'm not sure there's a method for webmasters to manually disable GPU acceleration on particular content, though.

Comment 6 by, Mar 17 2015

I'm not sure a single ad on its own is going to exhibit the symptoms - the best bet would probably be trying to load until you see a similar ad, or just saving the AP homepage into a local file and manually replacing the ad (heck, just do all 4 mobile ones for maximum enjoyment).

We're getting bombarded with unhappy users - I'm really curious if it's something recent that made it so much worse.

Happening on OnePlus One running KitKat, Nexus 6 running Lollipop 5.1, and other devices. Even beefy ones, as you see.

I'll try to record a screencast showing just how bad it gets on an actual page.

Comment 7 by, Mar 17 2015

OK, I managed to catch a similar ad to the one above, though not nearly as bad as the GMC one. You can see the page performance decreases as soon as the ad loads and starts playing and at some point the flings have a delay of 1-1.5 seconds. With the GMC ad, they were even worse. The best demo of the lag starts at 1:50. You can see the fling touches in the video, then freeze, then the fling starts.

These actually remind me of performance issues when using touchmove which we have observed in Chrome during development a few months ago. We had to hunt down and remove all calls to touchmove as they were lagging the flings by up to 4-5s. Since Swiffy uses touch events too, I think it's a good place to start looking at. Or they could just be symptoms of something different that's wrong, as #5 suggests.
It's not only performance...
Quote from G+:

+Artem Russakovskii​ what's even worse: I'm often redirected to ad links when just scrolling around in the page. If I touch the ad while scrolling and release my finger, the link sometimes open.
This started with these swiffy ads a couple of days ago and makes me rage

Comment 9 by, Mar 17 2015

@aelias: Could you upload a trace?

Comment 10 Deleted

Any progress here, guys?
+skyostil, +alexclarke: Do we expect any of the load-related scheduler optimizations to help here?

archon810: Much work has been done between M41 and M43 to increase responsiveness of scroll gestures under heavy content load (e.g., html5 ads). Touch handlers are indeed a source of jank, as Chrome has to block on an element's touchstart and touchmove handler before it can proceed with scrolling. This was likely made more apparent with the removal of the touch timeout on mobile sites over a year ago, but the timeout was really just a crude bandaid over the general problem of poor scheduling and pathological JS/resource dispatch. 

It would be really helpful if you could capture a trace of the suspect behavior (

That said, this is likely not a regression in Chrome, and it might be worth reaching out to the ad providers (and Swiffy directly) to see if we can't optimize (or validate) these flash conversions.
I managed to pull a trace that shows the janky response on (taken with a Nexus 5 and Canary 43.0.2352.0). A couple observations:

1) Compiling takes 500ms (at the 5.2s mark). Currently this cannot be interrupted, and will inevitably cause jank if the user tries to interact with the page during compilation.

2) Compilation of takes ~250ms, and initial execution after compilation takes ~300ms. Again, these long-running JS compile+execute chains will cause jank if the user decides to interact with the page at inopportune times.

3) rAF calls are taking ~100-200ms. It's not immediately clear what all is taking place in this animation callbacks, but I suspect much of it is the work of animating these swiffy-based ads (we should dig into devtools to see what is so expensive). Any operation that is 200ms will jank the start of scrolling if there are touchstart/touchmove handlers.

4) We're triggering "idle" work between touchstart and the first touchmove, which can cause long-running operations that delay scrolling (e.g., at the 6.1s mark we execute a 300ms long JS task during our idle period). Ross: I believe there are plans to defer such idle work when the touchstart response is pending?

So, in general, swiffy appears to be a relatively heavyweight solution that is not (yet?) optimized for mobile devices. Morever, there are 4 (yes 4!) giant swiffy ads on the landing page of, each of which consumes more than half the viewport, all of which are dynamic. 
2.1 MB Download
For reference, I loaded in Firefox and Firefox Beta on my N5, and they both exhibit even more severe perf degradation after all 4 Swiffy ads have loaded.
Aha, so after Swiffy is fully loaded, I see 2 glReadPixels calls per rAF call. This is both contributing to the excessive rAF time, but it's also a prohibitively expensive (synchronous) call than can easily jank scrolling once it has started.
I think the origin of glReadPixels is likely a canvas getImageData call from Swiffy.  eugeniom@, do you know what Swiffy needs getImageData for?  That's really slow when canvases are GPU-accelerated and it would be good to avoid it if at all possible.

If it can't be avoided, then maybe a workaround we could consider on the Chrome side would be to disable GPU acceleration when getImageData is heavily used (since the canvas is effectively being used as a software canvas anyway), although I'm not sure there's a clean way to do that.
re #15 point 4. This isn't actually an idle task.  The scheduler is within an idle period, but the task which is being executed is just a regular task (in this case running some JS code which takes 300ms). Idle tasks only ever run if there are no other tasks to run, and we never schedule long-idle periods between touchstart/touchmove handlers. However we can trigger a "short" idle period but this would always have a deadline of less than 16ms. In any case, the issue here seems to be just the amount of JS code having to be executed by swiffy.  Is there any way Swiffy could chunk up the work they need to do into ~6ms chunks? That way we could schedule it much better (and potentially they could use the requestIdleFrame proposed API to ensure the JS execution doesn't jank the page)?
Some suggestions: if disabling canvas acceleration is ameliorating the problem, it's likely the getImageData() calls which are problematic. As an interim solution, you could try tiling your canvas rendering to 256x256 or smaller to force canvas rendering into software. This is not the best solution however, since that heuristic is something we may change in the future.

What could be a good path forward is the work that Justin is doing with display list canvas, where we hope to be able to detect the getImageData() cases and never go to GPU rasterization at all in those cases (since the roundtrips often make this a net perf loss).

Comment 22 by, Apr 15 2015

I think it is worth trying to fully enable display list 2d canvas on Android (equivalent to using the --force-display-list-2d-canvas command line flag.
Do we have any telemetry benchmark pages that have Swiffy-like elements? If not, can we fully capture a prototypical Swiffy page or two to help monitor progress?

Comment 24 by, Apr 15 2015

woudl love a beginnings of a tough_ads_cases pageset

Comment 25 by Deleted ...@, Apr 29 2015

I'm getting this issue too, been having it for sometime on my Nexus 5. Only affects Chrome and Opera (same engine?)

This is the only error that always appears during the freezing.

Chromium E []
GpuCommandBufferStab::OnAsyncFlush, LatencyInfo
Vector size 106 is too big.

Sometimes the vector size will be 105 or 126, no other issues with any other software.
6 weeks have passed since this issue reported, but there still isn't any solution or fix. Please just disable those poor ads. The converted ads ruins Chrome experience.
aelias: any progress on this?
Justin is OOO this week and in SYD the next two, so we'll likely only be getting sporadic updates on display list canvas for the next while.
Chrome vs opera mini, chrome very lag.
Any news on that bug? I started to hate Chrome because of it. Shouldn't it be priority bug to be fixed?

Comment 32 Deleted

Comment 33 by Deleted ...@, May 27 2015

This bug is so annoying it made me switch to Firefox. I hope you fix it ASAP or more people will do the same as i did. 
Labels: Hotlist-Ads
Sincere apologies for the lack of updates.

Both the Chrome and Ads teams are working on this issue which is a high priority item.
We've identified some actionable changes (Chrome-side and Swiffy-side) and more will come.

I'll make sure we tag similar issues and proposed changes with Hotlist-Ads so you can follow along or help us confirm a given change had a positive impact. 
Status: Started
Since this is more a meta bug than a specific work item, I'll take point and continue to help the teams identify actionable changes.
Blockedon: chromium:490465
Blockedon: chromium:476158
Blockedon: chromium:493357
Blockedon: chromium:493359

Comment 40 by, Jun 18 2015

Blockedon: chromium:501642

Comment 41 by Deleted ...@, Jun 24 2015

Any news? 
Blockedon: chromium:487937
Here is a high level summary.

Chrome side:
 -  issue 493357 : benchmark of typical ads running on actual devices: done.
 - issue 493359: investigate root causes for the subset of ads that underperform: on-going.
 -  issue 501642 : add filter support to 2D canvas to accelerate some of the FX used in Swiffy ads: on-going.
 -  issue 487937 : stop calling requestAnimationFrame for offscreen iframes: we initially thought that the wins would be weak but further investigation indicates that this might be impactful => triaging.

There are other items that we are exploring but it's too early to tell if these matters. If you have other examples of poor user experiences let me know as we might find other reasons beyond Swiffy ads.

Swiffy side: a lot is happening but I will leave further details to the discretion of the team's lead.

Comment 43 by, Jun 25 2015

Regarding rAF being heavy for offscreen frameS: I believe we should consider the merits of that work *against* increased focus on viewability apis. We already know we need that, and if we had viewability then swiffy wouldn't need to hammer on RAF in the first place. That is, one piece of tech helping two things. Versus us pursuing two avenues at once.

Comment 44 by, Jun 26 2015

filter support in 2D canvas just landed:

To use it, you must first enable "Experimental Canvas Features" in chrome://flags

For feature detection, just check for the existence of a 'filter' attribute on CanvasRenderingContext2D.

Example of how to draw a blurred image into a canvas:

ctx.filter = 'blur(5px)';
ctx.drawImage(myImage, x, y);
ctx.filter = 'none';

I would appreciate feedback on how well this feature helps Swiffy.
FWIW: Firefox has implemented this last year and they intend to ship soon. Apparently their main motivation to ship this is SWF emulation performance, just so you know.

There are still a few bugs and performance improvements that I need to take care of, but the feature is already mostly usable. For more details, see the blocking bugs linked to  issue 501642 
An update:

About  issue 487937  in light of comment #43.

I think there was some slight misunderstanding and after further discussion the scheduler-dev team has agreed to take care of it.

About Swiffy: the team has made a lot of progress on their new engine and have confirmed major improvements on Chrome*.

*: sadly, Chrome for iOS will not see the same benefits due to iOS limitations.
Great news! When are we going to see this major improvements in the form of an app update?

Comment 47 by Deleted ...@, Aug 28 2015

any improvements in any final app yet?
Some initial improvements have landed on the Dev channel (e.g.,  bug 490465 ) and more are being worked on. Please check the bugs that this one is blocked on for more details.
Labels: Hotlist-Recharge
This issue likely requires triage.  The current issue owner maybe inactive (i.e. hasn't fixed an issue in the last 30 days).  Thanks for helping out!


Comment 50 by, Sep 24 2015

This patch that just landed should help a lot by elimination GPU readbacks:
Nice, when can we expect it in Chrome Dev for Android for testing #50?

Comment 52 by, Sep 24 2015

Next Dev channel release should have it. The release schedule is not public as far as I know, but the dev releases are approximately weekly. 
Finally, less lag on AndroidPolice haha :)

Any progress?, news?
We have shipped canvas filters in Chrome 52 (currently in beta). So that should allow swiffy to do blurs and other similar effects super fast.
Labels: -Hotlist-Recharge OS-All
Status: Fixed (was: Started)
A lot of progress has been made on both front.

For Swiffy, not only significant performance improvements but also major design changes to play nicely (e.g. dropping frames and quality if the creative is too demanding for the current device/website context).

On the Chrome side we have a lot more coming for other aspects of third party performance. To just name two of the approaches we are taking:
 - Interventions: see,
 - APIs such as Intersection Observer and Passive Event Listeners (shipped) [1]

Please file bugs if you can find problematic cases: poor responsiveness, slow loading user experience (taking too long to display what matters to the user), janky/low-fps scrolling... 

Hopefully it won't be Swiffy anymore: let me tentatively close this bug.


Sign in to add a comment