Page MenuHomePhabricator portal slow on Safari on iPhone 7 Plus with iOS 13.1.3
Closed, ResolvedPublic


Starting from a fiber connection on uncongested wifi with a 34ms ping time to, the first contentful paint for the portal takes a long time on an iPhone 7 Plus running iOS 13.1.3 accessed from a private browsing session on Safari. Contrast this with w:Main Page, which loads extremely fast.

Original screen recording animated GIF:

3 December 2019 Timeline trace:

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 14 2019, 3:59 PM
dr0ptp4kt updated the task description. (Show Details)Nov 14 2019, 4:03 PM
Reedy added a project: Mobile.
Jdlrobson moved this task from Needs triage to Triaged on the Mobile board.Nov 14 2019, 10:55 PM
Gilles added a subscriber: Gilles.Dec 2 2019, 9:13 PM

Since you were able to record it, was it consistent? Can you still reproduce this reliably?

Since you were able to record it, was it consistent? Can you still reproduce this reliably?

Yes. I just tried again and got the same behavior as recorded in the animated GIF in the Description. It happens with JavaScript turned on, and it's about equally slow even with JavaScript disabled.

Gilles added a comment.Dec 3 2019, 7:27 AM

Have you tried Desktop Safari with a computer on the same WiFi network?

TheDJ added a subscriber: TheDJ.Dec 3 2019, 9:20 AM

FYI: I use an iPhone X with Safari 13.0.3 (iOS 13.2.3) and it's not a problem for me.

Have you tried Desktop Safari with a computer on the same WiFi network?

I don't witness the same sort of slowness with desktop Safari when using the same networks. There it only takes about 1.0-1.5 seconds.

@Jdrewniak are you seeing something similar on your iPhone? What are the specs there?

By the way, I tried this with the non-Private mode and got similar results on the iPhone 7 Plus for both first access and repeat access of web root of

Find attached a Timeline trace.


dr0ptp4kt updated the task description. (Show Details)Dec 3 2019, 3:13 PM

The slowdown seems to be coming from the connection time, and particularly the TLS handshake portion of it:

Followed by very slow request times:

Without details about headers sent and cookies, it's hard to guess if these requests fit in single TCP packets (in which case the issue would be local) or if it is because the browser is waiting a while for TCP acks (which means it's a networking problem, potentially). Having to wait for TCP acks that take a while would be consistent with the TLS handshake taking a while.

A TCP-level problem would be best seen with Wireshark of similar, or maybe the iOS devtools would let you capture that?

A traceroute would also be useful, as well as knowing which IP for the phone is trying to reach.

It seems (?) like all of the network transfer (including TLS handshake, first page, subsequent assets) from this timeline recording happens within 1.5 seconds. That part's okay (even though I wish TLS handshaking and the networking subsystem went faster!). The waiting for layout part, though, at about 8 seconds, seems like it may relate to something with style recalculation, no? The timeline doesn't suggest anything unusual in terms of CPU usage (not sure about memory pressure, but I typically only have one app active).

It looks like the raw timeline file contains IP info and cookies, although not the low level packets one would get via a pcap.

The server IP from that timeline was, routed from Minneapolis. The route from Minneapolis to codfw is really fast (it was also fast from Atlanta to eqiad when checking elsewhere), especially on fiber. I've tried this via both the ISP's DNS resolver and, without and with VPN tunneling for different routes, etc. after phone reboots and all that. Seems like the same symptoms surface on these different connection scenarios, from most vanilla to quatre épices 🤷‍♂️

dr0ptp4kt updated the task description. (Show Details)Dec 6 2019, 12:10 PM
dr0ptp4kt updated the task description. (Show Details)Dec 6 2019, 12:15 PM

I was so focused on the beginning that I missed that. There's a single Layout event of 8.47s, it's simply the browser rendering the page. I have an iPhone 7 plus as well (newer version of iOS) and I can't reproduce the issue.

That being said, since in the initial handshake things are slow as well, it all seems like your instance of Safari is just being very slow. On a fiber connection these durations it takes for the browser to send data are insanely high. To me it feels like the execution of Safari is severely throttled for some reason. Why it affects the Wikipedia portal in particular is mysterious. But it doesn't seem to be related to the content.

It would be interesting for you to record the same thing on a website that is fast to load and that you don't already have a potentially existing HTTP/2 connection nor cached data.

Thanks. I hadn't yet been prompted to upgrade from iOS 13.1.3 (it seems sometimes the carrier backplane configuration is a little slow on that for initiating the prompt), but will try on 13.2.3 and report back later (gotta run now). Meantime, see the attached animated GIF for w:Main Page, followed by a timeline recording captured a little later. Both from pristine freshly instantiated app and browser instances in private mode. In my timeline inspector it implies that initial handshake is around 500ms (although for some reason I can't seem to hover on it). Anyway, looks pretty fast. I tried a larger article on a presidential candidate and that didn't seem to be a problem.

After the update to iOS 13.2.3 the problem went away. So I guess we'll chalk this one up to a browser or OS bug fixed by an OS upgrade.

Thanks Gilles for all of the support!

Gilles closed this task as Resolved.Dec 6 2019, 4:03 PM
Gilles claimed this task.