Web page is loading slower in Kiosk Pro than in mobile Safari?

Suggestions for increasing the speed and responsiveness of content shown in Kiosk Pro include: 

Use the WKWebView Browser Engine

Since it's introduction in 2010, Kiosk Pro has been based on Apple's UIWebView browser, which up until the introduction of iOS 8, was the browser that all third party apps accessing web content were required by Apple to use. UIWebView uses a separate (and slower) rendering JavaScript engine than the native mobile Safari browser, resulting in slower loading of your content. 

In iOS 8, Apple introduced a new browser shell, WKWebView, that is now available to third-party apps and uses the same Nitro engine as mobile Safari. This is now the default and recommended browser engine option for Kiosk Pro. 

Optimize Kiosk Pro Settings

Many of the things that Kiosk Pro does (like hiding the copy/paste menus, for example) are done by manipulating a page at runtime, which extends loading times - while we attempt to optimize these transformations whenever possible, these also contribute to slower performance. 

You can minimize the amount of processing Kiosk Pro is doing by using the following settings:

  • JavaScript API > Access JavaScript API = Never (recommended only if you aren't using our JavaScript API)
  • Memory & Privacy > Clear Cache on Homepage > Off.
  • Advanced Settings > any setting you do not specifically need > Off.

With the settings above, you should see faster performance (although there are the tradeoffs of not being able to use these settings, which you'll have to weigh in the context of your own project).

Increase Touch Sensitivity

The UIWebView and WKWebView browser components interpret and pass touch events to the app. As a result, there's no way for us to increase the sensitivity or speed of a touch event.

UIWebView adds a 300ms delay after you touch anything to determine whether the user is single or double clicking. This delay is one of the most prominent reasons that HTML-based web apps are considered "sluggish" by many users.

In WKWebView, testing has shown that the 300ms delay is only added after a fast tap (<~125 ms), which the iOS interprets as more likely to be part of a double-click 'tap-to-zoom' gesture, and not after a slow tap (>~125 ms).  More detail on this  here

We've had several users see improvements with "sluggish" content by implementing FastClick or another library that eliminates this delay.

Still stuck? How can we help? How can we help?