DEV Community: ToolsBracker

I Built a Free Browser FPS Tester Using requestAnimationFrame (Next.js + TypeScript)

ToolsBracker — Thu, 28 May 2026 09:23:57 +0000

A few weeks ago I wanted to check my browser frame rate
quickly without downloading any software. Every tool I
found was either a desktop app, required an account, or
was buried behind ads.

So I built fpstest.pro, a free browser-based FPS tester
that works instantly with zero setup.

Here is how the core FPS measurement works and what I
learned building it.

The Core Problem: Measuring Real FPS in a Browser

The browser does not expose a direct "current FPS" API.
You have to calculate it yourself using
requestAnimationFrame.

The idea is simple. requestAnimationFrame calls your
callback once per frame. If you track the timestamps
between calls, you can calculate how many frames are
rendering per second.

let frames: number[] = []
let rafId: number

function tick(timestamp: number) {
  frames.push(timestamp)

  // Keep only last 60 frames for rolling average
  if (frames.length > 60) {
    frames.shift()
  }

  rafId = requestAnimationFrame(tick)
}

requestAnimationFrame(tick)

Every 500ms I calculate the current FPS from the frame
timestamps:

function calculateFPS(frames: number[]): number {
  if (frames.length < 2) return 0

  const elapsed = frames[frames.length - 1] - frames[0]
  const fps = ((frames.length - 1) / elapsed) * 1000

  return Math.round(fps)
}

The Stats: Avg, Min, Max, Frame Time, Stability

Just showing current FPS is not enough. I wanted the
same stats you see in MSI Afterburner.

Average FPS is straightforward — sum all calculated
FPS readings and divide by count.

Min and Max track the lowest and highest FPS
recorded during the test.

Frame Time is 1000 / currentFPS — how long each
frame takes in milliseconds. At 60 FPS this is 16.7ms.
At 144 FPS it drops to 6.9ms.

Stability is the interesting one. I calculate the
standard deviation of frame deltas and convert to a
percentage:

function calculateStability(frames: number[]): number {
  if (frames.length < 10) return 100

  // Get frame deltas (time between each frame)
  const deltas = []
  for (let i = 1; i < frames.length; i++) {
    deltas.push(frames[i] - frames[i - 1])
  }

  const mean = deltas.reduce((a, b) => a + b, 0) / deltas.length
  const variance = deltas.reduce((a, b) => 
    a + Math.pow(b - mean, 2), 0) / deltas.length
  const stdDev = Math.sqrt(variance)

  // Lower stdDev = more stable
  const stability = Math.max(0, 100 - (stdDev / mean * 100))
  return Math.round(stability)
}

100% stability means perfectly consistent frame timing.
In practice 95%+ is excellent, below 80% means noticeable
stutter.

The Cleanup Problem

This caught me early. If the user navigates away or the
component unmounts while the rAF loop is running, you
get a memory leak and potential state updates on an
unmounted component.

Always cancel on cleanup:

useEffect(() => {
  if (gameState !== 'running') return

  rafId = requestAnimationFrame(tick)

  // Cleanup: cancel rAF when component unmounts
  // or when gameState changes
  return () => {
    cancelAnimationFrame(rafId)
  }
}, [gameState])

The Monitor Hz Detector

This is a simpler version of the same idea. Instead of
tracking FPS over 10 seconds, I count raw frames over
exactly 3 seconds:

async function detectHz(): Promise<number> {
  return new Promise((resolve) => {
    let frameCount = 0
    const startTime = performance.now()

    function count() {
      frameCount++

      if (performance.now() - startTime < 3000) {
        requestAnimationFrame(count)
      } else {
        const hz = frameCount / 3
        resolve(roundToStandard(hz))
      }
    }

    requestAnimationFrame(count)
  })
}

function roundToStandard(hz: number): number {
  const standards = [60, 75, 90, 120, 144, 165, 240, 360]
  return standards.reduce((prev, curr) => 
    Math.abs(curr - hz) < Math.abs(prev - hz) ? curr : prev
  )
}

The roundToStandard function snaps the raw measurement
to the nearest real monitor spec. A reading of 143.7Hz
rounds to 144Hz.

One Gotcha: Battery Mode

I noticed during testing that laptops on battery saver
mode consistently showed 30-40 FPS even on a 144Hz
display. The browser throttles requestAnimationFrame
when the system is in power saving mode.

Added a note in the UI: "For accurate results, plug in
your laptop."

What I Used

Next.js 15 App Router with TypeScript
Tailwind CSS for styling
Recharts for the live FPS graph on the homepage
Lucide React for icons
Zero external APIs — everything runs in the browser

The Result

The site is live at fpstest.pro with 6 free tools:

FPS Meter (the one above)
UFO Motion Test (see 30/60/120/144 FPS visually)
Frame Rate Comparison (side by side)
FPS Reaction Test
Monitor Hz Detector
Input Lag Test

Also built a Chrome extension version that puts the FPS
meter, Hz detector, and reaction test in a popup —
submitted to the Chrome Web Store yesterday.

The requestAnimationFrame Accuracy Question

