Significant input delay in the game client


During regular usage of the Roblox player client, I as the user can build up significant client-side input delay, hindering my ability to play reaction based games such as (but not limited to) First person shooters, Action games, Obbies, Minigames, etc…

It’s notable are that the client does not have to be ‘lagging’ or bottle-necked by hardware resources. I have recorded that the client can be running on any number just below 60 FPS (for example, 55 fps) with low CPU, GPU, and memory usage, and still build up over 5 seconds of input delay.

Describe ‘Input delay’

The amount of time it takes for a user’s action/input to make changes on the game client. Not to be confused with network latency (such as ping) or the player’s reaction speed.

Describe the behavior

The client starts putting input tasks (such as UserInputService events) from the user, into a queue that can end up to around 400ms, or higher before the input is registered as an event.

Guide to the issue


  • Join any Roblox game with a good average number of instances (bricks, decals, particles, etc…)
  • Find a world position where you can make your Roblox client render enough of the world or spin your camera to the point where you no longer render at 60 fps
  • Gain access to one or more of the following abilities to test your input lag with: walk, shoot, click, jump, interacting with UI


  1. Move your mouse around continuously in a pattern while keeping your fps below 60
  2. Notice your inputs starting to increase in latency
  3. Repeat step 1

Video displaying the issue:

Video A - Stationary mouse

Video B - Moving mouse - Compare with above

What happens in the video:

In the videos I am in a testing place with a fixed camera angle for each test. Directly looking at a difficult to render scene for the Roblox engine, causing me to be consistently below 60 FPS.
In this testing place there is a white frame in the bottom left corner that responds to UserInputService InputBegan events.
This frame will turn green at a random moment, and the user clicks when it appears green on their screen.
The moment the frame turns green, a timestamp is made to calculate how long it took for the user to send a UserInputService event.

Video A:
  • The cursor is stationary and is not moved
  • Average input response time was 289ms

> 263 267 288 276 280 259 296 288 276 296 296 292 359 309 313 263 301ms

Video B:
  • The cursor is moving around
  • Average input response time was over 8 seconds, increasing drastically over time

> 1013 1880 4526 17959 15430ms

Extra information:

  • This issue occurred after a recent Roblox (or Windows) update
  • The issue is 100% reproducible
  • The issue started occurring in an update after 5th of August
Read important Footnotes:
  • Any input is delayed, not just from UserInputService, but that’s what I have decided to use in this example.
  • Even the Roblox Player responds late to things like alt tabbing back into the game.
  • In this testing environment I can easily get over 8 seconds of input latency, but this is just to prove that there is a problem with the game client. In real scenarios this input latency would only be around 300-400ms at worst, but at random. Which in the case of action or rhythm games becomes really frustrating and unplayable.
  • For players that do not have this over 8 seconds of input latency under the same conditions, they still seem to report that their input response time has increased by at least 70ms when their client no longer renders at 60 fps. Which should definitely also be improved upon.
  • Even when I’m in a less graphically challenging game, and have my settings to the lowest, it is still possible for my client to stagger during quick rotations (flicks) of my camera angle. Causing the same input delay effect for a few frames as I am moving my mouse in this motion. But as mentioned before; this is increasingly frustrating as this affects action games a lot.
  • Using the Roblox FPS Unlocker by axstin, and setting the FPS limit to 30 FPS does actually improve on the scene showed the video. No longer causing 8 or more seconds of input latency and only ending up around an average of ~360ms instead. ( Video: ). My theory is that this input latency only queues up when the client is throttling frames. And with the FPS cap being at 30, it no longer throttles to run the scene. However, running at 30 FPS is no solution as this increases your input latency over 100ms by default.
  • This input latency test includes the user’s time to respond (reaction time). Which on the average gamer should be around 230ms. You can calculate your own reaction time here, and subtract that average value from your results. This is nowhere close to scientific, but the results are clear enough that there is evidence of a problem. If you do have the hardware to scientifically calculate response time, I would love to see your results and compare them.
  • This forum post might be related to the issue. The problem discussed is not well documented, so it is not clear if it is actually related. He posted this around the same time as when I first ran into this problem.

System info:

Home build desktop


OS: Windows 10 Home
GPU: AMD Radeon RX Vega 56
CPU: AMD FX-8350 (8 Core 4200 Mhz)
Memory: 8GB Ram

misc & versions

