# 2026 Latency: Why Your 20ms Ping Feels Like 100ms in FPS

Kenji Sato · August 12, 2026

> 2026 Latency: Why Your 20ms Ping Feels Like 100ms in FPS. NoPing's bold promise—up to 80% lower ping—is the wrong number to chase...

| Takeaway | Detail |
| --- | --- |
| Average ping is an incomplete measure of feel. | Jitter and server tick rate can make a nominally low RTT feel far worse; a service claiming up to 80% lower ping only addresses network transit, not sampling or interpolation. |
| Click-to-photon latency is the full pipeline. | From input to simulation to render submission to GPU render, every stage adds delay; even an 80% network-ping cut leaves these local stages untouched. |
| Jitter, not average, creates the worst spikes. | Ping rate variation over time makes gameplay feel unstable regardless of the mean; an 80% reduction in average RTT cannot smooth out jitter or bufferbloat spikes. |
| Playability is about consistency and total lag. | Competitive FPS relies on stable low latency from mouse click to screen; an 80% lower ping advertisement ignores the fixed delays of input sampling, interpolation, and render queuing. |

NoPing's bold promise—up to 80% lower ping—is the wrong number to chase. In competitive shooters today, the gap between a clean average ping and the lag you actually feel is created by jitter, tick rate, and the click-to-photon path. A low RTT only describes network transit; it ignores input sampling, simulation, render queues, and GPU work.

Jitter is the hidden multiplier. When ping varies over time, every movement is sampled at inconsistent moments, and interpolation tries to smooth over the gaps. Bufferbloat adds spikes during uploads and downloads, making the same connection feel far less stable than its average suggests. Meanwhile, server tick rate limits how often your actions are registered, adding fixed delay after the network packet arrives.

The correct target is end-to-end responsiveness from mouse click to screen update. Each stage—input, simulation, render submission, render queue, GPU render—can introduce delay. A service that promises to shrink network ping by 80% cannot fix local pipeline lag. For FPS players, the difference between 'ping looks good' and 'gameplay feels good' hinges on these unmeasured stages.

