A short history of the 350ms tap delay
…and why choosing to opt out of it might not be the best choice.
--
If you’ve used a mobile browser powered by WebKit (such as Safari on iOS), you’ve probably noticed a slight delay before the browser actually responds to your tap. WebKit adds a 350 millisecond delay after your first tap before it actually responds to it. It does this to add a buffer and see if you’re going to tap again, so it can register a double-tap event instead of a single-tap. The double-tap gesture is used to zoom in on a webpage – once you’re zoomed in, you can also double tap within the top and bottom 1/4th of the screen to scroll up and down respectively. This is especially helpful if the page is not optimized for mobile. When Apple first implemented this, the feature was supposed to help make existing websites (that were optimized for desktops) viewable on mobile. At the time, I don’t think they expected mobile websites of the future to look like apps, and be designed mobile first.
However, as responsive web design started becoming more and more popular, developers optimized their content for consumption on mobile. Ideally, text is sized appropriately and actionable elements have adequately sized hit areas. In most cases, this does away with the need for double-tapping to zoom in. This is where the 350ms delay detracts from the overall experience. Each tap with the attached delay feels like a browser hiccup, irrespective of how buttery smooth the interactions are, and how performant the webpage actually is. That’s the thing about perceived performance — It doesn’t matter how many milliseconds you managed to shave off your load time if it doesn’t feel fast from the user’s point of view, and the delay definitely doesn’t help by making the mobile web seem sluggish in general.
A little while ago, I replied to a tweet about the delay on iOS, mentioning how this only makes it easier for naysayers to dismiss the mobile web’s potential, and a bunch of people seemed to agree with me:
When they first started running into this issue, developers tackled it in different ways. Some came up with clever hacks, and some ended up using libraries such as FastClick or rolling their own solution. There was a pretty long (and informative) discussion on G+ a couple of years ago where people chimed in with their preferred method of overcoming the delay on mobile along with the UX tradeoffs involved in doing so. Eventually, Chrome came up with a smart solution to this issue, without having to force developers to disable scaling, and Firefox followed suit some time later.
Yesterday, WebKit finally implemented a change that did away with the delay on webpages that do not allow the user to zoom in or out. This is awesome, but there’s a little catch. This change is opt-in. It only applies to webpages where the developer explicitly disables scaling by using the user-scalable=no or initial-scale=1,maximum-scale=1 attributes as part of their viewport meta tag. This removes the delay just fine, but it also removes the user’s ability to use the pinch-to-zoom gesture.
This is a huge accessibility flaw!
Many developers place a lot of emphasis on making sure their product works well on iOS, and this change may well just encourage some of them to (unknowingly) make their websites inaccessible. Pinch-to-zoom is a commonly used interaction on touch screen devices, irrespective of whether you’re using a native app or the web. Many users depend on it while browsing the web, and as a side-effect of removing the delay, you might render your website completely unusable to them. Even if your website is responsive and your content fits screen bounds, it won’t necessarily be readable for everyone trying to use it. In the off chance that this seems like an okay thing to do, my grandma would like a word with you.
Whether or not you should disable scaling for your website or webapp on mobile depends completely upon your use-case, implementation and target audience. Take some time to figure out whether it’s really worth it to ship a change that might end up affecting some of your users negatively.
Everyone deserves to be able to use the web as well as you can.
Update: While the commit with this change has made it into WebKit, an engineer working on confirmed that it’s unlikely that we’ll see this change in WebKit which will ship alongside iOS 9.1. This probably means that we have to wait for the next release cycle, which, unless something changes on Apple’s end, will probably be about a year from now. Until then, using FastClick is probably your best option.
