cflat

don't need to remove the audio. it's muted by the browser. removing audio just saves bytes.

My bet is on HEIF. It's far superior. Full subsampling support, >24bit colours, etc, etc

>What's so bad about WebP?

* Lack of clear spec ("The code is the spec")

* Lack of versioning of spec (at least 3 major versions with different capabilities/features of which not all degrade nicely)

* Forced 4:2:0 chroma subsampling

* 8bit-channel only (no support for 10bit+ aka wide-gamut images)

As I've said previously [1][2][3], you shouldn't PUSH with `Link re="preload"` for performance gains. You will likely run into TCP HOL Blocking or browser request race conditions. Instead send PUSH_PROMISES in the whitespace while the client waits for the TTFB.

[1] https://news.ycombinator.com/item?id=14082636 [2] https://shouldipush.com [3] https://youtu.be/GjWD1pOkxUk?t=1534

Using `Link: rel=preload` is interesting, but it misses the real opportunity to get the critical resources before the html and window to grow the congestion window early. At best you are in a race condition on the browser's preloader/speculative parser. At worse, you are competing with the html base request with your pushed resources.

The better solution is to push these resources before the HTTP headers and status code from the application framework. The real opportunity is to get the content downloaded early, grow the congestion window ahead of receiving the html, then yielding the socket to the html, and then continue pushing content until the browser starts making it's own http requests. As all things - mileage will vary. Some times this is a large opportunity (eg: User in Australia requesting content from NY; or DR failover). Other times, push opportunity might be negligible (eg: cached html page) On high RTT networks, this does save you the full round trip for the request.

For more details on this check out my talk at Velocity Amsterdam: https://youtu.be/GjWD1pOkxUk?t=1534 https://speakerdeck.com/colinbendell/promise-of-push

I also built a tool (on top of webpagetest.org) that helps you evaluate the potential for push here: https://shouldipush.com

yes, but as the server responding to your webp enabled client, I can't tell which version of support you actually have. I can infer, but that's problematic.

And it likely won't come back because of the lack of support for 10bit channels needed for P3 displays. Jpeg2000 (Apple's alternative to webp) does.

My two cents: Which version of webp should Firefox support? There are 3 major versions, and the subtleties in the 'extended' webp is only traceable through the releases of Chrome.

further, how can I tell which client supports which version of webp? `Accept: image/webp` is insufficient because it doesn't tell me which version or subset of features this client uses. Take for example, ios9b1 where webp was thought to have accidentally been available through CoreImage. It only supported WebP basic. But how would a server know this?

Lastly, webp is not setup to be successful for the next set of requirements: it is 8bit per channel color only (can't do 10bit needed for P3 or rec2020). It can't do full chroma subsampling (4:4:4). And the list goes on. It was a good first start, but it needs much more work before it can break out of the Google grip and get wide support.

You are the human manifestation of "the chaos monkey"

This is a copy of the Akamai's http2 demo: http://http2.akamai.com

Nitpick - It's HTTP/2 not HTTP/2.0

We've all learned from the failure of SNI and IPv6 to gain widespread adoption. (Thank you windows xp and Android 2.2) HTTP/2 has been designed with the absolute priority of graceful backward compatibility. This creates limits and barriers on what you can do. Transparent and graceful backward compatibility will be essential for adoption.

I agree, HTTP/2 is Better - not perfect. But better is still better.