One thing worth knowing: browser rAF is not perfectly
accurate for FPS measurement. The browser can skip or
delay callbacks under heavy load, which is actually
useful for our purposes — we want to measure real
rendering performance, not theoretical maximum.

For a simple canvas test like this, rAF gives you a
good signal for whether your system is struggling. It
will not match MSI Afterburner numbers for in-game FPS,
but that is a different measurement entirely.

If you are into browser performance or gaming tools,
check out fpstest — all free, no signup, works
on any device.

Happy to answer any questions about the rAF
implementation in the comments.

Day 8 of Launching a Next.js Tool Site

ToolsBracker — Fri, 01 May 2026 02:04:34 +0000

Eight days ago I launched toolsbracker.com —
33 free browser gaming benchmark tools built
with Next.js 15.

Here's what actually happened.

The numbers on day 8

28 pages indexed by Google
47 keywords showing impressions in GSC
Real visitors from 5 countries
Bounce rate dropped from 74% to 41%
4 blog posts live, each indexed same day
Star ratings showing in Google search results
Chrome extension submitted to Chrome Web Store

What moved the needle fastest

Schema markup on every page.

Not just basic schema. SoftwareApplication,
FAQPage, HowTo, and BreadcrumbList on every
tool page. The result: star ratings showing
in Google search results on day 3. Most
sites never get this right.

Category hub pages.

I launched with 33 tool pages all sitting
directly under root. Google saw 33 unrelated
pages. After building category hubs at
/click-tests, /reaction-tests, /memory-tests,
/typing-tests — Google now sees an organized
authority site. Impressions jumped the same day.

Fixing the footer bug.

Every footer link pointed to href="#tools" —
a homepage anchor. Google was following those
links and hitting dead ends. Zero link equity
reaching actual tool pages. One fix. Massive
internal linking improvement.

Static dates in the sitemap.

I had lastModified: new Date() which told
Google every page changed on every deploy.
Google learns to ignore freshness signals
when everything is always "updated." Static
dates per page fixed this immediately.

What didn't move as fast as expected

Blog post traffic. Day 8 is too early for
blog posts to rank. They're indexed, they're
showing impressions, but clicks require
positions 1-10. Current average position is
58.8 across all keywords. That number will
drop over the next 60-90 days as domain
authority builds.

Patience is the actual skill in SEO. Not
the tactics.

What's next

One blog post per week targeting low KD
keywords verified in Semrush. Two new
backlinks per week from relevant platforms.
Check GSC every Friday and react to new
keyword data.

The site is at toolsbracker.com if you want
to try any of the tools or check the
architecture.

All 33 tools are free at
toolsbracker.com - no signup, works offline.

I built 33 free browser gaming tools with Next.js, Here's what I learned about SEO and PageSpeed

ToolsBracker — Wed, 29 Apr 2026 04:07:19 +0000

A few days ago I launched toolsbracker.com — 33 free
browser-based gaming benchmark tools. CPS test, reaction
time, WPM test, aim trainer, memory tests, color blind
test and more. No download, no signup, no ads.

Here's what building it actually taught me.

The stack

Next.js 15 App Router, TypeScript, Vercel. All 33 tool
pages are pre-rendered at build time with
generateStaticParams. Zero server cost, instant TTFB,
and the site works offline once loaded.

What I got right: SSG for tool sites

Static Site Generation is underrated for sites like this.
Because nothing is dynamic until the user actually clicks
a tool, pre-rendering all 33 pages gives you a 99 mobile
PageSpeed score without any optimization tricks. The score
came free from the architecture decision.

What I almost got wrong: flat site structure

I launched with 33 tool pages all sitting directly under
the root. Google saw 33 unrelated pages instead of an
organized authority site.

The fix was building category hub pages — /click-tests,
/reaction-tests, /memory-tests, /typing-tests. Each hub
links down to its tools. Each tool breadcrumbs back to
its hub. Now Google sees a structured hierarchy and ranks
the hubs for category-level keywords.

Schema markup is not optional in 2026

Every tool page has four JSON-LD blocks:
SoftwareApplication, FAQPage, HowTo, and BreadcrumbList.
The homepage has Organization, WebSite with SearchAction,
and ItemList.

This got me 100/100 on PageSpeed's SEO audit on day 3.
Most sites never achieve this because they treat schema
as optional. It's not.

The footer bug that was leaking link equity

My footer had 5 "Popular Tools" links all pointing to
href="#tools" — a homepage anchor. Google was following
those links and hitting a dead end instead of crawling
the actual tool pages. One fix, massive internal linking
improvement.

The sitemap mistake nobody talks about

I had lastModified: new Date() in my sitemap. This means
every single deploy told Google that all 33 pages changed
today. Google learns to ignore your freshness signals when
everything is always "updated."

Fix: static dates per page. Top 5 tools get a recent date.
Stable utility pages get their original publish date.

Results so far

Day 5: 98 mobile PageSpeed, 100 SEO score, 42 pages
indexed, visitors from 5 countries, blog post getting
traffic on day 1.

The site is at toolsbracker.com if you want to check
the source or try any of the tools.

What questions do you have about the architecture or
the SEO setup? Happy to share specific code in the
comments.

All tools are free at toolsbracker.com — no signup, works offline.