iPhone and android version : how does the waterfall vary from the desktop version ?

[braincracking]

Hi

I’m starting to use the WPT with the iPhone and android clients, thank you very much for providing them.
However the graph are really different from what we are used to see on desktop browsers.

On iPhone ( see http://www.webpagetest.org/result/120629_VJ_8e1ff3b7bb2672fd90da8b8cef9d9b5d/1/details/ ) :

• bars are always blue, aka “downloading”
• there is only 1 thread per host in the connection view, however we can see parallel downloads in the waterfall. I dont remember the iOS safari using only 1 thread
• in this specific waterfall ( http://www.webpagetest.org/result/120629_VJ_8e1ff3b7bb2672fd90da8b8cef9d9b5d/2/details/ ), we see a gap in the downloads. Since there is no CPU graph, I dont know if it’s a bug or the browser taking a break before continuing to parse and evaluate

On Android (see http://www.webpagetest.org/result/120629_MF_fb8dbeed7ee9ee2d0b6fffd1bd675d44/1/details/ )

• I have a big bar getting something from 192.168.0.1 . I checked and that’s not a bug in production
• in the connection view, I also see only one thread per host, not sure if it’s the way the android browser really works ?
• in the connection view, taking a look at the 1st domain connection bar, I see many small orange bars (initial connection) : is it the behaviour of the browser ?

Also, it would be nice to have an ipad version, with the two possible orientations

The question : I get the technology used is completely different (only based on the network via a proxy I guess), but could we have some tips on how to read the waterfalls for those new clients ?

thanks in advance, and thanks already for the addition of those tools

[pmeenan]

@braincracking

On iPhone ( see WebPageTest Test - WebPageTest Details ) :

• bars are always blue, aka “downloading”
• there is only 1 thread per host in the connection view, however we can see parallel downloads in the waterfall. I dont remember the iOS safari using only 1 thread
• in this specific waterfall ( WebPageTest Test - WebPageTest Details ), we see a gap in the downloads. Since there is no CPU graph, I dont know if it’s a bug or the browser taking a break before continuing to parse and evaluate

Yeah, the mobile instrumentation is still very immature

We don’t get a lot of visibility into the requests in IE so it shows up as a solid blue line (DNS, socket connect, ttfb are all unavailable).

Not sure what you mean by “1 thread”. All of the mobile browsers support several connections per domain in parallel and even do pipelining so I’d expect to see a lot of concurrent requests. The gap is likely javascript but exactly what script is going to be really difficult to track down just through the mobile agents. Try spoofing the mobile user agent string in Chrome and you should be able to see what is going on (though it will be a lot faster on your desktop).

On Android (see WebPageTest Test - WebPageTest Details )

• I have a big bar getting something from 192.168.0.1 . I checked and that’s not a bug in production
• in the connection view, I also see only one thread per host, not sure if it’s the way the android browser really works ?
• in the connection view, taking a look at the 1st domain connection bar, I see many small orange bars (initial connection) : is it the behaviour of the browser ?

The connection behavior is possible if it is pipelining but it should still open several in parallel. It’s possible that it’s a bug in the extraction from the pcap.

192.168.0.1 is the gateway out of the network - wonder if there is some non-test behavior that got captured while the test is running.

The question : I get the technology used is completely different (only based on the network via a proxy I guess), but could we have some tips on how to read the waterfalls for those new clients ?

It doesn’t proxy, we are measuring directly on the devices but it’s far from bulletproof. You should largely read it like a normal waterfall and just let us know when you see oddities so we can track them down.