Hi,
I made the experience with our website that when the connection is poor in the range of edge/gprs, I see the for example for 200kB resource the TTFB is 1/3 and the downloading of it takes the rest 2/3 of the time. Which for me does not make a sense.
Any thoughts?
Have you got some tests we can compare?
This would be an example:
Which resource in particular? If there’s a lot of other activity going on at the same time it’s possible that the response is buffered in the network before it starts arriving.
Hi,
For example line 9:
DNS Lookup: 1 ms
Initial Connection: 199 ms
SSL Negotiation: 262 ms
Time to First Byte: 5051 ms
Content Download: 15057 ms
Bytes In (downloaded): 175.9 KB
The first byte needs 5 seconds to arrive. Lets assume that we 512 byte IP packet size. that wold mean for the first 512 bytes it needs 5 seconds, for the rest of 170k it needs 15 seconds. I don’t get it.
What you mean by network buffering in particular?
BTW. the SSL negotiation has also some IP packets going back and forth, and still needs just 262 ms.
By “network buffering” I mean that other bits in flight at the same time are ahead of the bits for that request and given the 200kbps (~20KB/s effective) they may be starving the connection.
From the looks of that waterfall, I’d say the SSL negotiation for typekit is probably the one to blame since nothing else seems to be going on at the same time but the bandwidth chart at the bottom of the waterfall is pegged.
Hi,
I still do not get it why it get so long to start (5 sec receive first packet) and it takes another 15 second to receive the rest of 300 packets (175KB).
I do not see what can block because the network is congest, but nothing particular is going on in this time:
6 connections are waiting for the first byte and a ssl negotiation is running.
What is consuming my 20KB/s during this time of 5 seconds = 100KB:
6x500bit (1st byte)
1x? (SSL, 100KB??)
For me there is something strange going on or not monitored by this setup
regards
If you want to see exactly what is going on at that time you can enable tcpdumps and look at the packet capture.
The typekit ssl negotiation takes 2.2s so it’s not using the full 5 seconds but it’s possible that it is downloading large certificates and looks to also include OCSP stapling information. There are a bunch of other requests in flight at the same time that also do not start downloading until the typekit SSL is finished but they will all be competing for the same bandwidth as the one request you are looking at as well.
If you don’t think that network congestion could be impacting it, re-run the test with the same latency but MUCH higher bandwidth (and get rid of the 5% packet loss in case the first data packet got lost and had to be retransmitted).