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.

But it can keep the port open so a few round trips are saved, it might be fast enough to make the second request while the first was still coming in so effectively very little overhead, even on (especially on) high latency links where it matters most. It can start drawing even from the first range request, and the idea is to never pull down the entire file (for big files, the case you are optimizing anyway, small ones you don't really need to) and only maybe end-up pulling in the entire hires file with a third request if say the user zooms way in.

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.

You could avoid that with a simple optimization where the page could indicate the byte ranges for a tile level. Suppose something like this worked:

    <picture>
      <source srcset="foo.jp2 100w 100h range=1-<first layer>">
      <source srcset="foo.jp2 500w 500h range=1-<middle>">
      <source srcset="foo.jp2 1000w 1000h">
    </picture>

That'd avoid the need to a round trip at all and it'd also be a huge improvement for caches which support HTTP range correctly since it'd be a single resource rather than multiple different URLs. It'd also allow browsers to start making decisions like selectively preloading more of an image which the user is likely to zoom, etc. although some of that would come simply from a good progressive JP2 implementation.

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.

> more verbose, more error-prone and more confusing than just specifying different resources

That's largely opinion: are byte ranges really better than having to maintain clusters of related images? Any serious site already has to deal with things like cache invalidation when a source file changes and by the scale of things which sites do for performance this is certainly no worse than, say, JavaScript/CSS minification or UA sniffing.

I'm not a network engineer. But perhaps this wouldn't be a problem once `SDPY` is popularized.

It would be less painful but still a problem: SPDY / HTTP/2.0 allows you to send more traffic over a connection but they can't do much for round-trip latency if you need to do something like ask what sizes of an image are available. That's particularly painful on cellular networks with a delay measured in hundreds of milliseconds – SPDY's ability to ship many things in parallel would only come into play after the browser knew which resources to request.

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.

Historically, the story with visibility on checkins to iOS Safari was not that great.

But yes, for desktop Safari usually one can get some idea by scouring checkin logs.

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.

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

While being much improved over previous version of Safari 6, that's not saying anything. It's still abysmal, and Chrome and Firefox are still leaps and bounds ahead.

Instead of just saying it's abysmal, could you be a little more specific? I've been using Firefox inspector for few months and still don't found the new WebKit Inspector to be lacking at all (except the lack of Responsive Mode).

As mentioned in another comment, I'm just now looking at this and will get back to it.

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

I'm just now reading this but when I get a chance ill try to give a complete run down of issues I have.

Not even a few that come to mind immediately?

I was replying on an iPad, and wanted to give better information than merely what I remembered.

Edit: Sorry for the awful formatting. =( I'll note that I want Safari tools to get past the stage where they are playing catch up. This will allow them to play with new ideas, such as what Mozilla can do because of Firebug.

These are in no particular order. The developer tools crashed several times (pre-release and all), and I don't have the time to keep going through all the other places.

I'll make this clear up front, as I mentioned it below, but want to make it clear:

"I'll admit there is more their than I originally thought, but still missing things I use daily."

Here are my notes:

* Lack of effective Network Tab

* This can be found in Timelines > Network Requests

* Basic problem is the Timeline is now trying to do two things at once, both with different reasons

* Browsing network requests is cumbersome at best.

* Cannot switch between headers and bodies

* No way to see raw headers

* No way to open request

* Copy row is pointless

* This is such an odd miss...

* Back button is not consistent

* From full frame console, it sends you back to the network requests

* From source, it sends you "back" to another source page (?)

* I see no way to define what is being repainted/drawn for each record of Layout & Rendering

* Consoles in other parts of don't seem to function at (at least, the response is put into the Console tab, and not in the console area that opens up).

* No way to edit JS

* No way to edit Breakpoints without specifically opening up the Debugger

* CSS editing is non-obvious

* It's also less than helpful when completion

* No easy mechanism to edit existing rules

* Debugging doesn't let you mouseover and see this (?)

* Cannot execute JS in scope while debugging

* Debugging just seems awfully buggy at the moment, it's a pre-release, but makes it hard to put through it's paces.

All together, the dev tools don't seem fluid. I'll admit there is more their than I originally thought, but still missing things I use daily. More so, nothing seems put together that makes sense. You can argue that it's because I'm used to Chrome Dev Tools, but I can move from Chrome to Firefox with relative ease, but debugging inside Safari is still painful. Couple that with the bugs, and it really makes it hard to give it a proper run through. For example, the debugger right now is set to break on all uncaught exceptions. Running this on http://www.apple.com/osx/preview/#ibooks, it stops on ac_retina.js:20, but it doesn't offer any information in the debugger, or in the console.

I get a feeling this was designed by people copying from Xcode, rather than people working with web developers. Tools I'm used to working with don't work, or work in a different way that is simply not useful.

I didn't spend much time digging through more of the timeline stuff, and as I mentioned, the debugger was cumbersome to use.

Heck, even the Resources tab was painful. I mean, the page is loaded, yet somehow clicking on scripts to view put them in a constant loading state.

Again, it's a pre-release, but it's all I have.

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.