Lag, Low FPS, or Stutter? How to Tell What Is Actually Slow#

Research checked: 11 September 2026
A source-led diagnostic guide prepared for lag.repair. The comparisons below are proposed procedures, not original benchmark results. Platform-specific controls must be checked against the version in use.

A game can look smooth but respond late. It can respond promptly and still pause during movement. It can also render smoothly while positions in an online match jump. Calling every problem “lag” is understandable, but it does not tell you which setting, component, or service needs attention.

Start with the event that seems wrong. Low FPS describes a low frame-production or presentation rate; stutter describes uneven progression; input delay describes a late response to an action. Network timing is another part of an online interaction, not a substitute for measuring the whole experience. A system may have more than one problem. NVIDIA's technical explanation separates network latency from the peripheral, computer, and display stages of system latency. [1]

The aim of this guide is not to name a faulty component from a symptom. It is to help you choose a useful next comparison—and avoid spending money before the evidence supports it.

Start with what you can observe#

These are investigation routes, not automatic diagnoses. Frame deadlines, network buffering, and display processing are distinct mechanisms; the supporting documentation explains why the comparisons are worth separating. [1, 3, 5, 6, 7]

Before changing anything, write one sentence that another person could check: “Entering this room produces a visible pause,” or “The character moves back to an earlier position during online play.” “My computer is bad” is not an observation precise enough to test.

Why high FPS can still look uneven#

An average answers how much happened over an interval. It does not describe how evenly the events were spaced.

Consider two constructed sequences of four frame intervals:

Both contain four frames over 0.04 seconds, so the aggregate rate is 4 / 0.04 = 100 FPS. Sequence B nevertheless contains a much longer interval. This is arithmetic, not a device test or a claim that all viewers perceive the difference identically. It also is not the arithmetic average of four instantaneous FPS values, which would be a different calculation.

For a real interruption, keep a time-ordered frame record when the application or a suitable supported tool provides one. A short numerical counter is not enough to reconstruct the pause. Android's rendering documentation similarly treats missed presentation deadlines as a source of visible jank and describes tracing for investigation. Its tools and thresholds belong to the supported Android environment, not to every game engine. [7]

A useful first comparison#

Choose a repeatable scene and record what happens on the first traversal and on another traversal. Keep the application version, settings, resolution, presentation mode, and relevant background activity unchanged. Note whether any upscaling or frame-generation option is enabled rather than silently combining several changes.

A second run that improves identifies a difference between first and repeated use. It does not identify the cause. Epic documents pipeline-state-object preparation as one possible source of runtime hitches, including work that was not ready when needed. Other explanations remain possible without a trace or more specific evidence. [3]

Do not immediately clear every cache to investigate a first-use pause. Decide which condition you need to preserve before resetting it. Otherwise, you may remove the difference you were trying to understand or repeatedly recreate preparation work.

A useful result: “The pause occurs on the first traversal but not on repeated traversals under these conditions.” That is narrower, and more defensible, than “the GPU is too slow.”

Why low ping does not rule out lag#

Microsoft's ping command sends ICMP Echo requests and reports replies and round-trip timing. That is a defined communication test. It is not a measurement of everything between pressing a control and seeing the resulting game state. A timeout means that the expected reply did not arrive within the configured interval; it does not explain why. [2]

There is a documented historical example of the distinction. In May 2022, Riot Games reported movement-buffer delays in VALORANT that its Network RTT graph did not show, and described changes to recovery and diagnostics. This is evidence of a past implementation problem, not a claim that today's installation has that bug. [4]

For your investigation, prefer the application's own documented diagnostics when they describe the relevant activity. Record which graph or number you used. “Ping” to an unrelated destination and an application's processing-delay graph are not interchangeable tests.

A useful first comparison#

Check whether the specific symptom can also be reproduced in a genuinely local, supported activity. Do not assume that a menu named “practice” or “training” is offline; establish whether the comparison actually removes remote dependencies.

Keep the visual workload comparable where possible. A quiet local scene and a crowded online match differ in more than connectivity. If the comparison changes several things, record that limitation rather than attributing the outcome exclusively to the network.

A problem reproduced without a remote dependency demonstrates that the dependency is not necessary for that reproduction. It does not exclude an additional network problem during another activity.

