8

I have a set of iPads (3rd gen) running iOS 9.3.5. This is the highest they support. I am attempting to replace the functionality of a custom iOS app with an equivalent web application. The site is built in Angular 11, targeting es2015, and I've declared iOS > 9 in the browser support file. The majority of the site performs exactly as I would expect for such old devices. The linchpin of the whole thing is this third party form that needs to be filled out that is served up as an iframe, and it performs so, so horribly.

Here is the code of component HTML with the iframe (URL changed for privacy):

<div class="row header"><a class="restart" (click)='restart()'>Start Over</a><a routerLink='/welcome'><i class="fa fa-times close-x"></i></a></div>
<iframe src="https://notarealsite.com" (load)="waiverLoaded()"></iframe>

The waiverLoaded function is a simple boolean flip to detect the embedded page reloading upon completion so that I can route to a different component in my app. The performance is unchanged if the iframe is the only element on the page. Other pages that play nice when embedded do not suffer a performance drop like the waiver does, so I have to assume it's something in the code of the waiver page.

The original custom iOS app uses a webviewer to load the page, and it loads in 2 seconds or less. The same performance can be seen by visiting the page directly in Safari. In both instances the responsiveness of the dynamic form is reasonable given the age of the devices. When loading the page via an iframe the performance tanks. We're talking 30-45 seconds of loading, and sometimes up to a full second delay between tapping a button or field, and the form reacting.

I have attached the device to my computer and used the remote inspector in the MacOS Safari to view the timeline. The majority of the initial load time is the several 1-2 kb image files used by the form like the scroll bar and some icons. Usually one of these items ends up taking 20-25 seconds all for themselves. When interacting with the form there's an XML resource that appears in the timeline every field change or button press, and that is what takes around a second or two before the page is up to date again.

I'm not well versed in troubleshooting web application performance like this, and this is my first real Angular application that I've built, so I might be missing something painfully obvious. What can contribute to such a difference in performance between a page being visited directly, vs being placed in an iframe?

Some additional info:

  • The performance is the same between running locally via npm serve or built and deployed to my local server.
  • I have tried hosting it via HTTP and HTTPS in case it was some security hangup, as the form is only delivered via HTTPS. However I only have a self-signed cert at the moment.
  • I have seen no discernable difference in load times between the two methods on my other devices, including an iPad Air running iOS 12.5.2.
  • There is a warning in the console about jQuery support on iOS 9.3.5 being outdated, but it occurs in both scenarios.

Additional Troubleshooting

I've tried to look into some of the suggestions I've received. I've checked the timings and headers on the slow loading elements in Safari in the following configurations:

  • In the iframe on my app on the iPad.
  • Visited directly on the iPad.
  • In the iframe on my app on my MacBook Pro.
  • Visited directly on my MacBook Pro.

On my laptop the performance is nearly identical. Comparatively, on the iPad the actual load times of all the elements is within a millisecond or two of their times on my laptop. What ends up being notably different is the latency between request and response for the elements.

The latency when visiting directly is higher than on my laptop. When loading through the iframe all the timings increase fairly proportionally. A time of 750ms jumps to 4s. A time of 6s jumps to 30s.

Lastly, a real oddity to me, is the super high latency image for some reason results in a 302 to Cloudflare, but only on the iPad. It doesn't matter if it's through the iframe or direct. Both devices are using the same WiFi network. I can't think of a reason for the redirect to happen unless the destination site is handling the iPad differently somehow. Changing the UserAgent in Safari on my laptop to match the iPad doesn't result in the same redirect.

So I've confirmed that even outside of the iframe the site in question behaves differently on iOS 9.3.5 than on newer versions, and compared to my computers.

Logarr
  • 2,120
  • 1
  • 17
  • 29
  • To whomever decided to VTC, I don't feel a code example is necessary here as it's a pretty cut and dry situation. I can't disclose the URL being used in the iframe, and that's literally all the code involved. – Logarr May 16 '21 at 04:32
  • The iframe tag might me simple but showing how you are using it might help, change the url to http://fakeurl.com – Mauricio Gracia Gutierrez May 21 '21 at 19:45
  • @MauricioGraciaGutierrez I've added it, but I'm confident it's not going to help. – Logarr May 22 '21 at 03:05
  • Check if the answers here can guide you - https://stackoverflow.com/questions/38037760/how-to-set-iframe-src-without-causing-unsafe-value-exception – Mauricio Gracia Gutierrez May 22 '21 at 14:25
  • The URL is fixed, so sanitization doesn’t factor into this, but thank you for trying. – Logarr May 22 '21 at 15:08

1 Answers1

0

Please post your code for us to diagnose and help. In general there is more overhead for an IFrame my suspicion is the jQuery handler or cookie policy, to be sage I also listed other items to check.

  1. It looks like you already checked the previous unsecured elements which was an issue. Both in the network graph and the calls, double check there are no dependencies or URL calls of the Iframe of unsecured elements then it wont display, it used make multiple round trips if Https had mixed content between secure and non-secure stuff, there's a ticket for A new TLS issue.

theres a ticke for A new TLS issue

Once you fix that ensuring its hosted/called securely, clear the cache, cookies, data completely and reloading the page fixes the problem even on mobile browsers.

  1. Redirects/Bouncing Your order of loading scripts/css, if there are dependent scripts and they are not cached it could be blocking, or if its redirecting back to HTTP this will also slow it down.

  2. For IOS mobile apps only (doesn't apply here) - if you are using the 3rd gen, check the default for Cookie Security policy (HTTPCookieAcceptPolicy) for UIWebView has changed to NSHTTPCookieAcceptPolicyOnlyFromMainDocumentDomain

Animations Are slow in safari Iframes


You have the click event in your code, could be the issue

  1. ..."Turns out that any non-anchor element assigned a click handler in jQuery must either have an onClick attribute (can be empty like below):"...

Put the following element declaration cursor:pointer or tap event

Transformer
  • 6,963
  • 2
  • 26
  • 52
  • What additional code would be helpful? It's an extremely barebones Angular application. I have no scripting in play beyond Angular and the Angular Routing module. Also, item 3 leads me to believe you've misread my question. I'm not having an issue with an iOS app. Unless I'm mistaken, that suggestion is for iOS app development. – Logarr May 22 '21 at 18:31
  • thats correct UIWebView is for apps with Iframes, please ignore that. can you give item 4 a shot. – Transformer May 22 '21 at 18:33
  • Further, item 4 does not apply here either, as the event is defined already in the HTML, and not added after the DOM is loaded via jQuery. – Logarr May 22 '21 at 18:33
  • since there is no click event try binding it to the tap event, the previous thread has some more on that. i am trying to replicate this locally and unable to see that slow load, not sure what else to try.. will get back if I find something else – Transformer May 22 '21 at 18:36
  • The click event works just fine, and its presence or absence has no effect on the load times of the iframe. As far as I can tell that entire thread is specifically about a click event not working on iOS, and has nothing to do with page performance. – Logarr May 22 '21 at 18:40