141–150 of 356 posts
A typical HTTPS RSA certificate is about 3.9kb. ECDSA certificates with ECDSA cross-signed with an RSA root will be around 2.9kb. So this 14kb of HTML response should leave some room for the certificates too.
A typical HTTPS RSA certificate is about 3.9kb. ECDSA certificates with ECDSA cross-signed with an RSA root will be around 2.9kb. So this 14kb of HTML response should leave some room for the certificates too.
That's only doable with a text-centric website. I'm currently finishing a photography section for my personal website, and the gallery pages are several hundred kBs in size, while single photo page is almost 1MB in size (provided you load it on a 28" screen; browser will load smaller variants on smaller screens). Most of that weight is the thumbnails (and almost-full-size photo in the latter case). The only JS I have…
Some sites break the TCP standard by sending the whole contents of the landing page without waiting for the first ACK even it's more than 10 packets.
Shameless self-promotion: the homepage of plaintextsports.com is 5.2kb today [1], an in-progress WNBA game (4th quarter) is 11.2kb [2], and an extra inning MLB game is 8.8kb [3]. I wasn't aware of this size threshold, and I'm not at this level of optimization, but I'm always pleased to find more evidence of my playful claim that it's the "fastest website in the history of the internet". [1]: https://plaintextsports.c…
It's very small, but it's difficult to scan and painful to read. You could easily use built-in HTML structures to make it actually readable. Your site is, in my opinion, as much a deviation from the old readable web as the over-designed modern sites are. There are lots[1] of small, "class-less" CSS libraries that would keep your site as small (or smaller, with tree-shaking in a modern build system) and it would end u…
A typical HTTPS RSA certificate is about 3.9kb. ECDSA certificates with ECDSA cross-signed with an RSA root will be around 2.9kb. So this 14kb of HTML response should leave some room for the certificates too.
HTTPS requires an extra couple of round trips (to do the handshake and exchange keys etc). I don't think the whole thing can be optimised to 1 round trip, unfortunately.
Earlier quoted context omitted.
Bandwidth is extremely carbon intensive. Someone viewing a couple of few 25MP images online could use 20g to 100g of CO2 (depending on compression).
Source ?
In the US as of 2020, it was 3KG CO2 per GB Data.
I like the idea mentioned in the article of increasing the number of packets sent in the slow start - as far as I know you could just crank that from the server side TCP stack to something much larger, right?
Yeah, now that most of us control the server, is this an option?
Earlier quoted context omitted.
It's only 8kB compressed.
A fresh load of the page (according to Chrome) is 21.5kB transmitted, 59.1kB uncompressed. That's when loading with nothing cached. The HTML is just 7.9kB, but then the CSS is 2.2kB, JS is 2.3kB, and the favicon is 7.9kB which is a bit funny (but it's of course irrelevant for the actual page). HN could put the CSS and JS into the generated HTML file and still stay under 14kB for the initial load, which then would giv…
> HN could put the CSS and JS into the generated HTML file and still stay under 14kB
At the expense of caching those resources that stay static. With http/2 the benefit of merging into one resource should be negligible anyways.