For most chrome windows (which aren't opaque) we didn't gain much from switching to DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL, because that just changed what used memory bandwidth.
Previously:
Chrome blit from its backbuffer to DWM's copy (1 read and write) and DWM drew from that to the screen (1 read and write).
Notably, even though the window contents were transparent, DWM didn't need to draw anything below Chrome's window to the screen. This is probably because it know that the area outside of DwmExtendFrameIntoClientArea was supposed to have black behind it, so any blending could happen in the shader.

With DirectComposition:
DWM draws from the GDI buffer to the screen (1 read and write) and DWM then draws from Chromes IDXGISwapchain to the screen (1 read and write).

Chrome's swapchain can't normally be marked opaque (until  bug 554033  is implemented), and DWM doesn't that the contents of the GDI buffer are just transparent black, so it has to draw them.

To improve performance, we could create a 1x1 opaque IDCompositionSurface, fill it with black, put it at the bottom of the DirectComposition visual tree, and scale it to the same size as the opaque part of the window. This would avoid an unnecessary read of a bunch of black pixels, though the unnecessary writes would stay there. This would require some sort of communication between the GPU process and browser process about what area of the window is actually opaque.