If we throttle, not stop, it should not affect the first frame, right?

Imagine we push no more than one frame per 3-second unless the load is complete, this can ensure the fast first frame, and less unnecessary update.

I guess I should've worded that better, I meant the first useful frame. Its hard to tell in the compositor about when we have rendered something useful. So on a good network, if we get a commit request really quickly and we push a frame which hadn't been completely rendered, and then block sending more updates until the next frame interval (say 3 seconds), we would delay the user perceived page load time.

We could possibly use some signals from blink to decide when to send the first frame, like VisuallyNonEmpty here https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/public/web/WebMeaningfulLayout.h. Not sure how good these are to depend on though.

The bug talks about investigating commit throttling on the engine. Since the investigation for commit serialization data usage has pointed out that this throttling is necessary and crbug/608888 is already tracking work for the approaches to perform this, I am closing this bug in favour of the existing bug.