Fastclick profile

Fastclick is a plugin designed to solve the 300ms click delay on mobile.

On the mobile side, if you click on an element without doing anything to the page, the event flow can be simply interpreted as: Touch -> after 300ms delay -> click.

Here’s how FastClick works:

  1. Listening to thetouchendEvents in thetouchendCalled when theevent.preventDefault()The default is triggered after 300ms is disabledclickEvents;
  2. throughdocument.createEventManually create a mouse event object.
  3. througheventTarget.dispatchEventwillclickEvents are manually dispatched to the current destinationDOMElement.

Enumerate the SINS of FastClick

In fact, FastClick is so buggy right now that it’s been five years since the last update.

But tens of thousands of people are still downloading and using it every week at NPM.

For now, the problems I have with FastClick are as follows:

  • Clicking input on mobile is insensitive and requires multiple clicks to react
  • Tune up mobile phone native soft keyboard card, slow
  • Click through
  • Click wrong (click A, trigger B)

Mobile 300ms delay of past life

“There is a 300ms delay when a mobile click triggers a click event” is widely used in the front end circles. It seems that everyone agrees that this phenomenon does exist. In today’s mobile user experience, 300ms delay is unacceptable. Rely on plug-ins. Look it up on the Internet and everyone’s using FastClick. So, you use FastClick anyway.

Let’s go back to the 300ms delay itself and explore why it exists at all.

In 2007, before the first iPhone was released, there was a problem. When surfing the Internet on an iPhone, the web page basically looked like this:

A decade or so ago, the web was mostly designed for PCS, with no concept of mobile adaptation, resulting in fonts that looked very small and difficult to read.

To deal with this, Apple engineers came up with a variety of solutions, most famously double tap to Zoom. Double – click to switch between zoom and original scale.

How do you determine whether the user is clicking or double-clicking? Here’s Apple’s logic:

If there is no second click within 300ms after the user clicks here for the first time, it is considered as a pure click operation.

This is where the 300ms delay comes in. The browser guesses your intentions at 300ms intervals, trying to tell if you want to click or double click.

How to solve

Since the browser has a logic for deciding whether to click or double click, all we have to do is tell the browser, “Don’t guess, I just want to click, I don’t want to do any double click zoom at all,” and the browser will obediently remove the meaningless behavior detection interval.

Ok, how do you tell? We quote fastClick directly from the NPM official address

In chrome32+ (2014), if the viewport meta tag sets the width of the layout viewport equal to the width of the desired viewport, it tells the browser: “My web page is specially adapted for mobile terminal, not the kind of word with the same size as the ant web page, so I don’t need to double click zoom this operation, quickly put 300ms delay to me off.”

If we set user-scalable=no, we’re telling the browser, “my page is no longer scalable at all,” and browsers are instructed to remove 300ms latency in all versions, not just chrome32+.

In addition to chrome32+, other major browsers such as firefox,IE/Edge and others followed in 2014 and 2015 to fix the issue.

IOS, which started the process, fixed the problem in iOS9.3, released in March 2016.

Note ⚠️, most webView versions of iOS will use WKWebView. In WKWebView, the 300ms delay problem has been solved, but it still exists in the old UIWebView. In fact, UIWebView not only has a lot of bugs, the official has given up on its maintenance, and strongly recommend developers to use WKWebView for development.