Apple Captive Network Assistant Slowness Problems on iOS
We were trying to launch a new captive portal page design for a customer and we ran into the strangest issue. Only on iOS devices, we’d see extreme slowness and unresponsive behavior in the Apple Captive Network Assistant (CNA).
Over the course of several days, we made multiple attempts to fix the problem. We tried rewriting our ajax libraries, removing external dependencies, adding elaborate logging functionality and even performing all our calls without SSL. Nothing worked. We also spent a lot of time on the phone with network engineers performing packet captures and we could not isolate the source of the slowness.
After running out of ideas, we decided to have an all-hands meeting with the team to come up with some out-of-the-box solutions. One of our engineers recommended we take a look at the animated GIF background image that was part of the new page design.
At first, we couldn’t see how this could be related. The GIF file loaded extremely quickly in the browser and it wasn’t clear how a static asset could have affected the web service calls made by the portal. Well, it turns out that animated GIFs are extremely CPU intensive, and we discovered that the page was taking nearly 90% of the CPU on test devices when the GIF was animating in the background. After removing the GIF, the CPU utilization of the page went down to almost zero.
We deployed a new version of the portal without the animated GIF background image and it worked flawlessly in the Apple CNA. We believe the reason for this is that the Apple CNA was choking on the animated GIF and basically putting all other processes in the background (like important web service calls) in order to render the animation.
The lesson here is to always do performance benchmarking on portal pages, especially when the Apple CNA is being used. As we continue to learn, the Apple CNA is a severely limited browser and likely does not benefit from the performance optimizations present in modern full-featured browsers.