41–50 of 109 posts
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…
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…
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.
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... )
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…
500kB honestly doesn't require much effort at all. My WordPress blog with a popular theme and a few plugins has each almost every article below 500kB, despite looking like any modern blog and having at least 1 image per post.
Actually, if I remove the Facebook share button, they drop to almost 250kB. Time to remove it I guess.
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
Is it really needed when browser (and linux distros!) have their own captive portal detection page ? (e.g http://detectportal.firefox.com/ or http://connectivity-check.ubuntu.com )
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…
I tried that too but decided that saving a few bytes is not worth the parser restarting, so I adhered to strict XHTML for fast page load times.
If you’re using the HTML parser (e.g. served with content-type text/html), activities like including the html/head/body start and end tags and quoting attribute values will have a negligible effect. It takes you down slightly different branches in the state machines, but there’s very little to distinguish between them, one way or the other. For example, consider quoting or not quoting attribute values: start at https://html.spec.whatwg.org/multipage/parsing.html#before-a..., and see that the difference is very slight; depending on how it’s implemented, double-quoted may have simpler branching than unquoted, or may be identical; and if it happens to be identical, then omitting the quotes will probably be faster because there are two fewer characters being lugged around. But I would be mildly surprised if even a synthetic benchmark could distinguish a difference on browsers’ parser implementations. Doing things the XHTML way will not speed your document parse up.
As for the difference achieved by using the XML parser (serve with content-type application/xhtml+xml), I haven’t seen any benchmarks and don’t care to speculate about which would be faster.
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 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 500kB honestly doesn't require much effort at all. My WordPress blog with a popular theme and a few…
To me it looks like it has always been a fairytale made up by Facebook to spread their analytics scripts all over internet.
If 1kb websites interst you, check out the https://js1k.com that has awesome Javascript demos within 1kb!
Wild. https://js1k.com/2013-spring/demo/1555
Earlier quoted context omitted.
> 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 500kB honestly doesn't require much effort at all. My WordPress blog with a popular theme and a few…
Honest question—do actual real people use Facebook share buttons? Have they ever? To me it looks like it has always been a fairytale made up by Facebook to spread their analytics scripts all over internet.