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. Allowing for a reasonable HTTP response header, we're in the 12-13kB range for the file itself.
That's enough to get a real point across, do complex/fun stuff with CSS, SVG, and Javascript, and it isn't arbitrary: in principle, at least, the whole website fits in a single TCP packet.
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.
You forgot the HTTP header... Which is variable size, but unfortunately usually quite large.
They can easily be in the 500 to 1000 byte range, taking up most of the first TCP packet. e.g this HN page has a 741 byte header. I suppose if you control the web server you could feasibly skim this down to the bare minimum for a simple static page - not sure what that would be.
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.
TLS certs won't count against your initial congestion window, although there's still a bit of overhead.
If there's a session/ticket resumption, the server won't send a certificate, but it does still need to send a negotiation finished message, and it may likely want to send new tickets (I'm not sure if you can delay that though). In TLS 1.3, the client may send the request as early data, if not the request will come as the beginning of the second round trip, so the congestion window will have opened more for the response.
If it's a full handshake, the certificate is part of the first round trip, and the content is in the second round trip; the cert won't count against the congestion window, because it must have been received before the client sent the http request.
Even if the initial congestion window is set to 10 segments, all that does is send out the packets if they're available to send. It still takes less time for the receiver to receive 3 segments than 10 segments, having the congestion window be that wide just means that the sender doesn't need to wait to receive ACKs for those 10 segments (which, to be fair, is faster than sending each packet and waiting for an ACK.)
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).
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. Allowing for a reasonable HTTP response header, we're in the 12-13kB range for the file itself.
That's enough to get a real point across, do complex/fun stuff with CSS, SVG, and Javascript, and it isn't arbitrary: in principle, at least, the whole website fits in a single TCP packet.