Break down the time taken by redirects since they're often a key part of the user experience
D
Dazzit! Corp.
Currently updown.io breaks out the time of normal requests into:
* name lookup;
* connection;
* tls handshake; and
* response time
but shows redirects as a single block of time. It would be useful to see redirects broken out the same way.
Users often type naked domains, like example.com, into browsers. That might lead to this sequence of redirects:
(HSTS preload requires the first redirect; you can't go straight from http://example.com/ to https://www.example.com.)
Depending on how you're handling both http and naked domains the time for the redirects can be much greater than the time of a page load. It would be useful to know where that time is actually being spent. For example, maybe your naked domain doesn't have good geographic distribution, or maybe it has slow TLS handshakes.
Log In
Adrien Rey-Jarthon
@Tony you can use https://tools.pingdom.com/ for example to get a waterfall view of the different redirection requests detailing how much time they took and from which URL you passed by.
It's also possible with local tools like curl if you're familial with command-line (https://dev.to/yuyatakeyama/how-i-measure-response-times-of-web-apis-using-curl-6nh).
Tony Dehnke
Hi Adrien, I agree it would be great to be able to get more detail here too.. Or if you could provide a document to help newbies learn how to do it as you mention that would be great.
Adrien Rey-Jarthon
Unfortunately the library we use to issue requests (libcurl) doesn't provide more detailed timings on the redirection intermediary requests, also presenting this amount of information would be much less readable so I don't think we'll do this but I'll keep the suggestion open to measure interest.
Alternatively you can of course mesure the performance of your different redirections on your side and if you want to more detailed metrics from our locations you can contact us by email and I'll give them to you.