When people say a controller feels laggy, they usually blame the network. The network matters, but it is only one piece of a longer chain. Understanding the whole chain tells you where a change will help and where it will not. This guide follows one button press from your thumb to the game and puts a realistic time on each stage.
The figures here are typical ranges, not promises. Your phone, router and game will land somewhere inside them.
The journey of one button press
- Your finger lands on the glass and the touchscreen detects it.
- Android delivers the touch to the GamepadOS app.
- The app turns the touch into controller state and sends it.
- The data crosses the link, by Wi-Fi or by cable.
- The PC server receives it and writes it to the virtual controller.
- The game reads the controller on its own schedule.
- The game responds, and the next frame reaches your display.
Stage 1: the touchscreen, 4 to 17 ms
A touchscreen does not report your finger continuously. It scans at a fixed rate and reports at the next scan. A panel that scans 60 times a second can add up to about 17 milliseconds before the phone even knows you touched it. A 120 Hz panel adds up to about 8, and a 240 Hz gaming phone about 4. This is the largest single delay in the chain for many phones, and it is entirely outside the app's control. If you are choosing a phone for gaming, "touch sampling rate" is the figure to look at, not the screen's refresh rate.
Stage 2: Android and the app, about 2 ms
Android hands the touch to the app, and the app turns it into a button or stick value. In our measurements this takes roughly two milliseconds on a current phone using the app's native input path. It rises when the phone is busy with other work, which is one reason a cool phone with background apps closed feels crisper.
Stage 3: sending, well under a millisecond
The app sends the change the moment it happens rather than waiting for a timer. It also repeats important changes a few times in quick succession so that one lost packet cannot swallow a button press. These repeats are spaced a couple of milliseconds apart because three copies sent in one burst would be lost together.
Stage 4: the link, about 2.5 ms by cable or about 10 ms by Wi-Fi
This is the part people blame, and the part you can influence. Over USB a round trip takes about 2.5 milliseconds. Over a well-tuned 5 GHz Wi-Fi network it is closer to ten. Under heavy contention on a crowded channel individual packets can take tens of milliseconds, and those rare slow packets are what players notice most. The average hides them, which is why a Wi-Fi connection can have a great average and still feel unreliable. The guide to reducing input lag lists the ways to cut that variation.
The Wi-Fi figure is a round trip: out to the PC and back as an acknowledgement. The one-way trip that matters for your button press is shorter, and the number includes the PC side.
Stage 5: the PC server, 1 to 3 ms
The server receives the packet, decides which of the repeated copies is newest and writes the state to the virtual controller. Windows and the ViGEmBus driver then present it as a real controller. The server runs at a raised priority so this step does not wait behind other programs.
Stage 6: the game, 0 to 17 ms or more
Games do not react to a controller the instant its state changes. They read it once per frame. At 60 frames per second a new input can wait up to 16.7 milliseconds to be read, and at 30 frames per second up to 33. This is a second large delay outside the app's control, and it explains why the same controller can feel snappy in one game and slow in another. Raising the frame rate shortens it directly.
Stage 7: rendering and the display
Finally, the game draws the result and your monitor shows it. A high refresh rate monitor, a game mode on the TV and turning off heavy post-processing all trim this stage. It is part of what you feel, but it belongs to your display and not to your controller.
Putting it together
| Stage | Typical delay | Can you improve it? |
|---|---|---|
| Touchscreen scan | 4 to 17 ms | Only by choosing a phone with a faster panel |
| Android and the app | about 2 ms | Keep the phone cool and quiet |
| Link | 2.5 ms (USB) or about 10 ms (Wi-Fi) | Yes: cable, band, position, QoS |
| PC server and driver | 1 to 3 ms | Keep the server updated |
| Game input read | 0 to 17 ms or more | Yes: raise the frame rate |
Add those up for a good Wi-Fi setup on a 120 Hz-touch phone and a 60 frames per second game and you get somewhere in the region of 20 to 40 milliseconds from finger to reaction, with the network responsible for a minority of it. That matches what most players feel: responsive and playable, with the occasional tail of slower moments on a busy channel.
What this means for you
- If your Wi-Fi is already on a clean 5 GHz channel, hunting for more network speed will give you little. The remaining delay sits in the phone and the game.
- A faster-sampling phone and a higher game frame rate are the two biggest levers outside the network.
- USB removes both the average and the variation from the link stage. Use it when the rest of the chain is already as fast as you can make it.
- Averages are not the whole story. A steady 12 ms feels better than a connection that is usually 8 ms and sometimes 40. Look for consistency.
When you are ready to tune, start with reducing input lag, and read dropped inputs on Wi-Fi if the trouble is missing presses rather than slow ones.
Try it yourself. GamepadOS is free to start: download the PC server and the Android app, scan the QR code and play. Stuck? The support center and contact form reach a real person.