The proxy doesn't do any rendering so this is unnecessary work.

RenderWidgets that don't composite should be created with |never_visible|=true.

Keep in mind that the proxy can be swapped with a local main frame, and in that case the RenderWidget will start to submit frames.

The other way can also happen, a local main frame that was compositing can be swapped with a proxy and will stop producing frames.

There is a slight complication where in some cases there can be a remote main frame that can later be 'swapped in' and become a local main frame, in that case the non-compositing RenderWidget will need to start compositing.

I am becoming increasingly motivated to pick up bug 419087 again to kill that RenderWidget, because it keeps causing pain working around the special case. Unfortunately, four different people have worked on that bug over three years now, and untangling RenderView from RenderWidget is still looking daunting.

FWIW, +1 to someone working on this decoupling sooner rather than later. We keep bumping into this issue in Viz developing and having to work around it. 

Re comment 5: can you explain in more detail the use-case of a remote main frame
that can be later swapped in?

A simple case for remote main frame swap is possible even without Site Isolation. If you have tab on a.com, which does window.open() to create another one with opener relationship, the two are put in the same BrowsingInstance since they can script each other. If the new tab is navigated to a new site, it will be navigated into a new process, however because of scriptability requirements, we create proxy objects for the respective windows in each process. If later on the opened tab navigates to the same site as the opener, they will be put again in the same process. In this case we will perform a RemoteFrame -> LocalFrame swap.
Let me know if I can help clarify anything else.