4 ms·

For a site with limited assets, people care more about bandwidth costs than storage costs and ideally your webserver can automatically transcode and serve the b

by mnutt 8y ago

For a site with limited assets, people care more about bandwidth costs than storage costs and ideally your webserver can automatically transcode and serve the best format based on content negotiation. Except for JPEG2000, which Safari supports but does not include in its Accepts: header. So Akamai just sniffs the user-agent and serves JPEG2000 to anything that looks like Safari, whether they support it or not.

y4mi 8y ago
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...
- mnutt 8y ago
  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.
  - Avamander 8y ago
    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.
    - mnutt 8y ago
      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?
      - Avamander 8y ago
        If you only compress, then maybe, but if you have more than just nginx running on the Pi it really helps.

by mnutt 8y ago

y4mi 8y ago

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...

mnutt 8y ago
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.
- Avamander 8y ago
  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.
  - mnutt 8y ago
    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?
    - Avamander 8y ago
      If you only compress, then maybe, but if you have more than just nginx running on the Pi it really helps.