WebPagetest Forums

Full Version: Strange results with iPhone vs Nexus over tls
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi there! I'm seeing strange difference in StartRender between nexus and iphone. I’ve removed almost all the external assets including all css to make it as simple as possible but on iPhone I always get a 3s delay in start render.

Nexus result: http://www.webpagetest.org/result/160513...1/details/

iPhone result: http://www.webpagetest.org/result/160512...1/details/

On the webperformance slack group it was pointed out to me that the iPhone result wasn't showing any ssl negotiation and they wondered if this was a limitation of the iphone test setup and if that could have anything to do with this? It was a bit of a long shot but worth bringing up! I ran a similar test that went straight to https in case it was down to the redirect but that shows the same (http://www.webpagetest.org/result/160516...1/details/)

I'm all out of ideas really, there is any advice you could give me about what might be causing the delay I would be really appreciative!

Many thanks
The iPhone reported data doesn't include any of the component times (DNS, connect, TLS) but those should all be part of the TTFB for requests (sorry, a limitation on what iOS reports through the dev tools interface).

Try enabling tcpdump capture on the iOS test and look at the packet capture (or I can take a look if you share a test result with tcpdump). My bet is that iOS is doing a OCSP/CRL check for the certificate during the TLS negotiation and it is PAINFULLY slow.
Thanks for replying Pat.

I have just done that. Here is a test with tcpdump enabled http://www.webpagetest.org/result/160517_VA_Q5S/

Looking at the dump in wireshark I see an Encrypted Alert followed by what looks like quite a lot of ARP/IGMPv2 chatter. This is my first time in Wireshark though so it's all quite alien to me. I'll dig deeper but if you have a moment to take a look and can spot anything obvious that would be amazing. The first request cap files don't seem to load but the second request ones are very quick.
Unfortunatly that one doesn't seem to have a 3+ second TTFB (even the first run). My guess is that the CRL/OCSP validation is still in cache from earlier testing. Could also just be variable server performance but my money is on the OCSP side of things.

As far as looking at the packet capture, it is easiest if you filter it to just the device with a filter like:
ip.addr == 192.168.201.20

I don't see any OCSP/CRL validation checks (in run #1) and the timing from what I can see looks like:
051 - 103ms : DNS lookup
114 - 152ms : Socket Connect
159 - 304ms : TLS negotiation
310ms : HTTP Request sent (probably)
1843ms : HTTP Response starts arriving

In this case it looks like the server took ~1.5s to generate the response.
1.5s seems reasonable for this particular old and clunky app. It doesn't explain why start render is pushed back so far though does it? Notice how on this run it gets everything it needs under a second but doesn't start rendering until 4s http://www.webpagetest.org/result/160517...ls/cached/

This occurs even when there's no js or css on the page. Is this something I could figure out using wireshark? There seems to be a lot of communication right up until 3.7seconds when filtering it to that ip. Would that ongoing communication not show up in the waterfall but block the rendering of the page? Sorry if this is a basic question! I need to learn how to read that tcp dump properly
That's a cached page load. "Everything it needs" includes a bunch of resources you can't see coming from cache as well as js execution. You might be able to get a sense for all of the activity that is going on by capturing a timeline in Chrome on Android or debugging it locally with Safari connected to an iPhone but I don't get a lot of visibility into what Safari is doing outside of the network Sad

Chrome tends to be a lot more aggressive about painting (and we're working on making it even more aggressive) so even though Chrome may have a faster render time, the actual browser activity independent of render should still give you an idea of what the page is doing and what Safari might be waiting for.
Ok, I'll try and dig into tracing and see what the browser is doing as well as tethering the iphone locally. I've been through these steps already without much luck but I will have another go.

Because I couldn't figure it out the first time I tried to debug it by isolating the problem. I ended up removing everything piece by piece until there really was nothing on the page: no css, no js, just a couple of tiny images and I still got the same result (on the first load) http://www.webpagetest.org/result/160512...1/details/

I don't have that environment left any more but maybe I should recreate it and see if I can get a tcpdump or tracing from that too.
I'm having the same basic issue, though over a not secured (http://) connection. It seems like image loading is preventing rendering from starting on mobile safari. My page loads and the DOM Content Loaded line is immediately after it, but the Start Render line doesnt happen until all images included via img elements have loaded (and that line happens immediately after those images have loaded).

I have disabled all file includes other than from img elements (no css or js, etc files are loaded, only inline styling).

I have tried setting the width and height attributes on each img element in case not knowing a specific size was preventing safari from rendering, but that didnt help.
Safari in general likes to delay rendering as long as it is doing something that may impact the layout/display of the page so it doesn't have to duplicate work. Chrome is pretty aggressive about getting content on screen as quickly as possible.

I don't know of anyone who has experimented with seeing what it takes to get Safari to render earlier so I'd love to hear if you have any luck with it.
Reference URL's