The performance is obviously decent already, and premature optimisation yada yada yada… but the pause between the HTML being donwloaded and the next resource (css) being requested bugs me.
Why does it take the better part of half a second for it to parse my HTML and request the CSS file right at the top of my ? I feel it should be almost instantaneous - what am I missing?
Thank you!
My guess (and it’s just an informed guess without collecting a much more detailed trace) is that the time is Chrome initializing the renderer for the site. On navigation it gets a head-start by initiating the HTML fetch from the “browser” process while it starts the sandboxed renderer, then it hands off responsibility for loading the site.
If you look at the timeline view and zoom in to the beginning: https://webpagetest.org/chrome/timeline.php?test=210129_DiPY_a767addc8230a0b52255d356101dbfa0&run=1
There is around a 60ms gap between when the browser process starts loading the response body and when the renderer process starts loading it (and then there are going to be a few more delays for the background parser to parse the HTML and initiate the CSS fetch).
I’ve looked at plenty of other sets of test results that I’ve seen in the forum here and most of them don’t seem to have the same problem. Is there something I might be doing wrong?
I tried moving the CSS file from the assets subdomain to the www subdomain and was surprised that that didn’t make a difference.
On that note I’m REALLY curious how it is that request 2 (css) manages to complete before the SSL handshake of request 10 (JS on the same subdomain) has completed.
If it needs to do an SSL handshake for the assets subdomain (which I think is correct), how on earth is it ok for it to do that AFTER it’s already received the CSS from that same subdomain?
Please educate me Pat, thank you!
The main domain and subdomain are both using HTTP/2, share a certificate and resolve to overlapping IP ranges so the requests can be coalesced to share the same connection (at the cost of a DNS lookup to verify the IP ranges). Request 2 was served over the same connection as request 1.
Request 10 came from a different connection. Most likely it was fetched as crossorigin for some reason (would need to collect a netlog to be sure). Crossorigin requests can’t use the same connection as credentialed requests.
It’s worth noting that you’re a decimal point out here… it’s 0.05s, not 0.5.
Pat is correct (obviously); this file is fetched anonymously which will force a new connection:
<script crossorigin="anonymous" src="https://a.rootsandrain.com/js/common.min.js?c"></script>