#thirstyLinkSluts

the 14kb webpage shared universe

the introduction

https://endtimes.dev/why-your-website-should-be-under-14kb-in-size/

the counter argument

https://www.tunetheweb.com/blog/critical-resources-and-the-first-14kb/

the sober synthesis

https://angusjf.com/14kb/

the club

https://14kbclub.com/

the members

https://gitclassic.com/

https://no-js.club

https://1kb.club

https://motherfuckingwebsite.com

https://alecsargent.codeberg.page

https://512kb.club

in sum, the actual MTU value may not be exactly 14kb but the basic principle stands that if you inline the most important styles markup and assets into the first 10ish kb of your website, the speed with which your page will render cancels out any percieved inefficiency you think you’ll have by using inlined css and assets

Why your website should be under 14kB in size | endtimes.dev

@bri7 My site doesn't quite squeak in (my portfolio might but I've only got so much patience for typing ls -l on my phone) but honestly it's just nice to see that anyone besides me is even capable of delivering a page in less than a megabyte.
@bri7 I like to simply obey the kilobyte rule: starting at the first HTTP response header, the first kilobyte of your page (taking into account static HTTP header compression dictionaries, if your server supports them; vanilla Nginx only supports this for HTTP/3 for some reason) should inform the browser of all render-blocking resources. An arbitrary rule of thumb.
@bri7 Since my site is static I enabled 0-RTT; with HTTP/3 that means the first response contains my TLS certificates and maybe even the beginning of the HTTP response. On HTTP/2 you still need the extra TCP handshake. I advertise HTTP/3 on my HTTPS DNS resource records for an initial HTTP/3 connection, so my theoretical window may be smaller.
@bri7 I like the 1KB rule for render blocking assets because it’s something that pages of almost any size can adopt to speed up loads without radically changing their content.