Mobile 300MS click-through delay

Mobile 300MS Click-through delay and click-through problem one, mobile 300ms click Latency

In general, if the mobile browser is distributing the Click event without special processing, there will usually be a delay of around 300ms. That is, when we click on the page, the mobile browser does not respond immediately, but will wait for a few moments before the effect of clicking. In the early days of the mobile web, users ' sense of 300ms latency was not obvious. However, as users increasingly demand an interactive experience, the Click latency of mobile 300ms is becoming apparent and unbearable today.

So, how does the click Latency for mobile 300ms come from?

Origin of the problem
This goes back to the beginning of 2007. Apple, on the eve of the launch of its first iPhone, encountered a problem: the site was designed for large-screen devices. So Apple's engineers made some promises to tackle the problem of the IPhone's small screen browsing desktop-side site.

The most famous of these is the double-click scaling (double tap to zoom), which is the main reason for the 300 millisecond delay.

Double-click Zoom, as the name implies, using your finger to quickly click on the screen two times, and IOS comes with a Safari browser that zooms the page to its original scale. So what's the connection to the 300 millisecond delay? Suppose such a scene. The user clicked on a link in IOS Safari. Since the user can double-click the zoom or double-click the scrolling operation, when the user taps the screen one time, the browser does not immediately determine whether the user is really going to open the link, or want to double-click the operation. As a result, IOS Safari waits 300 milliseconds to determine if the user clicked the screen again. Given the success of the iphone, other mobile browsers have replicated most of the iphone Safari's conventions, including double-click zooming, which is now available in almost all mobile browsers. Before people just touch the mobile page, in the joy of the time often do not care this 300ms delay problem, but now touch interface like springing up, the user to the experience of higher demand, this 300ms brings the lag slowly become difficult to accept.

In other words, the mobile browser will have some default behavior, such as double-click Zoom, double-click Scrolling. These behaviors, especially double-click scaling, are primarily designed for desktop Web sites on the mobile side of the browsing experience. When the user is working on the page, the mobile browser will prioritize whether the user wants to trigger the default behavior.

What is the solution to this problem?

Browser Developer's Solution

Browser developers need to improve the design of the mobile browser itself to provide long-term solutions.

At present, the browser developer's solution mainly has three kinds of solutions:
Scenario One: Disable scaling
When the HTML document header contains the following meta label:

<meta name="viewport" content="user-scalable=no"><meta name="viewport" content="initial-scale=1,maximum-scale=1">

Indicates that the page is not scalable, the ability to double-click the zoom is meaningless, the browser can disable the default double-click Scaling Behavior and remove the 300ms click Delay.
One drawback of this scenario is that you have to remove the click Delay by completely disabling scaling, but disabling scaling completely is not our intention, we just want to disable the default double-click scaling behavior so that you don't have to wait 300ms to determine whether the current operation is a double-click. But usually, we still want the page to be scaled using two-finger zooming, such as zooming in on a picture and zooming in on a small piece of text.

Scenario Two: Change the default viewport width
Initially, in order for the desktop site to be displayed in the mobile browser, the default viewport width of the mobile browser is not equal to the width of the device browser window, but rather larger than the device browser window width, usually 980px. We can set the viewport width to the device width using the following tabs.

<meta name="viewport" content="width=device-width">

Because double-click scaling is mainly used to improve the desktop site in the mobile browsing experience, and with the popularity of responsive design, many sites have been the mobile sit-up and optimization, this time do not need to double-click scaling, if you can identify a site is a responsive site, Then the mobile browser can automatically disable the default double-click Scaling Behavior and remove the 300ms click Delay. If the above tag is set meta , the browser can assume that the website has been adapted and optimized for the mobile side without double-clicking the zoom operation.
The benefit of this scheme over scenario one is that it does not completely disable scaling, but simply disables the browser's default double-click Scaling behavior, but users can still zoom in and out of the page with a two-finger zoom operation.

Scenario Three: CSS touch-action
I am puzzled by the many articles on the web that boil down to this scenario as a pointer event.

In my understanding, the pointer event is not intended to solve the 300ms click Delay, but to use a separate event model to handle multiple input types, such as mouse, touch, and touch. In other words, the mobile browser does not have to design different events for different input devices, and the developer of the Web page will not have to write different event response codes for different input types of devices, but can develop applications across different input type terminals through unified pointer events.

Associated with 300ms Click Latency, this is touch-action the CSS property. This property specifies the default behavior of the user agent (that is, the browser) that can be triggered on the corresponding element. If the property value is set to touch-action: none , then the action on that element does not trigger any default behavior of the user agent, and there is no need for a 300ms delay judgment.

If you set this CSS property or not, pointer events should all work. Therefore, the online article makes me very puzzled, hoped that the great God can give me the instruction ~. ~

Existing Solutions

To solve the problem of 300ms click Latency, in the long run, it is natural for the browser developers to provide a unified final solution. However, so far, the above three options do not provide a good compatibility, for scenario I and two, Chrome is the first to support, Firefox followed, but the headache for safari, it is in addition to double-click the zoom and double-click Scrolling, if the two options, That is bound to even double-click scrolling together to disable, for scenario three, IE is supported, but other browser support is not perfect. For details, see this article: Mobile Click300 milliseconds Click the ins and outs of the delay (go).

So, before the final unified solution for browser developers comes out, we have some JavaScript-based solutions available.

Scenario One: Polyfill of pointer events
Most browsers now do not support pointer events, except IE. There are some JS libraries that allow us to use pointer events in advance, such as

• Google's polymer
• Microsoft's Handjs
• The-harris of the @Rich Points

However, what we are concerned about is not the pointer event, but the CSS properties associated with 300ms latency touch-action . Since most browsers other than IE do not support this new CSS property, the Polyfill of these pointer events must somehow be emulated to support this property. One scenario is that JS goes to request parsing of all stylesheets, and the other is a property that will be touch-action used as an HTML tag.

Scenario Two: Fastclick
Fastclick is a lightweight library developed by FT Labs specifically to address the 300 millisecond Click Latency issue for mobile browsers. The Fastclick implementation principle is that when the Touchend event is detected, a DOM custom event is immediately set up to simulate a click event and block the browser's click event after 300ms.

Second, click through the problem

After talking about 300ms latency on the mobile side, we have to mention the problem of mobile click-through. Some people may think, since Click has 300ms delay, that for touch screen, we directly listen to the Touchstart event is not good?
There are two bad places to use Touchstart to replace the Click event.
First: Touchstart is the finger touch screen trigger, sometimes users just want to swipe the screen, but triggered the Touchstart event, this is not the result we want;
Second: The use of the Touchstart event may cause a click-through phenomenon in some scenarios.

What is click through?
If there are two elements a and B on the page. The B element is above the a element. We register a callback function on the Touchstart event of the B element, which is the function of hiding the B element. We found that when we clicked on the B element, the B element was hidden, and then the a element triggered the Click event.

This is because in the mobile browser, the order in which the events are executed is Touchstart > Touchend > click. The Click event has a 300ms delay, and when the Touchstart event hides the B element, the browser triggers the Click event after 300ms, but at this point the B element is missing, so the event is distributed to the a element. If the A element is a link, then the page will jump unexpectedly.

Mobile 300MS Click-through delay