OS version: latest - 1903
GPU version: latest - 19.8.2
CPU Cores/Threads: 8 / 8
CPU Clock: 4200 Mhz
CPU Platform: AM3r2
RAM Size: 2x Kingston 4GB
RAM Type: DDR3-1333 / PC3-10600 DDR3 SDRAM UDIMM
RAM Clock: 667 MHz


Aditional found information

While investigating even more on this issue, I’ve found that the Mouse Move timing under the Timings category is related to the input latency problem.
image *(Ctrl + Shift + F1) in-game.

As I could not find any information on Mouse Move timer on the developer wiki, I can only speculate on it’s meaning and purpose. But I can lay down what it does:

What is the ‘Mouse Move’ timer?

When I as the user move my mouse around, this number increases to match my FPS. My speculation is that this is the update frequency of your mouse movement events in the game.

What I found

With this timer I can identify when the client is having input latency issues as this timer attempts to reach 0.0/s as soon as I stop moving my mouse. As demonstrated in the following video:

But when I test this during the input latency issue I get different results:

In the second video you will notice that the timer does not decrease fast at all and instead takes quite a while to finish. This duration matches very closely to the amount of time it takes for my input to be registered in the game client.

Speculation. This is actually speculation.

With this find I have more evidence that the client has input latency issues related to mouse movement.
My speculation is that when the client can no longer run at the targeted Framerate, it can no longer keep up with the amount of cursor inputs the client receives. And therefore start putting input tasks into a queue for the next frame to handle. Depending on how much the client is throttling, and how much you mouse the cursor, this queue can increase from microseconds to milliseconds, and even to seconds as demonstrated in the post.


This might be an issue I cannot solve in any way I try. This probably has to be looked into by the engineers.
If you’re having this issue right now, you can do the following to reduce the chance of this issue occurring:

  1. You can set your render quality to 1 to decrease the chance of game client throttle.
  2. You can lower the targeted frame rate of your client to 30FPS with the Roblox FPS unlocker to reduce the chance of game client throttle. But as mentioned in my footnotes, this is no solution as this increases input latency to a default 300ms. *Read the Guide before using FPS unlocker.
  3. Wait for officials

Can you attach a profiler dump?

Ctrl+F6 -> Dump -> 64 Frames, this saves an html file to C:\Users\username that you can post here or dm me

Thank you for replying,

Here’s the main profiler dump:

World_MovingMouse_microprofile-20190910-014800.html (4.9 MB)
This profiler dump was made during the most critical example of the latency issue.

I did run into one issue trying to make this dump that I believe is worth mentioning.
Because of my input being delayed by 8~17 seconds, it was tricky for me to create a correctly timed dump. To fix this, I have just been clicking my mouse roughly every second over the duration of 20 seconds and moved my mouse over the dump frames button to get a dump in the middle of the action.

Extra profiler dumps

For your convience, I have made a few extra. All in different conditions to compare with:

World_MovingMouse_microprofile-20190910-014800.html (4.9 MB)
World_StaticMouse_microprofile-20190910-005044.html (5.3 MB)
NoWorld_MovingMouse_microprofile-20190910-000946.html (3.1 MB)
NoWorld_StaticMousemicroprofile-20190910-001045.html (2.8 MB)

World No world
Moving mouse :x: :heavy_check_mark:
Static mouse :o: :heavy_check_mark:

:heavy_check_mark: = Good/Short latency
:o: = Acceptable latency
:x: = Bad/Long latency

World = Compliated to render world
NoWorld = Spawnpoint and character
StaticMouse = Static non-moving mouse
MovingMouse = Moving my mouse around

1 Like

This is an interesting issue which I as well experienced a few days ago.
While using the roblox linked sword, (I was roblox clanning) I found that there was a delay from when I (double clicked) to lunge until it actually lunged. There was a 1-3 second delay which was extremely annoying to fight with. I also noticed that my ping was abnormally high. Hope this can be fixed soon!

(Link to game)

Still experiencing this issue.

I have a feeling your issue is not related to this problem, and instead is an issue with ‘ping’. But I could be wrong!

Let me explain why I think this:

The client communicates with the server on when to perform linked sword actions via the Activated event on a server script. Causing the server to wait for client response, and then replicating the action back to the players and caster.
qnKGdwhRfZ *Sample of Linked sword’s script
Depending on how high your ping might be, and considering you’ve mentioned that your ping is high during this problem. It is very likely that your issue is not related to what I described to be “Input delay”.

If ping is the problem you’re facing, a better description for your problem would be “Network lag”.

Describe ‘Network lag’

