Why Is RDP Sluggish on a Fast Connection? — Separating Input, Rendering, and the Network

A speed test reports hundreds of Mbps, yet in Remote Desktop characters appear a beat late. Scroll a page full of photos and the screen hitches even more.

The key to making sense of that discrepancy is this: being able to carry a lot of data and getting a quick answer to an action are two different things. On top of that, the screen that comes back as the answer is produced on the host PC and displayed on the PC in front of you. It is not work the network link does by itself.¹

On the same remote screen, let us follow what changes as you go from typing, to scrolling, to running a search in a business application. Sections 1 to 4 explain the mechanism, and section 5 onward is the investigation part, for actually looking into it.

1. A Faster Link Does Not Necessarily Shorten the Wait for an Answer

Suppose you type one character into Notepad on the remote machine. What you see is the screen right in front of you, but Notepad is running on the host PC. Your action is sent over there, the information about the changed screen comes back here, and the character appears.

So what part of that round trip does the “500 Mbps” from a speed test represent?

It is a figure for how much data can be carried in one second. That capacity is what matters when the file you are downloading is large. What you notice when you type a single character, on the other hand, is the time from the key press until the result comes back. It is like the difference between adding lanes to a road and shortening the distance to your destination.¹

For the sake of explanation, assume the action takes 50 milliseconds to reach the host and the resulting screen information takes 50 milliseconds to come back. In that case the time spent on the network alone adds up to 100 milliseconds, or 0.1 seconds. The processing time on the PCs at both ends is set aside here for the moment.

flowchart TB
    accTitle: Example of the network time before the result of one character comes back
    accDescr: An example that assumes 50 milliseconds each way for the sake of explanation. It excludes the processing time at both ends and does not represent a packet count per key.
    A["Type one character locally"] -->|"Outbound, 50 ms"| B["Host receives the input"]
    B --> C["Send the screen with the input applied"]
    C -->|"Return, 50 ms"| D["The result arrives at your machine"]

Figure 1: If the trip out takes 50 milliseconds and the trip back 50 milliseconds, the network alone accounts for 0.1 seconds. These are not measured values.

This time to travel across the network and back is called the round-trip time (RTT). Even if you switch to a link that can carry more, the wait for an answer in Figure 1 remains as long as the round-trip time stays the same.¹

