Summary: | WebKit is too conservative in its first paint threshold | ||
---|---|---|---|
Product: | WebKit | Reporter: | Malte Ubl <malte> |
Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW --- | ||
Severity: | Normal | CC: | ap, beidson, cdumez, josephea, nham, simon.fraser, steven, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | All |
Description
Malte Ubl
2023-02-16 11:59:46 PST
They way the trade-off is described in the report makes me think that what we do now is the right choice? This is about our first paint heuristic (we don't generally refer to this being about "streaming HTML"). It would be better for someone on the rendering team to chime in on this. But the visually non empty heuristic (FrameView::checkAndDispatchDidReachVisuallyNonEmptyState) is indeed there to try and prevent flashes of white when navigating between pages, and also to save resources on paints that will be quickly replaced by other paints. The thresholds are already pretty low so I'm not sure that we should be decreasing them even more for real webpages. This is likely a different threshold than the one to prevent white-paints between navigations (I'm a big fan of that one!) Here we are talking about Safari not painting for 5 seconds+ while there is stuff to paint and other browsers paint. Are you aware of a URL that behaves better with the heuristic? Chrome's heuristic is: - paint after 65KB - paint before encountering a sync script tag in HTML body The latter triggers paints at the right time for React's and Svelte's streaming implementations, because they always emit a script tag when they flush the buffer. See https://github.com/vercel/next.js/issues/52444 for a reproducer |