othermaciej

Manually specifying different HTTP ranges of the same resource is more verbose, more error-prone and more confusing than just specifying different resources. Other than that, I guess it would work.

When it comes to page load speed, extra network round trips are really bad. Even if you're loading the same total amount of data.

That's not so great for high-latency networks (like most cellular networks). If you use range requests, you add round trips. If you cancel the load partway, you're too late because your pipe is already filled with bits you don't need.

It matches the CSS equivalent feature, image-set().

SVG is fine for assets that can easily be described in vector form, but it's not the best choice for all image types. For example, photographs (where you might have an ultra high resolution original that you're scaling down) are not easily representable in SVG other than to embed the bitmap.

In the case of Web standards in particular, you can usually see the checkins in our public source tree well before we ship it. But per policy we will rarely publicly commit to shipping something or not ahead of time.

WebKit did fine before Google ever joined the project, and I'm sure it will do fine with them gone.

In WebKit, we have macros to always inline or never inline for our target compilers, so we can force the issue if the compiler won't take the hint in a place that matters.

Do you have any specific feedback about things you have problems with?

Try the version in WebKit nightlies and the OS X Mavericks developer preview. It's much improved from Safari 6.

I expect other browsers could greatly improve JSBench performance if they focused on it. But I would be quite surprised if they matched Safari's current results in a month. It took a lot more than a month and significant architectural work to get those results in the first place.

It's not in the keynote, but if you get the Developer Preview you can see what's new.

Other JS benchmarks are not based on highly-trafficked real-world sources at all, so perhaps "real" is relative.