Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making a Website Under 1kB

tdarb.org

Post reply on HN
Print view View original

81–90 of 109 posts

Re: Making a Website Under 1kB

#81

Post by netr0ute »

jrockway wrote: post #67
cosmodisk wrote: post #66

Earlier quoted context omitted.

From time to time I visit websites that my i7 16gb dell xps struggles to process. Bloody hell, 20 years ago that kind of power would have powered a small super computer and now it can't run a news websites.

"i7" isn't a particularly useful measure of computer performance. It can refer to over 12 years worth of processors, including the ultra-low power version of the first model, a 1.07GHz processor. That thing probably has trouble loading Emacs.

> That thing probably has trouble loading Emacs.

I don't know about that, because my RISC-V SBC with a 1-core in-order 1GHz CPU and no GPU can load Emacs GUI just fine.

Re: Making a Website Under 1kB

#83

Post by skyfaller »

tekinosman wrote: post #35

I had a look at https://cv.tdarb.org/ . You could reduce it even further. By: - removing quotes around attribute values - replacing href values with the most frequent characters - sorting content alphabetically - foregoing paragraph and line-break tags for a preformatted tag I was able to bring it from 730 bytes (330 had you compression enabled) down to 650 bytes (313 bytes after compressing with Brotli). Rewording t…

Why not eliminate quotes in production, if you know the value doesn't need quotes? That's still valid, it's optional HTML: https://meiert.com/en/blog/optional-html/

Sorting content alphabetically and that sort of thing to improve compression may be silly code golfing and impractical for page content, but on the other hand I don't see that it costs you anything (aside from time experimenting with it) when applied to the / metadata. https://www.ctrl.blog/entry/html-meta-order-compression.html

I think that both of these methods could be used in production, and I intend to do so when possible.

Re: Making a Website Under 1kB

#84

Post by zero_shift »

numlock86 wrote: post #29

For nowadays standards I consider anything below 500kB and with less than 6 server requests already pretty minimal, yet those are still numbers that can achieve a lot of things and still look so "modern"/"normal" that you'd have to look into the dev console to really appreciate the effort that has been put into these. Whenever I see websites that use 5MB large PNGs for photos and have over 30 requests over a time spa…

For small websites I wrote an observables microlibrary, one afternoon. It's called Trkl and minified & gzipped the code is about 400 bytes: https://github.com/jbreckmckye/trkl

Re: Making a Website Under 1kB

#85

Post by cafeinux »

cocoflunchy wrote: post #7
PuffinBlue wrote: post #5

I managed under 1.5KB for a page that has an actual function, not just a test: http://www.captiveportal.co.uk And yes, that’s supposed to be a non-https link. I think the entire site, including favicon, might be under 5KB. You can check here: https://github.com/josharcheruk/CaptivePortal

Well, the function is not in the content so your website could even be completely empty. I would say https://cv.tdarb.org/ has more function.

Interestingly, I surprised myself browsing the website you posted and others, clicking on every link, ready each new page before going back to finish reading the page I was coming from, jumping from link to link just as I remember doing 20 years ago. That is something I don't do anymore. Sure, I sometimes click on some links when I'm reading something, but I usually do it with a middle click (opens the link in a new tab) and continue reading the first article before closing it and seeing the new tab. And at this point I usually lost interest in the content I opened a few minutes before and just close the tab without reading. I was just wondering why I usually do this and why I didn't this time, and I realise that the reasons I open links in new tabs and don't consume them directly are : - opening it in a second tab lets it enough time to load completely, since everything is so bloated; - a website messing with your tab history or redirecting you 6 times before allowing you to get the content you were waiting for means that going back to my previous article will be a pain in the ass, and I'd rather play with two tabs rather than quintuple-click that back button just to find my previous article.

Anyway, that didn't happen here, because I subconsciously knew that every link would load before I could even think of it, and that none would make coming back one step a pain in the ass, and that was refreshing and maybe even made me nostalgic. But more than anything else, it allowed me to read with more focus than I remember having the last few years. So yeah, I love that "bare ones" design.