A useful result: “The local scene still pauses, so the pause does not require this online connection.” That redirects the next test without certifying that every other part of the system is healthy.

Why a connection can deteriorate during an upload#

A connection can carry substantial traffic while smaller interactive exchanges wait. The IETF's active queue-management recommendations explain how persistent queues create delay and why queue occupancy should be managed rather than evaluated only through transfer rate. That mechanism supports testing performance under competing traffic; it does not establish that a particular household router is responsible. [5]

A useful first comparison#

Choose a destination you are authorized to test, preferably one relevant to the problem or a provider's documented diagnostic endpoint. Record the destination, protocol, device, connection method, and test duration. Compare an otherwise quiet interval with an interval containing a controlled upload, then repeat the quiet condition.

Keep enough ordered observations to show when the change occurred. Preserve timeouts separately rather than silently discarding them from the average. Treat the difference as evidence about this test and path, not as a certified measurement of all application traffic.

Do not run a load experiment while someone else needs the connection for an important call or task. Stop when it disrupts necessary activity. Avoid public endpoints that do not authorize the load being proposed; an ordinary reachability probe is not permission to stress-test a service.

A repeatable deterioration during the upload supports investigating competition or queueing along the tested path. Further isolation is needed before naming a component. A supported wired comparison may help, but it changes the access path and must be recorded as a separate comparison.

A useful result: “This destination's response became slower during the controlled upload and returned toward baseline afterward.” It does not yet justify buying a router or changing providers.

When the screen responds late rather than moving unevenly#

A finished image can still encounter display-side processing. HDMI's Auto Low Latency Mode allows a source to request a lower-latency display mode; some television processing features may be suspended. The feature's existence does not establish one fixed improvement across every television or configuration. [6]

For a supported mode comparison, use the same local action, input device, scene, resolution, and refresh setting. Change only the documented display mode where practical. Check that the mode actually activated, and record any accompanying changes you could not hold constant.

A subjective improvement is a useful observation, but label it as such. Without an instrument measuring the full physical path, do not assign a precise millisecond improvement. Also note visible trade-offs that matter to you; a different picture is part of the outcome, not something to conceal.

Old advice needs its original conditions#

A setting's name can survive after its implementation changes. Microsoft's DXGI flip-model documentation describes efficient windowed presentation paths, including Independent Flip. This is why “exclusive fullscreen is always faster” is not an adequate universal rule. Check the application and presentation path rather than copying advice solely because it uses the same menu label. [8]

A useful result: “The supported low-latency TV mode improves this local response, with these image changes.” That supports a display-side intervention without pretending it repaired remote game-state corrections.

When the whole device seems slow#

First separate one slow activity from a broad pattern. Does opening one application differ from switching among several? Does the behavior change after sustained use? Does an already available local task behave differently from retrieving remote content? These comparisons help define the question before an intervention.

Microsoft's performance guidance includes supported checks of resource use, available storage, applications, and startup activity. Treat such observations as leads rather than proof that one high percentage explains every delay. [9]

On an iPhone or iPad, Apple's guidance distinguishes network conditions, storage, power, temperature, and other causes. It also cautions that unnecessary force-closing can make reopening slower because data must reload. A routine that repeatedly discards state is not automatically a performance improvement. [10]

Use the guidance for the actual device and software release. This general article does not replace model-specific recovery instructions. Preserve important data before destructive operations; do not use factory reset, mass registry changes, or disabling safeguards as an unexplained first experiment.

Audio needs a separate timing question#

For sound, distinguish a late response to a live action from interrupted playback or poor lip synchronization. Android's audio documentation separates input, output, round-trip, and warmup latency and describes device and software variation. A single number without its path is insufficient. [11]

A proposed wired-versus-wireless comparison should preserve the same task. Comparing live microphone monitoring on one setup with prerecorded video on another does not isolate wireless delay. A video player that delays the picture to match sound can improve alignment without making either stream more current; that is an illustrative distinction, not a test of your headphones.

Record which activity is affected. “Late sound when I play a note” is a different investigation from “the dialogue does not match the lips.”

Keep a result you can use again#

