I logged every tap that did nothing for a week. On a mid-range Android phone the pattern was embarrassingly consistent: the first tap on a freshly loaded H5 game page produced no response at all, the second one hit the button I was aiming at. Put the timestamps side by side and the cause stops being mysterious.
The browser is not slow, it is waiting. After a page settles, a touch can still be read as the opening half of a double-tap gesture, so the engine holds the event for a few hundred milliseconds to see whether a second finger arrives. On a long article nobody notices. On a game where you tap a moving target, the page feels asleep.
The cheap fix is one CSS line: touch-action: manipulation on the tap surface, which tells the engine that zoom-on-double-tap is not wanted here. I test it against two deliberately different shells — the light entry at gowin and the H5 route at h5.ri188 — because a thin page hides the delay while a heavier one keeps it visible under first paint.
Two more things matter as much. Tap targets below 48 px turn into misses as soon as the thumb rolls, and any canvas redraw under a resting finger will swallow the next tap entirely. A browsable demo at rpvip2 and a packaged svip5 apk both load quickly enough to show this plainly: latency is rarely the network, it is scheduling.
Keep the tap surface still, declare the gesture, and measure with a real thumb instead of DevTools touch emulation. The last shell in my notes, hokiwin, is a useful reminder of the boring version: one tap, one response, no ceremony.
Top comments (0)