(PS: I also realise my comment is so long it could have been it's own blog post. Maybe I should start one...)

Re: Making a Website Under 1kB

#86

Post by skyfaller »

thegeekpirate wrote: post #37
dna_polymerase wrote: post #4

You don't need the quotes in many cases. Instead of: Try

will work just fine ;) Another fun trick is using since the spec says to pretend a space is there if not present for whatever reason ( https://html.spec.whatwg.org/multipage/parsing.html#parse-er... )

Cute, but I just ran both your suggestions through the HTML validator at https://validator.w3.org/nu/ and neither of them validated.

The first error read "Bad value data: for attribute href on element link: Premature end of URI."

The 2nd error read "Missing space before doctype name."

Depending on the context these hacks may still be useful, but I personally think that both production sites and code golfing should require valid HTML.

Re: Making a Website Under 1kB

#87

Post by diocles »

sjsdaiuasgdia wrote: post #41
samatman wrote: post #36

1kB is charming, the site shows the limitation: it's not even very much text, there's limited room in the medium to leave one's mark. Not a thing wrong with haiku, but for a whole art movement, we'll get more mileage out of a one-trip website. Ignoring a bunch of caveats I won't get into, a normal TCP packet is no larger than 15kB, for easy transit across Ethernet: the header is 40 bytes, leaving 1460 for data. Allow…

Think you got your math off there. MTU of 1500 bytes = 1.5kB, not 15kB.

I believe the parent comment was thinking of 1 round trip time.

Typically the TCP initial congestion window size is set to 10 packets (RFC 6928), hence ten packets can be sent by the server before waiting for an ACK from the client.

So under 15kB or so (minus TLS certs and the like) website loading has the minimum latency possible given any other network factors.

Re: Making a Website Under 1kB

#88

Post by Karrot_Kream »

samatman wrote: post #36

1kB is charming, the site shows the limitation: it's not even very much text, there's limited room in the medium to leave one's mark. Not a thing wrong with haiku, but for a whole art movement, we'll get more mileage out of a one-trip website. Ignoring a bunch of caveats I won't get into, a normal TCP packet is no larger than 15kB, for easy transit across Ethernet: the header is 40 bytes, leaving 1460 for data. Allow…

Ethernet MTU is 1500 bytes (not 15000 bytes or 15 Kbyte), assuming non-jumbo frames. TCP MSS tends to be 1460 bytes. But then, opening a TCP connection requires 3 packets anyway (so 4380 bytes.) TLS connections usually take another 2-3 packets (depending on your version of TLS/TLS parameters) so now your total payload just to establish the connection is sending 5840-7300 bytes over the wire. If we take the handshake as 50% overhead (which is quite sad mind you), then we can transmit a 7300 byte or 7.12 KB website, which can definitely make a pretty decent website.

Optimizing for 1 kB can be a fun creative exercise, but I think it's practically a bit meaningless. It's better to target something like a 28.8 Kbps connection and try to get the page to load under a second (including connection handshake < 20.1 KB), which is more than enough to have a rich web experience.

Re: Making a Website Under 1kB

#89

Post by remram »

sjsdaiuasgdia wrote: post #41
samatman wrote: post #36

1kB is charming, the site shows the limitation: it's not even very much text, there's limited room in the medium to leave one's mark. Not a thing wrong with haiku, but for a whole art movement, we'll get more mileage out of a one-trip website. Ignoring a bunch of caveats I won't get into, a normal TCP packet is no larger than 15kB, for easy transit across Ethernet: the header is 40 bytes, leaving 1460 for data. Allow…

Think you got your math off there. MTU of 1500 bytes = 1.5kB, not 15kB.

I think they might be referring to the initial TCP "window size", which is how much data can be sent before the recipient acknowledges it (in multiple packets but without round trips).
Post reply on HN