Hi Patrick,
hoping you will see this. For me the chart below makes no sense, due to TCP slow start. Why are 10 packages displayed splitted on all WPT platforms? Is it Lighthouse causing such charts? - Here the link.
Thanks.
Are you sure your initial congestion window is configured to 10 on the server? That said, the SSL negotiation also warms up the connection a bit so by the time it gets to the HTML it is likely a little bit bigger than the initial.
It’s also entirely possible that what you are seeing is the server early-flushing the header and some content and then the server sends the rest or possibly TCP_NODELAY is not enabled so the server is waiting to send the last packet for a short time since it is not a full packet, just in case more data is written to the socket.
Thanks for quick reply! Appreciate your time taken for this!
It sounds like the shared hosting server is kind of misconfigured. So I copied the static HTML index file over from German shared hosting to my DigitalOcean VPN (located in Amsterdam) and have the same result: 2 round trips for HTML, depending on chosen device generation and lenght of RTT.
Shouldn’t TCP_NODELAY be a fixed time value instead of beeing alsways as long as 1 RTT … and if the server is flushing early why it waits a time lenght of 1 RTT?
So you would definitely exclude the possibility that WPT eventually gives a wrong picture?
I compared WPT’s 3G Fast (150ms RTT) with values from a local Chrome browser (in Vienna) and PSI also (see here) and values are similar to each other but very different to the values from WPT which claims longer times for metrics. Example. PSI says: speed index 1,100 and WPT says 1,300 (which is like 1 RTT more). I measured several times with same result.
Local Chrome browser:
Thanks again!
TCP_NODELAY delays a partial-buffer write as long as there is pending un-ack’d data on the wire. As soon as the ack arrives it will flush the buffer (or wait until the timeout) so it will vary by the RTT for a certain amount.
Dev Tools traffic shaping (and PSI and Lighthouse) all operate in the application layer, well above the packet flow and won’t expose packet-level pacing issues. Uf you use Network Link Conditioner (or winshaper) locally then you should be able to reproduce it.