Back to Blog

Measurement

How FPS Is Measured | Frame Time Explained

Understand frame rendering, frame timing, refresh synchronization, and the metrics behind accurate FPS measurement in games and browser tests.

By FPS Test 17 min read
  • frame timing
  • frame rendering
  • metrics
How FPS Is Measured | Frame Time Explained

Quick Answer

FPS is measured by counting frames presented within a time window, derived from frame rendering completion timestamps and display submission events.

Formula

Instant FPS ≈ 1000 ÷ Frame Time (ms)

Introduction

This guide is part of the FPS Test knowledge base. Use the FPS test tool on the run page for live browser measurement, then work through the sections below to interpret frame delivery quality beyond a single average number.

Measurement method changes the number you see. Overlays, benchmark APIs, and browser requestAnimationFrame loops sample different points in the pipeline. This article maps those stages so you interpret FPS counters correctly.

Frame Rendering and Delivery

Frame rendering is the GPU (and CPU) work to produce one image: simulation, culling, draw calls, pixel shading, and post-processing. Frame delivery is when that image reaches the display buffer visible to you.

Frame timing records how long each stage takes. Spikes in simulation or shader compilation appear as sudden frame time jumps even when average FPS looks stable.

Refresh synchronization (V-Sync, G-Sync, FreeSync) caps or aligns FPS to display refresh, changing measured FPS without changing raw GPU speed.

The browser FPS test tool samples via requestAnimationFrame, which measures one point in the pipeline. In-game overlays may sample present queues or GPU busy time instead, so numbers diverge even on the same hardware.

Documenting where each tool measures is as important as the number itself. Without that context, comparing a menu FPS readout to a benchmark log is comparing different phenomena.

  • Frame rendering: CPU + GPU work per image
  • Frame timing: milliseconds per completed frame
  • Frame delivery: scan-out and buffer presentation
  • Refresh synchronization with display Hz
  • Performance metrics: avg, min, 1% low, frame time

From Frame Time to FPS

Tools sample frame time each cycle, then derive FPS as the reciprocal. A 16.7 ms frame equals roughly 60 FPS; 6.9 ms equals roughly 144 FPS.

Aggregates matter: mean FPS hides stutter; percentile lows expose worst frames players feel.

When averages look healthy but motion still feels wrong, switch focus from throughput to variance. A dedicated FPS stability test surfaces uneven pacing that mean FPS mathematically washes away.

Instant FPS (1000 ÷ last frame time) reacts immediately to spikes; rolling averages lag behind. Both are valid; know which your overlay shows before tuning settings.

FPS = 1000 ÷ Frame Time (ms)

  • Sample per-frame duration, not only end-of-second averages
  • Report 1% and 0.1% low frame times for stutter analysis
  • Note V-Sync on/off state in every log
  • Align test duration with thermal steady state

Measurement Checklist

Consistent methodology beats raw hardware. Two rigs compared with different measurement points or sync settings produce misleading conclusions.

  1. Define the pipeline point

    Know whether your counter measures GPU busy, present, or display time. Vendor overlays and engine stats often disagree for this reason alone.

  2. Fix display mode

    Record refresh rate, resolution, and adaptive sync settings. Changing sync mid-test invalidates before-and-after comparisons.

  3. Capture frame time

    Prefer frame time graphs over FPS-only averages. Graphs reveal periodic spikes tied to background tasks or shader compiles.

  4. Log percentiles

    Export 1% low and 0.1% low when available. Percentiles correlate with felt stutter better than absolute minimum FPS.

  5. Validate with second tool

    Cross-check browser and in-game counters occasionally. Agreement builds confidence; disagreement flags a methodology issue, not necessarily bad hardware.

  6. Note environmental factors

    Ambient temperature, power plan, and background apps belong in every log. They explain sessions that look like hardware failure but are environmental.

Measurement Examples

Cap at 60 FPS with V-Sync on: average stays 60 while frame time variance still reveals micro-stutter. The cap hides throughput problems but not pacing problems.

Uncapped 144 Hz monitor: FPS may exceed 144 but visible benefit stops at refresh unless latency tools are used. Extra frames can still reduce input lag depending on sync mode.

Borderless vs exclusive fullscreen: compositor overhead adds 1 to 3 ms on some systems. Measure both if you play competitive titles where latency matters.

Browser rAF loop vs native benchmark: browser validates WebGL health; native benchmark adds engine simulation load. Use both, but never expect identical FPS values.

  • PresentMon-style present latency vs FPS overlay
  • Browser rAF loop vs native game benchmark
  • Fullscreen exclusive vs borderless compositor overhead

FAQ

Why do two FPS counters disagree?
They sample different pipeline stages or averaging windows. Align tools and logging duration before comparing.
What is frame pacing?
Even spacing between frame deliveries. Uneven pacing feels worse than a slightly lower but steady FPS.
Does V-Sync affect measured FPS?
Yes. It limits FPS to refresh multiples and can add latency while smoothing tearing.
Should I trust instant FPS or average FPS?
Use instant FPS to spot immediate hitches and averages for session summaries. Serious tuning uses both plus percentile lows from frame time logs.

Conclusion

Measure frame time and percentiles, not averages alone. Document sync settings and pipeline stage for every session.

Run FPS Test