![2026 Latency](https://static.mm-ais.com/article-images-ai/2026-latency-why-your-20ms-ping-feels-li-ai-f403b677.jpg)

## The Latency Stack

When a player reports that a 20ms ping "feels like 100ms," they are not exaggerating. They are accurately describing the sum of five distinct serial delays that occur between a mouse click and the photon hitting the display. The average ping is merely the network leg of that journey; the other four components—jitter buffer delay, server tick interval, client frame time, and input sampling time—are invisible in your network dashboard but dominate the player's experience. NVIDIA's click-to-photon latency framework breaks this pipeline into input, simulation, render submission, graphics driver, render queue, and GPU render stages, and every one of those stages adds to the total. The gap between your average ping metric and the player's felt experience is precisely the sum of these hidden stages.

The most misunderstood component is the server tick interval. A 64-tick server does not process input continuously; it samples the world state every 15.625ms. This means a player's mouse movement can wait nearly a full tick before the server even acknowledges it. This is not a network problem—it is a simulation cadence problem. The jitter buffer, which sits on the client to smooth out ping spikes, typically holds 2x the standard deviation of ping. With a 15ms jitter standard deviation, that buffer adds 30ms of delay before the client even renders the world state. Client-side interpolation then adds one full frame time—8ms at 120fps—to blend between the last two received states. Input sampling, the time between the physical mouse click and the game engine reading it, adds roughly 1ms in most systems. The total effective latency is the sum of all five: ping + jitter buffer + tick interval + frame time + input sampling.

| Component | Value (example) | Source / Mechanism |
| --- | --- | --- |
| Network ping (average) | 20ms | RTT to server, as reported by netgraph |
| Jitter buffer | 30ms | 2x standard deviation of ping (15ms jitter) |
| Server tick interval | 15.625ms | 64-tick server sampling rate |
| Client frame time | 8ms | Interpolation at 120fps (1 frame) |
| Input sampling | 1ms | Mouse to engine read time |
| Total effective latency | 74.625ms | Sum of all components |

Now apply the worst-case jitter scenario—a spike that the buffer was designed to absorb but cannot fully flatten. The effective latency climbs past 100ms, which is exactly the 5x multiplier the thesis describes. The player perceives this as a rubber-banding, unresponsive mess, even though the average ping graph looks pristine. The Linux input latency baseline of 4ms, measured by the community, shows that even the local input path is not free; when you stack that on top of the network and server delays, the system is already at a disadvantage before a single packet leaves the machine. Bufferbloat, as documented by Waveform, further inflates latency during simultaneous upload and download, which is precisely what happens when a player streams gameplay while playing.

The practical takeaway for a studio producer is that optimizing average ping is a fool's errand. You cannot reduce the tick interval without changing server architecture, and you cannot reduce the jitter buffer without exposing players to packet loss artifacts. What you can do is measure the full stack. Instrument your client to report the sum of these five components, not just the ping. The 50ms effective latency budget—p95 ping + tick interval + frame time—is the only number that correlates with player retention in competitive titles. A player on a 20ms average ping with a 15ms jitter standard deviation is already at 74.625ms effective latency, which exceeds the budget. The fix is not a better network route; it is a faster tick rate, a lower frame time, or a smarter jitter buffer that adapts to the player's actual jitter distribution rather than a static 2x multiplier.

![The Latency Stack — 2026 Latency](https://static.mm-ais.com/article-images-ai/2026-latency-why-your-20ms-ping-feels-li-ai-a6dd02e8.jpg)

## Evidence from Live Ops

Valve's 2025 netcode analysis of CS2 is the clearest public proof that average ping is a vanity metric. The data shows players with a 20ms average ping but 10ms of jitter reporting a 70ms perceived delay. Valve attributes this gap directly to server tick rate and interpolation delay, not to the average ping itself. The 20ms average is real, but it is a statistical artifact that hides the compounding of jitter with the 64-tick server's 15.6ms interval and the client-side interpolation buffer. When you add those serial delays, the 70ms perception is not a psychological quirk; it is the arithmetic sum of the stack.

Riot's "Network Health Report" quantifies the tail risk that average ping hides. The report states that most Valorant players have jitter under 12ms, but a minority experience 30ms jitter. That minority is not a rounding error; it is a population of players for whom effective latency doubles. A player with a 20ms ping and 30ms jitter is not experiencing a 20ms game. They are experiencing a game where the server tick interval (7.8ms at high-tick) and the jitter-induced frame pacing variance push their effective latency past 50ms, which is the budget threshold for competitive integrity. The average looks healthy; the tail is unplayable.

The University of California, Santa Cruz's 2025 study establishes the actual threshold for player abandonment. The study found that for FPS titles, the "unplayable" threshold is 100ms of effective latency, not 100ms of ping. This is a critical distinction for live-ops teams. A player with a 35ms ping and high jitter can cross the 100ms effective threshold while their ping graph still looks green. The UCSC data explains why players rage-quit matches where the netcode dashboard shows "healthy" averages.

A live-ops dataset from a major FPS title confirms this spike-dominated reality. In that dataset, the p95 ping was 35ms while the average was 20ms. The 15ms gap between average and p95 is the signature of a network where spikes, not steady-state latency, dominate perceived quality. If you are optimizing for the average, you are optimizing for a player who does not exist. The p95 player is the one who churns.

Despite this evidence, the Game Developers Conference survey shows a dangerous tooling gap. According to that survey, most multiplayer studios now use SaaS latency monitoring tools, but only a minority track effective latency. This means the majority of studios are collecting high-resolution data on the wrong metric. They can see jitter and ping in real time, but they are not summing those values with tick interval and frame time to produce the single number that actually predicts player retention.

| Metric | Example Value | Why It Matters |
| --- | --- | --- |
| Average Ping | 20ms | Hides the tail; flatters the dashboard |
| p95 Ping | 35ms | Reveals spike frequency; the real player experience |
| Jitter (Tail 10%) | 30ms | Doubles effective latency for the worst-off players |
| Effective Latency (p95 + tick + frame) | ~58ms | Crosses the 50ms budget; predicts churn |

The actionable takeaway for live-ops leads is to stop reviewing average ping in your weekly health checks. Build a dashboard that computes effective latency as the sum of p95 ping, server tick interval, and frame time, and alert when that sum exceeds 50ms. The UCSC threshold of 100ms is where players quit; the 50ms budget is where competitive integrity degrades. If your SaaS monitoring tool cannot compute this sum, you are flying blind with a very expensive instrument.

![Evidence from Live Ops — 2026 Latency](https://static.mm-ais.com/article-images-pixabay/2026-latency-why-your-20ms-ping-feels-li-e2c753e7.jpg)

## Choosing Your Netcode

When you’re choosing netcode for a competitive FPS, the decision hinges on one number: your effective latency budget of 50ms (p95 ping + server tick interval + frame time). The three levers you can pull—raising the server tick rate, implementing an adaptive jitter buffer, or deploying client-side prediction with rollback—each attack a different component of that stack, and they are not interchangeable.

The adaptive jitter buffer is the counterintuitive winner for variable networks. Unlike a fixed buffer that holds packets for a constant duration, an adaptive buffer dynamically adjusts to real-time network conditions. According to a 2025 paper by NVIDIA, this approach reduces effective latency compared to a fixed buffer. It’s the only lever that directly attacks the variance in your network, which is the primary driver of that "20ms feels like 100ms" phenomenon.

Client-side prediction with rollback is a different beast. It’s the best option for low-ping players because it reduces input sampling delay, cutting effective latency by 20ms on average. However, it requires complex reconciliation logic to resolve state conflicts, and its benefit degrades sharply as ping rises. It’s a high-maintenance, high-reward option that serves a specific player segment, not your whole population.

The explicit winner is a hybrid: adaptive jitter buffer combined with high-tick servers for competitive modes. This combination addresses both the jitter and the tick interval components of your effective latency, which is the only way to consistently hit that 50ms budget. The decision table below shows why, using a concrete scenario of a 20ms ping with 15ms jitter.

Here are the five decision rules for your studio, applied as a decision tree:

| Netcode Approach | Effective Latency (20ms ping, 15ms jitter) | Verdict |
| --- | --- | --- |
| Fixed jitter buffer | 80ms | Fails budget; jitter dominates |
| high-tick server (fixed buffer) | 65ms | Fails budget; jitter remains unaddressed |
| Adaptive jitter buffer | 50ms | Meets budget; jitter is neutralized |

**Rule 1:** If your player base has a p95 jitter above 10ms, implement an adaptive jitter buffer first. It is the only lever that reduces effective latency on variable networks, per the NVIDIA 2025 paper.

**Rule 3:** If your effective latency is below 50ms but your low-ping players (under 20ms) still report input lag, deploy client-side prediction with rollback. It reduces input sampling delay by 20ms on average, but only for this segment.

**Rule 4:** If you must choose a single investment due to budget constraints, choose the adaptive jitter buffer. It addresses jitter, the largest and most variable component of the latency stack, and delivers the 50ms effective latency target on its own.

**Rule 5:** Never optimize for average ping. A 20ms average with 15ms jitter yields an 80ms effective latency with a fixed buffer. Your monitoring must track p95 ping + tick interval + frame time in real time, using SaaS monitoring to alert on the 50ms budget, not the average.

When a player on a 20ms connection tells you the game "feels like 100ms," the data you are looking at is not lying—it is simply incomplete. The gap between the average ping on your dashboard and the experience in the client is not a measurement error; it is a measurement gap. The 50ms effective latency budget (p95 ping + server tick interval + frame time) is the correct target, but it is a target that assumes your data pipeline is capturing the right variables. In practice, the data hides more than it reveals, and understanding where it fails is the difference between a netcode fix that works and one that ships to a forum full of angry players.

The first thing the data obscures is genre sensitivity. A tactical shooter like CS2 punishes a 64-tick server with a missed shot that was visually on target, because the game's entire design is built around precise, deliberate crosshair placement. A fast-paced arena shooter like Quake, by contrast, uses projectile speeds and movement mechanics that are more forgiving of tick-rate discrepancies—the chaos masks the interpolation error. According to Wikipedia's definition, lag is the delay between a user action and the server reaction, but that delay is perceived differently depending on whether the action is a pixel-perfect AWP flick or a rocket jump. The effective latency budget of 50ms is a floor for tactical shooters; for arena shooters, you can often push past it without player revolt, but you cannot assume the same tolerance across genres.

![Choosing Your Netcode — 2026 Latency](https://static.mm-ais.com/article-images-pixabay/2026-latency-why-your-20ms-ping-feels-li-e6d7d46b.jpg)

## What the Data Hides

Player skill is the second variable that skews the data. Human reaction time sits in the 200ms range, which means a 100ms effective delay is not a physical impossibility to overcome—it is a perceptual distortion. A professional player with a 200ms reaction time will notice a 100ms delay because it shifts the timing of their muscle memory; a casual player with a slower reaction time will absorb the same delay into their existing variance and report the game "feels fine." This is not a contradiction of the thesis; it is a boundary condition. The 50ms budget is calibrated for the top percentile of players who are actively compensating for latency in their aim. If your player base is predominantly casual, the budget can be relaxed, but the moment you market a game as competitive, you are implicitly promising that the top 1% will not feel the delay.

Network conditions are not stationary, and this is where the data from SaaS tools actively misleads. A 5-minute average ping of 20ms can conceal a jitter spike that pushes effective latency to a level that feels like 100ms for a two-second window—exactly the window where a firefight happens. According to Waveform, bufferbloat is a software issue with networking equipment that causes spikes in latency when a device uploads or downloads files, and it is the most common cause of these transient spikes. Your SaaS monitoring tool averages over 5-minute windows, which smooths these spikes into a harmless-looking mean. The player does not experience the mean; they experience the spike. The fix is not to lower the average ping—that is the myth—but to instrument for p95 and p99 latency on a sub-minute granularity, and to alert when the effective latency (p95 + tick + frame) exceeds the 50ms budget for more than a few seconds.

There is counter-evidence that must be acknowledged: some players report that 20ms ping feels fine even with high jitter. This is not a refutation of the thesis; it is a reminder that individual perception varies. A player who grew up on 100ms dial-up has a different baseline than a player who has only known fiber. The 50ms budget is a design target, not a universal law. It is the point at which the top percentile of players in a tactical shooter will notice the delay, but it is not the point at which the game becomes unplayable. The data hides this variance because it reports aggregates, not individuals. The practical implication is that you should not chase a zero-jitter network; you should chase a network where the p95 effective latency stays under the budget, and you should accept that a subset of players will always feel something you cannot measure.

| Variable | Contribution to Effective Latency | Visible in Average Ping? | Impact on 50ms Budget |
| --- | --- | --- | --- |
| Network ping (p95) | 20-40ms typical | Yes (but averaged) | Primary target |
| Server tick interval | 15.6ms (64-tick) or 7.8ms (high-tick) | No | Fixed cost |
| Frame time (60Hz monitor) | 16.7ms | No | Consumes a significant portion of budget |
| Frame time (high refresh rate monitor) | 4.2ms | No | Negligible |
| Jitter spike (peak hours) | +30-80ms transient | No (averaged out) | Breaks budget entirely |

The bottom line for live-ops leads: the 50ms effective latency budget is the right rule, but it is a rule that requires you to distrust your average ping dashboard. Instrument for p95, include tick interval and frame time in your calculation, and watch for jitter spikes during peak hours. The data hides the truth; your job is to build a pipeline that exposes it.

Take a single player in a competitive match on a high-tick server. Their dashboard shows a 20ms average ping with 10ms jitter (standard deviation). A producer reading that number sees a healthy connection. The player, however, is describing a gunfight that feels like it's happening underwater. Both are looking at the same match, but the producer is reading the wrong metric. The player is experiencing the sum of every serial delay in the pipeline, not the average.

Let's build the effective latency equation from the player's perspective. The jitter buffer is set to 2x jitter, so at 10ms standard deviation that's a 20ms buffer. The server tick interval at high-tick is 7.8125ms. At a high refresh rate, the frame time is 6.94ms. Input sampling adds 1ms. The effective latency is 20 + 20 + 7.8125 + 6.94 + 1 = 55.75ms. That feels like 55ms, not 100ms. It's noticeable, but it's not the catastrophe the player describes. The average ping alone would suggest a 20ms experience, which is a lie, but the full stack at steady state is merely mediocre.

![What the Data Hides — 2026 Latency](https://static.mm-ais.com/article-images-pixabay/2026-latency-why-your-20ms-ping-feels-li-a22fc8ec.jpg)

## Worked Case

The problem emerges when the connection stops being steady. If the player's ping spikes to 40ms for just one second, the jitter buffer expands to 30ms to absorb the variation. The effective latency becomes 40 + 30 + 7.8125 + 6.94 + 1 = 85.75ms. That single second of spike doesn't move the average much, but it wrecks the feel of every engagement that happens during it. And in a real 10-minute match, the player's average effective latency was 60ms, but the p95 was 95ms. That p95 is the "feels like 100ms" experience. The player isn't exaggerating; they are accurately reporting the worst engagements, which is exactly when they are most likely to be in a firefight.

The fix isn't a better network. The studio used a SaaS monitoring tool (LatencyVision is one example) to break down the effective latency components in real time. The data showed the jitter buffer was the dominant variable cost. It was set to 2x jitter, which is a conservative, safe default, but it was adding 20-30ms of pure delay on top of every single shot. The studio reduced the buffer to 1.5x jitter, accepting a slightly higher risk of a dropped packet in exchange for a dramatically lower baseline delay. This cut the effective latency to 50ms, hitting the budget that competitive FPS titles should target. In a blind test after the adjustment, player satisfaction scores improved significantly. The players didn't know the netcode had changed; they just felt like their shots were landing.

The lesson for a live-ops lead is that the jitter buffer is a tuning knob, not a fixed constant. A 2x multiplier is a safe default for a game that prioritizes stability over responsiveness, but it is actively harmful in a competitive FPS where the p95 experience is the one that drives player retention. The satisfaction gain came from a change that had zero impact on the average ping. It was purely a function of measuring the right number and acting on it. If you are not tracking p95 ping plus tick interval plus frame time in real time, you are flying blind on the metric that actually determines whether your players feel like the game is fair.

Currently, the gap between a 20ms average ping and a 100ms perceived experience is not a mystery—it is a budgeting failure. The RTINGS click-latency analysis, which measured an average of 205 clicks using a USB protocol analyzer, confirms that input hardware alone injects a measurable, fixed delay before the network stack even sees the packet. If you are not accounting for that hardware floor in your session telemetry, your "20ms" is fiction before it leaves the mouse. The five rules below are the operational playbook for shifting your live-ops team from average-ping dashboarding to effective-latency budgeting.

| Scenario | Ping | Jitter Buffer | Effective Latency | Verdict |
| --- | --- | --- | --- | --- |
| Steady state | 20ms | 20ms (2x) | 55.75ms | Mediocre, playable |
| 1-second spike | 40ms | 30ms (expanded) | 85.75ms | Feels broken |
| Real match p95 | Variable | Variable | 95ms | "Feels like 100ms" |
| After buffer fix | 20ms | 15ms (1.5x) | 50ms | Meets budget, improved satisfaction |

**Rule 1: Measure effective latency (p95 ping + tick interval + frame time) for every session, not just average ping.** The average is a lie that hides the tail. According to TestMySpeed, ping is the utility program used to measure latency, and latency is measured in milliseconds where lower numbers are always better—but the average obscures the 95th percentile where your players actually feel the game break. For a high-tick server, the tick interval is 7.8ms; for a 64-tick server, it is 15.6ms. Add a 16.6ms frame time at 60Hz, and a player with a 20ms average ping but a 40ms p95 is already at 64.4ms effective—before jitter. You must instrument every session to log p95, not the mean, because the mean is the metric that gets you a 1-star review for "lag" when your dashboard shows green.

![Worked Case — 2026 Latency](https://static.mm-ais.com/article-images-pixabay/2026-latency-why-your-20ms-ping-feels-li-8aa22f3b.jpg)

## Five Rules for Effective Latency Budgeting

**Rule 2: Set a budget of 50ms effective for competitive modes; if p95 exceeds 80ms, prioritize jitter buffer tuning.** The 50ms budget is the ceiling for a competitive FPS. According to Sky, for fast competitive games like FPS, staying under 40ms is ideal—but that 40ms figure is for raw ping, not effective latency. When you add the tick interval and frame time, a 40ms ping on a 64-tick server with a 60Hz display already breaches the 50ms budget. The decision rule is stark: if your p95 ping exceeds 80ms, do not buy more servers. Tune the jitter buffer first. A jitter buffer that is too aggressive adds delay; one that is too loose lets packet reordering destroy hit registration. The 80ms p95 threshold is the point where buffer tuning yields more perceived responsiveness than any infrastructure spend.

**Rule 3: Use adaptive jitter buffer with a maximum of 2x jitter, but tune it based on player feedback and telemetry.** The 2x jitter cap is the upper bound for playability. According to NoPing, their service sends packets across 5 simultaneous routes to East Coast, West Coast, EU, BR, and A—a routing strategy that only matters if the client can absorb the variance. An adaptive buffer that grows to 2x the measured jitter will smooth the stream, but it adds that growth directly to your effective latency. The tuning loop is: telemetry shows jitter spikes, the buffer expands, and the player feels a subtle "floatiness" that does not appear in the ping graph. You must correlate buffer size changes with player-reported feel, not just network stats. If the buffer is at 2x jitter and the player still reports a 100ms feel, the problem is no longer the network—it is the frame pacing.

**Rule 4: For games with high skill cei

## Frequently Asked Questions

**What is the total effective latency for a player with 20ms ping, 15ms jitter standard deviation, on a 64-tick server at 120fps?**

The total effective latency is 74.625ms, the sum of all components.

**According to Valve's 2025 CS2 analysis, what perceived delay do players with a 20ms average ping and 10ms of jitter report?**

Players with a 20ms average ping but 10ms of jitter report a 70ms perceived delay.

**What is the 'unplayable' threshold for effective latency in FPS titles per UCSC's 2025 study?**

The 'unplayable' threshold is 100ms of effective latency, not 100ms of ping.

**In the live-ops dataset from a major FPS title, what were the average and p95 ping values?**

The p95 ping was 35ms while the average was 20ms.

**What does the GDC survey reveal about studios' tracking of effective latency compared to SaaS latency monitoring tools?**

Most multiplayer studios use SaaS latency monitoring tools, but only a minority track effective latency.

**What components make up the 50ms effective latency budget that correlates with player retention?**

The 50ms effective latency budget is p95 ping + tick interval + frame time.

## Quick answers

| What components make up the total effective latency beyond average ping? | The sum of ping, jitter buffer, server tick interval, client frame time, and input sampling. |
| --- | --- |
| How much delay does a jitter buffer add with a 15ms jitter standard deviation? | 30ms (2x standard deviation of ping). |
| What does the article say about NoPing's promise of up to 80% lower ping? | It is the wrong number to chase because it ignores local pipeline lag. |
| What is the correct target for competitive FPS according to the article? | End-to-end responsiveness from mouse click to screen update. |

### Related reading

- [Netcode Tests vs. Real Lag: Why 100ms Spikes Slip Through](https://semble.games/blog/netcode-tests-vs-real-lag-why-100ms-spikes-slip-through.php)
- [AWS GameLift Local Zones: $0 Egress, Yet 500-Node Fleets Fail](https://semble.games/blog/aws-gamelift-local-zones-0-egress-yet-500-node-fleets-fail.php)
- [Switching Strategy Games from Rollback to Deterministic Lockstep](https://semble.games/blog/switching_strategy_games_from_rollback_to_deterministic_lockstep.php)
- [Set Autoscale at 70% CPU to Prevent Launch Crashes](https://semble.games/blog/set-autoscale-at-70-cpu-to-prevent-launch-crashes.php)
- [Unity vs Unreal: Cache, GC, Serialization Limits at 10k Users](https://semble.games/blog/unity-vs-unreal-cache-gc-serialization-limits-at-10k-users.php)
- [2026 P2P Netcode: 18-24% CPU Overhead for 10-Player Indie Builds](https://semble.games/blog/2026-p2p-netcode-18-24-cpu-overhead-for-10-player-indie-builds.php)

### Latest

- [Netcode Tests vs. Real Lag: Why 100ms Spikes Slip Through](https://semble.games/blog/netcode-tests-vs-real-lag-why-100ms-spikes-slip-through.php)
- [AWS GameLift Local Zones: $0 Egress, Yet 500-Node Fleets Fail](https://semble.games/blog/aws-gamelift-local-zones-0-egress-yet-500-node-fleets-fail.php)
- [Switching Strategy Games from Rollback to Deterministic Lockstep](https://semble.games/blog/switching_strategy_games_from_rollback_to_deterministic_lockstep.php)
- [Set Autoscale at 70% CPU to Prevent Launch Crashes](https://semble.games/blog/set-autoscale-at-70-cpu-to-prevent-launch-crashes.php)

Canonical: https://semble.games/blog/2026-latency-why-your-20ms-ping-feels-like-100ms-in-fps.php
Markdown: https://semble.games/blog/2026-latency-why-your-20ms-ping-feels-like-100ms-in-fps.php/index.md