Unexplained delay to HTTP connection

[Jake Archibald]

I've been doing a performance review of a site, and I ran into something unexpected:

The site: https://www.williamsf1.com/

WebPageTest: https://www.webpagetest.org/video/compare.php?tests=210319_XiEN_6fb8430d86c8985be8d7505bb2258ad4-r:3-c:0

There's a key image on row 20 of the waterfall, and I can't figure out why that HTTP connection happens so late. I can recreate it locally, so it isn't a WebPageTest glitch. I've also attached a net log.

The image is an <img> in the HTML, so it's discoverable by the parser, image fetching is not blocked by preceding CSS & JS, and none of the preceding scripts are parser-blocking.

tbansal@ took a look and concluded that it isn't a delay due to resource priority.

The page is HTTP/1.1, so there are more connections than you'd get with H2 pages. I don't know if that's relevant.

Any help would be appreciated! The mystery of this is keeping me awake 😀

[Patrick Meenan]

tbansal@ - are you sure it's not priority/scheduling?

Using The Net Priorities column from the priorities doc:

- Images start out at "lowest" until layout happens and it is discovered that they are in the viewport (the WPT priority is the final priority after reprioritization - I really should add the initial one as well)

- Under most conditions, Chrome will only load 1 medium or lower priority resource at a time when in "layout blocking" phase (basically while the parser is still in the head and in-head css is still loading)

- It appears to be in "layout blocking" mode until around 6.2s when aos.css loads

- news.svg (waterfall row 16) looks like it is the 1 low-priority resource that is initiated while in layout-blocking mode (and doesn't complete before exiting layout blocking mode so everything else is blocked)

- The image request in question looks like it released around the 6.2s mark (with a bit of a delay until 6.8 sec for the connection establishment - that looks like maybe DNS and other delays since I don't see DNS for that origin anywhere in the waterfall)

Chrome doesn't preconnect for delayed resources so the connection itself isn't started until the resource makes it out of the scheduler, delaying the actual request that much more.

--
You received this message because you are subscribed to the Google Groups "loading-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAPy%3DJoraUUdEyYf0sENCCyc22e66PR%2BGr6mhdB6-8HCWDBYUHg%40mail.gmail.com.

[Patrick Meenan]

I was under the impression that the resource scheduler was moved into blink at some point (or at least part of it or a version of it).  I think ResourceLoadScheduler might be it?

WPT can't capture json netlogs from Android devices but here is the same test run on desktop with mobile emulation (with netlogs 0 links to the left of the waterfalls).  The requests shuffled a bit but in test #1 I believe the equivalent "first real image" is request #14 and still delayed the same way because the svg is using up the 1 slot.  Full netlog for that run is here.

On Thu, Mar 25, 2021 at 12:08 PM Tarun Bansal <tba...@google.com> wrote:

Jake had shared a netlog as well and based on that it did not look like that the request was slowed down due to the resource scheduler that sits on the top of the network stack. There were other requests in the netlog that were slowed by resource scheduler though: https://imgur.com/a/jukvMph shows the request in question (row 20) with the other request from the netlog that was actually throttled by resource scheduler.

There could be other scheduling mechanisms at play that I am not sure about though (e.g., within Blink or within the network stack).

[Patrick Meenan]

Yes, sorry - probably technical semantics.  It probably wasn't held back by ResourceScheduler (the class in the networking service specifically and visible in the netlog) but WAS held back by general "resource scheduling in Chrome" (likely ResourceLoadScheduler in blink) :)

On Thu, Mar 25, 2021 at 3:02 PM Tarun Bansal <tba...@google.com> wrote:

There is ResourceLoadScheduler, and then there is ResourceScheduler. Former is in Blink, the latter is in the network process.

[Jake Archibald]

This is perfect, thank you! I wasn't aware of these priority details.

[Jake Archibald]

On Thu, Mar 25, 2021 at 2:33 PM Patrick Meenan <pme...@chromium.org> wrote:

tbansal@ - are you sure it's not priority/scheduling?

Using The Net Priorities column from the priorities doc:

- Images start out at "lowest" until layout happens and it is discovered that they are in the viewport (the WPT priority is the final priority after reprioritization - I really should add the initial one as well)

- Under most conditions, Chrome will only load 1 medium or lower priority resource at a time when in "layout blocking" phase (basically while the parser is still in the head and in-head css is still loading)

- It appears to be in "layout blocking" mode until around 6.2s when aos.css loads

- news.svg (waterfall row 16) looks like it is the 1 low-priority resource that is initiated while in layout-blocking mode (and doesn't complete before exiting layout blocking mode so everything else is blocked)

This image is triggered by the CSS, so I don't think it starts in layout-blocking mode. Could it be the preloaded fonts that are counting towards the limit?

[Patrick Meenan]

Sorry, yes - the preloaded fonts are medium and will count to the limit.  The news SVG just looked like it was loading early because of the connection setup being done earlier (as part of the regular connection pool).

[Jake Archibald]

Makes sense, thank you!

[Jake Archibald]

Somewhat related question: I guess pm/ssl in the net log means it's a connection used for CORS. What does the pm stand for? Privacy mode?

[Patrick Meenan]

Correct on both counts.  If you're seeing it on fonts it is because they default to crossorigin if they are served from a different origin than the page :(

[Jake Archibald]

Thank you! In this case I'm seeing it from a <link rel="preconnect" href="…" crossorigin>, but the actual request to that origin is an @import in CSS, so it's a preconnect miss. I wrote about it here: https://jakearchibald.com/2021/f1-perf-part-5/#connections-and-credentials

[Patrick Meenan]

The series has been a great read. Lots of problems that I see in a lot of sites so hopefully it helps.

Wonder if they were fixing the font preconnect by adding crossorigin and just added it to everything.

[Jake Archibald]

On Wed, Mar 31, 2021 at 2:27 PM Patrick Meenan <pme...@chromium.org> wrote:

The series has been a great read. Lots of problems that I see in a lot of sites so hopefully it helps.

Wonder if they were fixing the font preconnect by adding crossorigin and just added it to everything.

That'd be my guess too. "It's about fonts so it must need crossorigin".

I'm going to put together a doc for how I think we could improve DevTools based on this. We should at least warn about unused preconnects.