Adding a field to RequestResult increases overhead to the entire system.
I don't think the first_byte field is useful enough.

Adding a field to RequestResult increases overhead to the entire system. I don't think the first_byte field is useful enough.

Is your concern that the RequestResult struct becomes too big (size of the struct in bytes is big)?

I've used the Response-delay (= first byte) and Response-read (= last byte) values in hey (see: https://github.com/rakyll/hey/blob/898582754e00405372f0686641441168f4e2f489/requester/print.go#L30-L31) because those values describe the viewer experience well (users care how fast they get the content). So I was hoping to get similar data with oha.

Is your concern that the RequestResult struct becomes too big (size of the struct in bytes is big)?

Yes

I've used the Response-delay (= first byte) and Response-read (= last byte) values in hey (see: https://github.com/rakyll/hey/blob/898582754e00405372f0686641441168f4e2f489/requester/print.go#L30-L31) because those values describe the viewer experience well (users care how fast they get the content). So I was hoping to get similar data with oha.

Gotcha. I agree that collecting first_byte is good.
So, could you change the CSV column order and name to the same as hey?

I've renamed the new field to be Response-delay in the CSV (same as hey).
For the column ordering, the current order is request-start,DNS,DNS+dialup,Response-delay,request-duration,bytes,status which seems logical to me as the events are in the order in which they happen (first request-start, then resolve DNS, connect to the server, and so on) or what do you think?

For the column ordering, the current order is request-start,DNS,DNS+dialup,Response-delay,request-duration,bytes,status which seems logical to me as the events are in the order in which they happen (first request-start, then resolve DNS, connect to the server, and so on) or what do you think?

Looks good. Thank you!