The latency of a “network” connection represents the amount of time required for data to travel between the sender and receiver. People perceive unexpected time delays as “lag”.

Describe ‘Input delay’

The amount of time it takes for a user’s action/input to make changes on the game client. Not to be confused with network latency (such as ping) or the player’s reaction speed.


Whoops, may have gotten ahead of myself :stuck_out_tongue:

However it is odd that running at 200-300 ping causes the sword to have a second+ delay.
Sometimes it was responsive, other times not so much. Thanks for the help either way!

(cursor is client sided when I checked)

Inside the video, you can see that it takes a long while before the sword lunges.

EDIT I can add more video footage if wanted/needed. (I would need to sift through the hour and a half long video.)

1 Like

Got the same issue in my game. Some users with FPS lower than 60 get this exact issue. It looks like the UWA version of Roblox is not affected by this.

Got quite some other reports from players about actions they perform being inaccurate (e.g. actions are performed in a different location from where they actually clicked), which I suspect all being related to this too (but it’s hard to debug this with the average player). Players suggest to one another to reduce the Roblox graphics quality, which reduces/resolves issues for them.
I believe this issue causes a lot of confusion among those players.


turns out I’m not the only one with this issue, so I’ll gladly provide more information

More & New information:

During further testing and looking into this issue, there has been a few new discoveries that might help resolve or identify the problem.

Video showing the input delay in-game

I guess I haven’t shown what the input delay might look like in-game yet, but it’s quite hard to visualize. So here’s a video of me moving my mouse in a continues circular motion, but getting slowed down and throttled by the input delay problem.
At the end of the clip you can see all my build up inputs all firing tick by tick ‘catching up’ to real time input.

Describe the behavior

The client starts putting input tasks (such as UserInputService events) from the user into a ‘queue’, that can end up to around 400ms or higher before the input is registered as an event.
Releasing your mouse will make this queue rapidly fire the events in a sequence to ‘catch up’.

Setting processor affinity

image *Taskmanager’s ‘Processor affinity’ window
After some testing, we found that setting the processor affinity for RobloxPlayerBeta.exe to only use physical cores of your CPU reduces how long it takes for the input latency to recover during the ‘catching up’ period. This makes the playing experience slightly better when I combine this with setting my graphics to the lowest level, but this is no solution.

Another interesting find

I am not sure quite how relevant this find is to figuring out the solution as I will describe soon, but I can obtain the same input latency issue while being way over 60fps
In my testing place that I’ve primarily used to replicate this issue, I have made debugging tool that can be used to test environment changes and camera conditions.

Despawn world Re-parents the world into nil, making it no longer render
Hide world Changes all the properties of visual objects to make it invisible, hiding it from view
Toggle auto camera Turns the camera into Scriptable and moves it around automatically
Toggle CoreGui Hides all the allowed CoreGui elements via SetCoreGuiEnabled method

image *Debugger GUI
If I hide the world from view via the Hide world button, enable Auto camera, and load up Rbx FPS unlocker with the no limit option. I can replicate the same fps issue while having over 120fps.
This could be a side effect from using the FPS unlocker tool. But speculating that it isn’t, this could be another clue for the engineers to take a guess on where this issue might originate. (maybe another clue that the issue is FPS throttling, or still related to mouse movement)


This does not happen when you use Despawn world over Hide world.
Only differences I found over the two is ±150fps, and Hide world still processes the rendering queue for all the invisible and disabled objects.

Profiler on Hidden world setting

Another nice side effect from this is that the profiler data has become very minimal and easier to read while still containing the problem (if the problem is even visible in the profiler that is)
image *MicroProfiler

Sample 1: Hidden world, 120fps, Moving mouse, High Input delay
MovingMouse-microprofile-20190916-140339.html (830.6 KB)

Extra info

Sample 2: Hidden world, 150fps, Stationary mouse, No input delay
StationaryMouse-microprofile-20190916-140428.html (721.1 KB)

Extra info

Sample 3: Hidden world, 60fps(capped), Moving mouse, No input delay
MovingMouse-60fps-microprofile-20191008-211311.html (923.4 KB)

Extra info

A few other profiler samples can be found in a previous post above

Another interesting thing to note here is that Sample 1&2 above are in the same setup and scene, but differ in ~30fps purely from just moving my mouse around.

Further testing:

If a dev wants me to test if I can replicate this input delay issues on their game with my machine, feel free to DM me. If you want me to test something on a quick notice (or for the engineers), my discord is DarrenVs#0001

1 Like