Page MenuHomePhabricator

Mobile doesn't render until full HTML is downloaded in Chrome
Open, MediumPublic


I've been trying out to set the connectivity on my phone using TSProxy to slow down the connection to try to get stable metrics but I've seen another thing. When I look at the HAR file it looks like in practice on mobile (Chrome on Android), we will not start to render the page until the full HTML is downloaded:

Screen Shot 2018-04-27 at 10.05.20 AM.png (1×2 px, 357 KB)

Both the HTML and CSS got highest (or very high) prio but the CSS seems to always finish after the HTML is fully downloaded, so we cannot render before that. Meaning pages with a lot of HTML will be slower.

I verified by testing on Moto G4 on WebPageTest and it looks the same:

Screen Shot 2018-04-27 at 10.08.18 AM.png (596×1 px, 135 KB)

I know we touched this issue a couple of times before T125208 and at that time we talked about that the HTML had slightly higher prio than CSS (from Chrome) but now it looks that it has the same, but it still looks like the CSS never finish before the HTML is downloaded? Maybe file another upstream bug?

Upstream bug: =>

Event Timeline

Peter triaged this task as Medium priority.Jun 5 2018, 10:45 AM
Vvjjkkii renamed this task from Mobile doesn't render until full HTML is downloaded to 23daaaaaaa.Jul 1 2018, 1:13 AM
Vvjjkkii removed Peter as the assignee of this task.
Vvjjkkii raised the priority of this task from Medium to High.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed a subscriber: Aklapper.
Mainframe98 renamed this task from 23daaaaaaa to Mobile doesn't render until full HTML is downloaded.Jul 1 2018, 10:03 AM
Mainframe98 assigned this task to Peter.
Mainframe98 lowered the priority of this task from High to Medium.
Mainframe98 updated the task description. (Show Details)
Mainframe98 added a subscriber: Aklapper.
Peter renamed this task from Mobile doesn't render until full HTML is downloaded to Mobile doesn't render until full HTML is downloaded in Chrome.Aug 31 2018, 6:32 AM

Removing task assignee due to inactivity, as this open task has been assigned to the same person for more than two years (see the emails sent to the task assignee on Oct27 and Nov23). Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome.
(See for tips how to best manage your individual work in Phabricator.)

Krinkle added a subscriber: Krinkle.

Clearing out old Blocked column.

It seems Chrome might have improved to have a more optimal approach like the one we see in Safari.

But, I'm not sure. I tried quite a few different article sizes (to vary HTML payload size), and different network emulations (to vary artificial latencies) and for most combinations I tried we still see the waterfall the same way as Peter first found it.

I'm thinking that maybe with today's Chrome, it still often looks like the CSS first byte (and visual paint) are delayed by HTML completion, but maybe that is a coincidence? If the HTML is short enough, it will complete before the render can happen. And if the artificial latency is generally long, then it will take longer for the CSS bytes to arrive and thus arrive shortly after the HTML finished.

On a large article (like Obama), with a medium speed, I found that we seem to get the "ideal" where CSS and paint both finish completely while the HTML is still being downloaded:

Screenshot 2021-10-05 at 20.30.26.png (1×2 px, 847 KB)

I think this is still an issue. To test and verify I pushed some tests to run continuously and forced them to use HTTP1, I only did it for emulated mobile, and the test use simulated 4g. Make sure the test type is http1.

Then you can compare with the same URLs and change the test type to firstView. The impact is bigger than I thought on not so slow connection.

Here's two HAR files, one with HTTP1 and one with HTTP2, you can drag and drop them both into and then use the slider to see the diff.