Introducing Slowww.ml – the slow web server
-
@Edent Have you tested your images encoded with JPEGli as a progressive JPEG? I’ve found them to be roughly the same size as webP (I have a tool at https://github.com/jphastings/jpegli or brew install jphastings/tools/jpegli — but you’d need to compile it yourself for q=10!)
-
-
@byjp It isn't JavaScript
It is *literally* a very slow web server.
https://shkspr.mobi/blog/2020/10/introducing-slowww-ml-the-slow-web-server/ -
@Edent Some feedback (please ignore if you wish; you didn’t ask for it!):
The JavaScript *forcing* me to the bottom meant I couldn’t read the top until the end (cos I missed the page finishing loading
)The Opus audio didn’t work on my iPhone/Arc browser.
That’s it! Thank you!
-
@byjp I released the website a few years before JPEGli was a thing.
-
@byjp The forcing to the bottom is a trade-off. I wanted people focusing on what was happening, rather than skipping back and waiting for it to load.
As for Opus? Fuck Apple
-
@Edent Probably late to the party, but nothing loaded here. "The connection to the server was reset while the page was loading."
Mozilla/5.0 (X11; Linux x86_64; rv:131.0) Gecko/20100101 Firefox/131.0 -
@Edent It did, yes. Some content about slow content loading and 20 characters/second average reading rate and some other stuff.
-
@tink cool! Thanks for the feedback.
-
@Edent It did play a bit of havoc with my screen reader though - I suspect because as the content gradually loaded it forced the DOM to rebuild which in turn forced the accessibility tree to be rebuilt.
-
@tink youch! Sorry about that.
-
@byjp just playing with it.
The README says "WebP images are likely to be a little larger"
Should that be "smaller"?
️ What gave you the idea?
