News for hackers. Stuff that matters.
Re:Don’t use JPEG-XR on the Web by y4mi on Monday December 31, 2018 @11:33AM (#18795292)
Uuh, i thought the whole point of a static server was to not need an application that needs to prepare the content? It's supposed to be a dumb web server that accesses a folder structure or similar storage backed...
Re:Don’t use JPEG-XR on the Web by mnutt on Monday December 31, 2018 @12:36PM (#18795699)
Is that the point, though? I think the point is more that you tell the webserver "here is some content, I want you to serve it in the best way possible" and it figures out how to do it without any special configuration. In the same way I'd expect a "dumb" webserver to be able to negotiate gzip compression without having to point it at a directory of gzipped files.

Edit: I agree that something like the pagespeed module rewriting html probably goes too far and html rewriting is fraught with weird edge cases, but content negotiation is something only a webserver (or CDN) can do.

Re:Don’t use JPEG-XR on the Web by Avamander on Tuesday January 01, 2019 @06:59AM (#18799861)
A directory of gzipped files is often incredibly useful, I've managed to reduce both latency and time it takes to load pages by just precompressing resources. It's more than incredibly useful on low-powered hardware like Raspberry Pis, some applications can be made to load in 3 seconds instead of 10.
Re:Don’t use JPEG-XR on the Web by mnutt on Tuesday January 01, 2019 @01:39PM (#18801521)
That’s somewhat surprising that it makes that much of a difference, a Raspberry Pi 2 can gzip compress at around 20MB/s. Maybe there’s some inefficiencies in the webserver implementation, or just really big files?
Re:Don’t use JPEG-XR on the Web by Avamander on Tuesday January 01, 2019 @02:16PM (#18801709)
If you only compress, then maybe, but if you have more than just nginx running on the Pi it really helps.