Critical Resources and the First 14 KB (2022)(tunetheweb.com)
tunetheweb.com
Critical Resources and the First 14 KB (2022)
https://www.tunetheweb.com/blog/critical-resources-and-the-first-14kb/
11 comments
Separately from the content, this page loaded instantly for me. Its remarkable how good / different the experience is compared to 99% of websites out there.
Of course it did, it was less than 14 kB.
But in all seriousness, this sort of site is what I wish more sites were like. No ridiculous JS rendering engine, or 11 billion AJAX requests to 3rd party servers, just simple HTML and CSS.
But in all seriousness, this sort of site is what I wish more sites were like. No ridiculous JS rendering engine, or 11 billion AJAX requests to 3rd party servers, just simple HTML and CSS.
It took almost a second for me; I used devtools and it was about 200ms total for connection/TLS/download of the HTML (which is in fact under 14k (a bit over 35k uncompressed)). But then none of the assets (including the stylesheet) were queued for download until after 900ms. Does it really take 700ms to decompress and parse ~35k of HTML?
Site owner here! Even if it did take that long, browsers are clever enough not to wait until all the HTML is fetched as HTML can be processed in a streaming fashion. You can see here that stylesheets https://www.webpagetest.org/customWaterfall.php?test=240913_... are requested from the first bunch of HTML.
A second is little disappointing, but in fairness my lowly, single CPU, single core server with only 1 GB of RAM (a t2.micro server on AWS) was struggling a little with the load that Hacker News sent to it yesterday (16,000 page views in a day compared to about a third of that number for the whole month before that!). Plus the images on this page are a particularly big (because they are quite detailed so can't compress them more without losing that detail). So it was probably a bit slower than usual. At the minute everything is served from that one server (no CDN either at the mo - I really should stick it behind Cloudflare). It was a little play thing for me to test stuff out with, that became an occasional blog too on the side.
A second is little disappointing, but in fairness my lowly, single CPU, single core server with only 1 GB of RAM (a t2.micro server on AWS) was struggling a little with the load that Hacker News sent to it yesterday (16,000 page views in a day compared to about a third of that number for the whole month before that!). Plus the images on this page are a particularly big (because they are quite detailed so can't compress them more without losing that detail). So it was probably a bit slower than usual. At the minute everything is served from that one server (no CDN either at the mo - I really should stick it behind Cloudflare). It was a little play thing for me to test stuff out with, that became an occasional blog too on the side.
Thanks for the reply!
My question was more of a "WTF is Firefox doing in the ~700ms between when the HTML has finished a network transfer and before the .css file is requested?"
I just tried it today and things are, in general, much faster (presumably due to the reduced load), but there is still over 500ms between when the .html completes the download and the .css is queued for transfer.
[edit]
I just tried it in a private window and most of the delay disappears, so I suspect extensions.
My question was more of a "WTF is Firefox doing in the ~700ms between when the HTML has finished a network transfer and before the .css file is requested?"
I just tried it today and things are, in general, much faster (presumably due to the reduced load), but there is still over 500ms between when the .html completes the download and the .css is queued for transfer.
[edit]
I just tried it in a private window and most of the delay disappears, so I suspect extensions.
It loads as fast as a raw basic html page, which is amazing