Note from 25th June 2020

3 likes

1 repost

8 replies

1. Tim
   530ms seem unexpectedly long for your website, it could be a temporary glitch somewhere in the chain between dareboost and alwaysdata.
   To partly answer your original question, you might want to take a look at curl -w output format or httpstat: github.com/reorx/httpstat
   • 25th June 2020, 16:38
   • Source
2. Nicolas Hoizey
   This is not a temporary glitch, as @Dareboost shows, that's why I want to investigate.
   
   I'll see what I can get with http stat, thanks! 👍
   • 25th June 2020, 17:05
   • Source
3. Nicolas Hoizey
   Also, it's almost the same with Netlify, so I guess it's not an issue with @alwaysdata
   
   Did you see it's on simulated 3G?
   • 25th June 2020, 17:12
   • Source
4. Boris Schapira 🚀
   In Dareboost, the "More metrics" qui decompose the TTFB between DNS, Connecting, Waiting and Receiving.
   • 25th June 2020, 17:17
   • Source
5. Boris Schapira 🚀
   If your Connecting time is long, you can test with a perfect bandwidth/0ms latency to better assess the problem. If nothing changes, maybe it's because it takes time to validate your certificate.
   • 25th June 2020, 17:17
   • Source
6. Nicolas Hoizey
   Looks like I never clicked that button… 😅
   
   Connection takes 334 ms.
   • 25th June 2020, 17:28
   • Source
7. Nicolas Hoizey
   No issue on a perfect network:
   dareboost.com/en/report/a_35…
   • 25th June 2020, 17:30
   • Source
8. Nicolas Hoizey
   First result with httpstat from my computer on fiber was chocking! 🤷‍♂️
   
   Next ones are better.
   • 25th June 2020, 17:52
   • Source

1 mention

1. Nicolas Hoizey
   How do you analyse TTFB?
   
   How to know how many of these 530 ms come from the network, from reading files on the server, from many rules to parse in `.htaccess`, etc.?
   • 25th June 2020, 15:32
   • Source