DeviceBenchFree online fps test
FPS test with the 1% lows beside the average
Choose how many objects the canvas has to push around — none, 200, 800, 2,000 or 4,000 — and the page times every frame your browser delivers while it draws them. The headline comes from the median interval and the figure next to it is the 1% low, meaning the slowest frame in a hundred: an average of 144 sitting beside a 1% low of 41 describes a session that visibly hitches, and the average on its own cannot tell you that. What is being measured is one canvas in one browser tab sharing a thread with the rest of the page, so the result is worth comparing against itself and not against a game.
- 100% free
- No signup
- 300-frame window
- 1% low
- Up to 4,000 objects
How long each of the last 0 frames took
top of the box = — · dashed line = the median frameCollecting frames. The graph fills in from the left.
A flat line is a machine keeping pace with the display. Every spike is a frame that took longer than its neighbors, and a spike you can feel is the reason the 1% low sits where it does — one hitch in three hundred frames moves that figure and leaves the headline alone.
0 frames drawn since the last restart, at 200 moving objects. This is the rate of a 2D canvas inside a browser tab, sharing one thread with the rest of the page: it is a useful comparison against itself — same load, different browser, different machine — and it is not what a game engine talking to your GPU directly will produce.
How to run the frame rate test
Three readings, because a single number with nothing beside it says almost nothing.
Take a baseline with no objects at all
Leave the load on none for the first ten seconds and let the graph fill. With a single sweeping bar to draw, almost any machine will pin itself to the display's own schedule, and the flat line you get is the shape everything else is compared against. If even this reading wanders, the problem is something else on the machine competing for the thread rather than the work you are about to add.
Add objects one step at a time
Each step multiplies the drawing work: 200 circles is trivial, 4,000 is enough to bury a laptop integrated GPU. The step at which the headline first drops below its baseline is the useful result, because it says where this machine runs out of drawing headroom rather than giving you a score with nothing to compare it to.
Read the 1% low and the spikes, then decide
A headline that holds while the 1% low collapses means the frames are arriving unevenly, which is felt as stutter even when the average looks healthy. Spikes in the graph line up with whatever else the machine was doing — a background sync, a tab waking up, a thermal step down — so run it twice before concluding anything about the hardware.
Technical specifications
| What is timed | The gap between consecutive frames the browser delivers to this tab, in milliseconds — a ceiling, since requestAnimationFrame can never run more often than the compositor schedules it |
|---|---|
| Load steps | 0, 200, 800, 2,000 and 4,000 circles, each drawn as its own filled path every frame, plus one sweeping bar at 620 px/s |
| Rolling window | 300 frames — 5 seconds at 60 Hz, 2.5 seconds at 120 Hz |
| Headline figure | 1,000 ÷ the median interval of the window, not the mean |
| 1% low | 1,000 ÷ the 99th-percentile interval, updated on the same window |
| Long-frame threshold | 1.5 × the median interval, counted and shown as a fraction of the window |
| Readout rate | 8 updates per second; the samples behind it are collected on every frame |
| Data kept | 300 interval values in memory, overwritten as the window rolls and gone on reload — no scene, pointer position or device identifier is recorded |
Frequently asked questions
Is this the frame rate my games will run at?
No, and nothing measured in a browser can be. A game hands work to your GPU through Direct3D, Vulkan or Metal and owns the whole machine while it does it; this page draws circles into a 2D canvas that shares one thread with the page's layout, its JavaScript and every other tab your browser has not put to sleep. The two numbers move in the same direction on the same hardware, which makes this a fair comparison of two browsers, two machines or the same machine before and after a driver update — and a poor predictor of anything with a title screen.
Why is the 1% low so much lower than the headline?
Because they answer different questions: the headline is the typical frame and the 1% low is the worst one in a hundred. The headline comes from the median of the last 300 intervals, so a single 90 ms hitch moves it by almost nothing; the 1% low is 1,000 divided by the 99th-percentile interval, so that same hitch lands on it directly. Human beings notice the hitch and not the median, which is why every benchmark that used to publish an average alone now publishes both.
The rate dropped while I was scrolling the page. Is that a fault?
That is the measurement working correctly. Scrolling makes the browser recalculate layout and repaint areas of the page, and that work happens on the same thread the canvas is drawn on, so the frames genuinely did take longer. Leave the pointer still while you read a number you intend to write down, and treat any reading taken while you were interacting with the page as a demonstration rather than a result.
What counts as a long frame here?
Any interval more than one and a half times the median of the window. That threshold is relative on purpose: on a 60 Hz display a 25 ms frame is a stumble, while on a 240 Hz display 25 ms is six missed refreshes and a visible jolt, and a fixed millisecond cutoff would call one of those two wrong. The counter next to the graph tells you how many of the last 300 frames crossed it.
My laptop reads far lower on battery than plugged in.
That is the power management doing what it was designed to do. Unplugged, most laptops drop the CPU and GPU clocks, and several manufacturers also halve the display's refresh rate, which puts a hard ceiling on this measurement before the drawing work is even considered. Compare battery to battery and mains to mains, and if the two differ by more than about a third, the machine is choosing a power profile rather than failing.
The number sits exactly on a round figure and refuses to move. Is it stuck?
It is locked to the display, which is the healthy state. Frames are handed out when the screen is ready for them, so a machine with drawing time to spare produces one frame per refresh and the rate lands on the panel's own rate with almost no variation. You will see it come unstuck the moment you raise the object count past what the machine can finish inside a single frame.
Does the graph itself slow the measurement down?
Barely, and by design. The frame intervals are collected into a plain array and only summarized onto the screen eight times a second — updating React on every frame would mean sixty full re-renders per second of the panel, the table and the graph, which is enough drawing work to measurably lower the very number the page exists to report. The tradeoff is that the readout lags your input by up to an eighth of a second while the underlying samples stay exact.
About frame rate, frame pacing and what a browser can measure
Frame rate is a rate only by convention. What actually exists is a sequence of intervals — the gaps between the moments a finished picture is handed to the screen — and every figure anyone quotes is a summary of that sequence. Averaging it is the crudest summary available, and it is the one that hides the failure people actually complain about: thirty perfect frames and one that took 90 ms still average out near the target, while the eye registers the 90 ms one as a jolt. That is why this page keeps the intervals, draws them, reports the median as the headline and the 99th-percentile as the 1% low, and counts how many frames ran long. Frame pacing, the evenness of that sequence, is a separate quality from its speed, and a machine can be excellent at one and poor at the other.
A browser adds a ceiling that has nothing to do with your hardware’s ability to draw. requestAnimationFrame hands out callbacks in step with the compositor, which is in step with the display, so this canvas can never exceed the rate the panel is running at however little work it is given — and it will happily report a number below that rate when the work does not fit inside one frame. Finding out what that upper limit actually is on your machine is a different measurement with a different method, and it lives on the refresh rate test, which times an idle loop rather than a loaded one precisely so that the answer describes the display instead of the scene. If the reading here matches that ceiling at every load step, this machine has drawing headroom to spare.
Once a number is in front of you, the useful question is which part of the machine ran out first. A rate that falls the moment the object count rises is the drawing path saturating; a rate that stays flat while the 1% low collapses is something else on the system interrupting, and the bottleneck calculator is the place to reason about which of a CPU and a GPU is holding the other back in a real build. Two neighboring complaints get mistaken for low frame rate and are not: motion that looks smeared rather than jerky is the panel’s pixels rather than your frame times, which the ghosting test makes visible, and a picture that is smooth but answers your hand late is latency, which the input lag test times from the press to the painted frame.
What the frame counter keeps
Every number on this page is worked out by JavaScript running in the tab you are reading it in. Nothing you type, paste or open is uploaded, logged or kept, which is also why the tools carry on working after you disconnect from the network.
The only record this page builds is a rolling array of 300 numbers, each one a duration in milliseconds. It overwrites its oldest entry as the window advances and is discarded when you leave, so there is no session, no score history and nothing about your machine to keep — the summary you copy is assembled at the moment you press the button and exists nowhere else.