Before the test, decide what would count as a useful improvement: fewer repeated pauses in this scene, a more immediate local response, or a call that remains usable during an ordinary concurrent task. Do not change the success criterion after seeing the result.

Change one meaningful variable at a time where practical. Repeat the original condition when safe. If the workload, operating state, or software changed too, record the comparison as limited. A single before-and-after pair may be suggestive without establishing a durable cause.

Use this compact record; leave unknown fields unknown:

Symptom and exact reproduction:
Device and relevant software versions:
Workload, connection, display and power conditions:
What the measurement starts and ends with:
Instrument or observation method, including limitations:
Baseline observations and duration:
One change tested:
Repeated observations after the change:
Return-to-baseline comparison, if safe:
Outcome: improved / unchanged / worse / inconclusive
Trade-off or cost:
What remains unexplained:
Next comparison, support report, or reason to stop:

An unchanged outcome weakens an explanation only when the intervention and test could have exposed the expected effect. An inconclusive outcome is not permission to relabel the change a success. It tells you what remains unmeasured.

When asking for help, send the symptom, reproduction, environment, and result—not just a list of attempted fixes. Review recordings and logs before sharing them, and remove account identifiers, unrelated personal information, and credentials. A support report can be a useful outcome even when the relevant repair lies outside your control.

The endpoint is not a perfect score or a claim of zero lag. It is a satisfactory activity supported by an explanation you can test. For the historical context behind these distinctions, see The History of Device Lag.

Sources and scope#

The sources below were checked on 11 September 2026. This is a diagnostic synthesis, not a report of tests conducted on the reader's equipment. Historical accounts are labelled; maintained documentation is not treated as universally applicable instructions. The procedures and result template are this guide's recommendations. Chapter links in this handoff target the accompanying Markdown; the publisher must map them to the actual live history URL.

[1] NVIDIA. “Introducing NVIDIA Reflex: Optimize and Measure Latency in Competitive Games.” 1 September 2020. Technical definitions of local/system and network latency; vendor results are configuration-specific.
https://www.nvidia.com/en-us/geforce/news/reflex-low-latency-platform/

[2] Microsoft Learn. “ping.” Documentation updated 1 November 2024. ICMP request/reply scope and timeout behavior.
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping

[3] Epic Games. “PSO Precaching.” Maintained Unreal Engine documentation. Pipeline preparation and runtime hitches; not a universal diagnosis of stutter.
https://dev.epicgames.com/documentation/en-us/unreal-engine/pso-precaching-for-unreal-engine

[4] Riot Games, VALORANT Gameplay Technology team. “VALORANT Gameplay Consistency Update 2.” 24 May 2022. Developer account of movement buffering and Patch 4.10 changes; not evidence of a current bug.
https://playvalorant.com/en-us/news/game-updates/valorant-gameplay-consistency-update-2/

[5] IETF / RFC Editor. “RFC 7567: IETF Recommendations Regarding Active Queue Management.” July 2015. Persistent queueing and network behavior.
https://www.rfc-editor.org/rfc/rfc7567

[6] HDMI Licensing Administrator. “Auto Low Latency Mode (ALLM).” Maintained feature explanation. Source signalling and the display-processing trade-off.
https://www.hdmi.org/spec21sub/autolowlatencymode

[7] Android Developers. “Slow rendering.” Maintained documentation. Frame deadlines and supported investigation methods; framework-specific limitations apply.
https://developer.android.com/topic/performance/vitals/render

[8] Microsoft Learn. “For best performance, use DXGI flip model.” Documentation updated 6 January 2021. Windowed presentation and implementation-dependent latency.
https://learn.microsoft.com/en-us/windows/win32/direct3ddxgi/for-best-performance--use-dxgi-flip-model

[9] Microsoft Support. “Tips to improve PC performance in Windows.” Maintained support page; choose the instructions for the supported version.
https://support.microsoft.com/en-us/windows/experience/performance-optimization/tips-to-improve-pc-performance-in-windows

[10] Apple Support. “If your iPhone or iPad is running slow.” Maintained support page; includes cautions concerning force-closing apps.
https://support.apple.com/en-us/102598

[11] Android Developers. “Audio latency.” Maintained documentation. Distinct audio paths and device/build variation.
https://developer.android.com/ndk/guides/audio/audio-latency