That is why downloads can be fast while typing still lags by a beat. Next, consider the case where, on the same connection, typing gives you no trouble but scrolling turns sluggish.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (7 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. Scrolling Increases the Work of Sending the Screen

When you add one character in Notepad, only a small part of the screen changes visually. Scroll a page lined with photos, however, and a wide area of the display changes one frame after another.

RDP does not send the whole screen uncompressed every time. It sends the regions that changed and holds the traffic down with compression and caching suited to the content. The amount of work involved in updating and sending differs between adding one character and photos that keep moving.²

flowchart TB
    accTitle: How the screen workload changes between typing and scrolling
    accDescr: A small character change and a continuous update over a wide area differ in the nature of the work of producing and sending the screen.
    A["Add one character in Notepad"] --> B["A small region changes"]
    C["Scroll a screen full of photos"] --> D["A wide area changes continuously"]
    B --> E["Compress and transfer according to the change"]
    D --> E

Figure 2: On the same connection, the amount of work differs between adding one character and a wide area that keeps moving.

As a result, things can feel light while you are reading a static document and yet the graphics transfer can run out of headroom once you start scrolling. Raising the resolution on the remote side or adding monitors also enlarges what has to be produced and sent.²

Only now does it become clear why lowering the resolution and comparing is worth doing. It is not a magic spell for making RDP faster but an experiment to see whether responsiveness returns once you reduce the work of producing and sending the screen. Section 5 covers how to try it in detail.

If typing is fine but only scrolling is sluggish, it may be because the same link is handling far more screen updates. What, then, about the case where the link still has headroom but the screen cannot keep up?

3. Even When the Link Is Idle, the PC Producing the Screen Can Keep You Waiting

The Screen Is Processed Both Before It Is Sent and After It Is Received

When you scroll a page of photos, the host PC updates the display and converts and compresses the screen information into a form that is easier to send. That is encoding. The PC in front of you turns the arriving information back into a form it can display. That side is called decoding.¹

flowchart TB
    accTitle: Screen processing happens on both sides of the link
    accDescr: Compression on the host, transfer over the network, and decoding and display on your own machine are separate steps, and screen updates fall behind if any one of them cannot keep up.
    A["Host produces and compresses the screen"] --> B["Link carries the screen information"]
    B --> C["Local machine turns it back into a displayable form"]
    C --> D["Shown on the local screen"]

Figure 3: Compress on the host, carry it over the link, turn it back into a display on the local machine. Each is work done in a different place.

Suppose, for example, that compressing the screen on the host is taking time. Even with an idle link, you wait until the information to send is ready. Conversely, even when the information has arrived, the screen update is late if the local PC cannot keep up with decoding and display.³

The reflex is to think that the office PC is powerful, so anything will do at the local end, but the local PC still has the job of displaying the screen it receives. Headroom on the link and headroom in the processing at both ends are two different things.

If Only One App Freezes, You May Be Waiting on That App’s Answer

Now consider a case where, on the same remote screen, pressing Search in a business application freezes it for several seconds. Meanwhile, suppose you can type normally into a Notepad window open next to it.

In that case you want to see what the business application is waiting for. The app on the host may be asking a separate database to run the search, and the answer may be slow to come back. Reading a file from a shared folder produces the same kind of wait.⁴

flowchart TB
    accTitle: There is another party to talk to beyond RDP
    accDescr: Shows the case where, apart from the traffic that links the local client and the host, the app on the host waits for an answer from a business server.
    A["Local client"] -->|"RDP"| B["Business app on the host"]
    B -->|"Search or file request"| C["Database and shared folders"]
    C -->|"The answer the app is waiting for"| B

Figure 4: The business application beyond the RDP connection may in turn be waiting for an answer from yet another server.

Also, when the code responsible for an app’s screen and input takes on a long task, it cannot get to the next input or screen update. A WPF UI thread that stays occupied for a long stretch, for example, produces exactly this kind of delayed response. Watching only overall CPU utilization can leave you blind to a wait in the code that handles the screen.⁵

Just because you are waiting on an RDP screen does not mean RDP is what is keeping you waiting. That difference of “Notepad works but only the search freezes” is a clue you can find before changing any network settings.

4. Summary So Far: Link Speed Is Only Part of Responsiveness

Let us return to the opening question: why is it sluggish when the link is fast?

In the typing case there was a wait for an answer between sending the action and receiving the result. In the scrolling case the amount of screen to update and send went up. And the app that produces that screen, along with the graphics processing on the PCs at both ends, takes time as well.

A big number from a speed test alone does not tell you whether these three are in good shape. What is more, the speed test server and the RDP host that sits beyond a VPN or gateway are reached over different paths. The upstream direction on the host that pushes the screen out, and congestion along the way, are involved too.¹⁴

How comfortable RDP feels is decided not only by how much can be carried but by how quickly the result of an action becomes visible. That is the end of the explanation of the mechanism. When you actually investigate the slowness, use the investigation sections below to pick the comparison that fits your symptom.

5. Investigation: First, Compare the Same Action One Condition at a Time

The investigation examples assume the Windows Remote Desktop Connection client and a Windows 11 or Windows Server host. The command examples target Windows PowerShell 5.1. On a company device, keep comparisons within the scope your administrator permits, and save your work before changing settings and reconnecting.

Use the three cases above as the entry point for choosing a comparison. The table is not a verdict on the cause but a starting point for investigation.

If the sign-in screen takes a long time to appear, or things stall at authentication alone, start by examining the records for connection establishment and authentication. The entry point for that investigation differs from the post-connection input and scrolling covered here.

Is Another App Delayed in the Same Way?

Type about the same amount of text in the problem app and in Notepad. Comparing inside the same remote session first lets you see the difference between apps without changing the host or the link. In Task Manager, check the target app’s CPU, memory, and disk on the host, and the load of the RDP client on your own machine.⁴

When you compare on another client or another permitted path, repeat the same action there too, and record the result after reverting as well. On a host used by multiple users, make sure you are looking at your own session and processes.

flowchart TB
    accTitle: Limit the conditions you change at once
    accDescr: A flow that fixes an action reproducing the problem in the original state, changes one condition only and compares, then also checks the result after reverting.
    A["Same action with the original settings"] --> B["Change only one condition"]
    B --> C["Repeat the same action"]
    C --> D["Revert and check again"]
    D --> E["Record the condition that improved things"]

Figure 5: Repeat the same action in the original state, after the change, and after reverting, and record which condition made the difference.

Comparing by working at the host’s physical screen is also informative. Note, however, that the session and the rendering conditions can differ between local operation and RDP. Match the user, the data, and the application state, and do not pin the cause on the link just because “it is fast at the physical screen.”

When Scrolling Is Sluggish, Lower the Resolution on the Remote Side

Change either the monitor count or the resolution first, then scroll the same page. With mstsc on Windows, you can compare using the Display settings before connecting or by specifying a width and height. Check that the host’s desktop actually changed size, not just that the window on your machine got smaller. Sometimes a large screen is merely being shown scaled down.⁶⁷

3840×2160 has four times the pixel count of 1920×1080, but that does not mean the traffic is always four times as much. It varies with the regions that changed and with how well compression works. Lowering the resolution also changes the graphics processing at both ends, not just the traffic, so if it improves things, take that as the range where the clue lies.²³

flowchart TB
    accTitle: What a lowered-resolution comparison can tell you
    accDescr: Lowering the resolution on the remote side can change both the graphics processing and the transfer load, so an improvement alone cannot pin the cause on the link.
    A["Lower the resolution on the remote side"] --> B["Graphics processing on the host changes"]
    A --> C["The amount of information sent changes"]
    A --> D["Display processing on your machine changes"]

Figure 6: Changing the resolution is a comparison that affects not only the link but also the graphics processing on the host and on your own machine.

Changing several conditions at once, such as dropping to a single low-resolution screen, gives only a rough comparison. After it improves, revert one at a time to separate the effects, and choose the settings you will use day to day with text legibility in mind as well.

Does It Slow Down Once a Copy or Print Job Starts?

More than the screen flows over RDP: information for drives, printers, and other devices travels too. Redirection, which makes your local devices usable on the remote side, can increase the network and processing load while it is in use. Pause copies, cloud sync, and print jobs that you started yourself, within what you are permitted to do, and compare.⁴

flowchart TB
    accTitle: View the period before and after the trouble on one timeline
    accDescr: Record the same action and the load before a transfer, during it, and after stopping it, and compare how the trouble relates to that work.
    A["Action and load before the transfer"] --> B["Action and load during the transfer"]
    B --> C["Action and load after stopping it"]
    C --> D["Whether the trouble and the recovery line up"]

Figure 7: See how the slowness of the same action and the load change before the transfer, during it, and after stopping it.

You can also compare redirection of unneeded devices one at a time. This is not a procedure for disabling the audio and input devices the business needs in one sweep, or for stopping company backup or security processes on your own initiative.

6. Investigation: Confirm Where the Wait Is With Numbers

Confirm the comparisons from section 5 with measurements. For typing, look at the numbers for the network and the input wait; for scrolling, at the numbers for graphics processing.

From Your Machine: Examine the Network Round Trip and the TCP Connection

The following is an example on your own Windows client. It assumes you connect directly to the RDP host over the corporate LAN or a permitted VPN, and that the host uses the standard TCP port 3389. Going through RD Gateway or Azure Virtual Desktop changes both what you check and the path taken. Do not expose ports or change firewall settings.

$target = Read-Host 'Name or IP address of an RDP host you are permitted to investigate'
if ([string]::IsNullOrWhiteSpace($target)) {
    throw 'Specify the host to connect to.'
}

# Look at the ICMP response time several times. A failure alone does not prove RDP is unreachable.
ping.exe -n 20 $target

# A check limited to configurations that connect directly to the standard TCP port 3389.
Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed

ping examines the response time to ICMP. If the values swing widely during the slow time of day, record that. ICMP can also be blocked, in which case nothing responds. Conversely, a run of small values does not mean you have examined RDP graphics transfer or app processing.⁸

TcpTestSucceeded: True is a result saying the TCP connection to that port succeeded. It measures neither bandwidth, nor UDP, nor how smooth operation and the screen are after authentication. Test-NetConnection has no -UDP switch for examining UDP.⁹

Twenty ping probes is a short observation. For intermittent trouble, cross-check the time of the symptom against the connection information. Azure Virtual Desktop also makes per-connection RTT and estimated bandwidth available, but do not rule out brief stalls on the strength of averages alone.¹

On the Host: Examine the Wait Until the App Picks Up the Input

Open perfmon.exe inside the remote session on the host and, where the environment supports it, add User Input Delay per Process or User Input Delay per Session. Selecting the target session and process lets you observe the wait between input being queued and the app picking it up.¹⁰

flowchart TB
    accTitle: The interval that User Input Delay measures
    accDescr: The measured interval runs from the input queue on the host until the app picks the input up, and it does not include the network or the screen display before and after.
    A["Input arrives from your machine"] --> B["Enters the input queue on the host"]
    B -->|"This is what is measured"| C["The app picks up the input"]
    C --> D["App processing and graphics transfer"]
    D --> E["Displayed on your machine"]

Figure 8: What is measured is the wait in the input queue on the host. That is not the total time until the result becomes visible on your machine.

The value is the longest wait within the measurement interval. It is supported on Windows 10 version 1809 and later and on Windows Server 2019 and later, and on those targets no registry entry is needed to enable it. Observe at the default one-second interval to start with. Check the display names, the counters available, and the permissions required against your own environment.¹⁰

The standard per-process instance name is SessionID:ProcessID <Process Image>. From PowerShell in the same session, note the time and the session ID.¹⁰¹¹

Get-Date -Format 'yyyy-MM-dd HH:mm:ss.fff zzz'
(Get-Process -Id $PID).SessionId
query.exe session

Displaying other users’ sessions can require additional permissions. Cross-check against the administrator’s records as needed, and strip user names and host information the business does not need from any logs you share.¹¹

Even when this value is low, the processing after the app picks up the input and the delay until the resulting screen comes back both remain. The interval it measures differs from the round-trip time in section 1 and from the perceived time between pressing a key and the character appearing.

On the Host: Examine Whether Screen Updates Are Being Sent in Full

For stuttering while scrolling, use the RemoteFX Graphics counters where they are available. Check the target session name with query session or qwinsta and select the matching instance. Where a counter measures and whether it is available need to be confirmed against the OS, the host configuration, and your permissions.³

During an operation that updates the screen, compare Input Frames/Second with Output Frames/Second. If the output is lower than the input, frames are being dropped along the way. Looking at the Frames Skipped/Second values broken out by insufficient host, network, and client resources gives you a clue for narrowing down where to investigate.³

flowchart TB
    accTitle: Narrow down where to investigate from dropped frames
    accDescr: Compare the input and output frame counts during an operation that updates the screen and, using the counters for the reason frames were dropped as a clue, cross-check against the processing, network, and display load.
    A["Compare input and output while scrolling"] --> B["If the output is lower, check for dropped frames"]
    B --> C["Look at the counters broken out by reason"]
    C --> D["Cross-check with the host, network, and local load"]

Figure 9: Compare input and output while scrolling, and cross-check the reason for dropped frames against the load on the host, the link, and your own machine.

When the frame count is low on the input side to begin with, the app may simply not be updating the screen often. A low frame count on a static screen is not abnormal. If there are updates and it is still slow, also look at Average Encoding Time to see whether compression on the host is taking time.³

A note on reading measurement documentation. The diagram in section 1 is a conceptual one for understanding ordinary graphics transfer, not a claim that an independent round-trip packet is sent per key. Some configurations transfer video and audio through a separate mechanism. Use the Azure Virtual Desktop connection quality logs, and the Graphics counter documentation that still covers older configurations, only after confirming what the feature applies to. Do not read the numbers in such documentation as a shared specification like “all RDP is capped at 30 fps.”²¹³

7. Investigation: Choose the UDP and GPU Settings to Match What You Found

If the Network Is Suspect, First Confirm the Actual Path and Transport

RDP uses TCP or UDP depending on the configuration and the network conditions. The “Select RDP transport protocols” policy lets you choose between a setting that uses UDP or TCP and a setting that uses TCP only. Since there is also behavior that uses TCP when a UDP connection cannot be established, the fact that you connected tells you nothing about the transport. Confirm it from the client’s connection information, the product’s diagnostic logs, and the administrator’s network records.¹²

flowchart TB
    accTitle: Confirm the transport before comparing network settings
    accDescr: Distinguish an ordinary direct connection from one through a gateway or a service, confirm the actual path and transport, and only then run the comparisons you are permitted to run.
    A["The client in use and the connection configuration"] --> B["Confirm the actual path and whether TCP or UDP"]
    B --> C["Cross-check with the time of the symptom"]
    C --> D["Compare only the settings you need, one at a time"]

Figure 10: Confirm the transport and path in use, cross-check them against the symptom, and only then compare the settings you need.

RDP Shortpath in Azure Virtual Desktop is the mechanism that establishes a UDP path for that service. Including how direct paths and relays are used, it cannot be put in the same settings table as connecting to an in-house PC directly with mstsc. When Shortpath cannot be established, the connection falls back to a TCP-based one.¹³

Do not change things across the board on the idea that turning UDP off makes it faster. Match the transport in use, the policies, and the VPN or gateway conditions, then compare. Disabling the firewall or authentication, or exposing the RDP port directly to the internet, are not remedies to apply.

If Graphics Processing Is Suspect, Check Whether the GPU Is Used for It

Even when a GPU is present, it does not follow that the host app’s rendering, RDP’s encoding, and your machine’s decoding all use it. Microsoft’s GPU configuration documentation likewise configures and verifies rendering in the remote session and hardware encoding of frames separately. Examine the supported OS versions, drivers, policies, and client requirements.¹⁴

If section 6 showed that the compression time is long, that is the point at which to check GPU use for encoding. Changing encoding settings for an app that is waiting in the input queue aims at the wrong place. Work where you want text to be legible and work where you want video to look smooth also call for different choices among image quality, traffic, and processing load.¹⁴²

Developers of business applications can trace the waits inside an app by recording the time an input event was received, the start and end of database and file processing, and the moment the result reached the UI, each separately. A design that keeps heavy work from settling on the UI thread matters too. Note that a processing-complete log on the host is not a record of the display completing on your own screen.⁵

8. Notes Worth Leaving When You Hand the Investigation Over

Describe the slow action concretely, as in “typing in Notepad is normal, but scrolling photos stalls.” Leave behind the conditions you tried and the results as well.

Time the symptom occurred, with time zone:
Host OS, client in use, and versions:
Direct connection / VPN / RD Gateway / Azure Virtual Desktop, and so on:
The slow action and app, and how other apps in the same session respond:
Resolution and monitor count on the remote side:
Copies, print jobs, and the like running at the same time:
The one condition changed, and the result after reverting:
Load and counters observed on the host and on your machine:

How much can be carried, how long you wait for an answer, and how long it takes to produce and display the screen. Once that distinction is clear, you stop putting “RDP is slow” down to a single cause and can start from the action that is slow right now.

Related Articles

• How to Think About Windows Session Isolation
• Isolating a Windows Disk at 100% Safely
• Why Does “1 Second Remaining” Take So Long?

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

A speed test reports hundreds of Mbps, so why is RDP input slow?

How fast large amounts of data move and how long an action takes to come back are two different things. Sending the input, the app processing on the host, compressing the screen, transferring it, and displaying it on your own machine all play a part. The speed test server and the RDP host are also reached over different network paths.

Typing is fine but only scrolling stutters. Is that a network problem?

You cannot narrow it down to the network alone. When screen updates increase, the rendering and compression on the host, the transfer, or the decoding and display on your own machine may fail to keep up. Change the remote resolution and the monitor count one at a time and compare, then look at the graphics counters if needed.

If ping is fast, is RDP communication healthy?

That alone does not settle it. ping measures the response to ICMP, and it does not measure RDP graphics transfer or app processing. In configurations that go through RD Gateway and similar, the path may not match either. When there is no response, distinguish ICMP being blocked from RDP itself being unreachable.

Is User Input Delay the time from pressing a key to the character appearing?

No. It is a counter that measures how long input waits on the host after it is queued until the process picks it up. It is not the perceived delay that includes the network round trip, the app processing after the input is picked up, and compressing, decoding, and displaying the screen.

Should I disable UDP when RDP feels slow?

Not as a blanket recommendation. First check the transport actually in use, the path, and the policies applied. UDP may be unavailable and the connection may have fallen back to TCP, so switching to TCP only does not always make things faster. Compare under matched conditions with your administrator's permission, and revert changes that turn out to be unnecessary.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.