Engineer-to-Engineer: Building a Typing Test That Doesn't Lie to You

If you've ever shipped a "typing speed" feature into a developer tool, an educational dashboard, or a hiring pipeline, you've probably noticed that the simplest-looking metric in computing — words per minute — is also one of the easiest to game and the hardest to defend in a code review. The original article in this series pushes past the 80 WPM plateau. This one is for the people building the measurement itself: how do you write a typing test that survives scrutiny from an accessibility lead, a data engineer, and a skeptical senior dev all at the same time? We'll walk through the constraints, the formulas, the edge cases that bite in production, and a checklist you can paste into a PR description. Where the underlying mechanics of WPM calculation matter, I'll point to a thorough walkthrough at Lizely's WPM formula guide so you don't have to reinvent the theory from scratch. The Two Meanings of "Word" You Need to Settle Before Anything Else A typing test fundamentally answers "how many characters did a user commit, and over what interval?" Everything else is convention. Before you write a single line of measurement code, decide which of these two definitions your product will use, because they produce noticeably different numbers for the same user: The classic 5-character word. Divide total characters typed (including a trailing space) by 5. This is the convention most office-suite benchmarks report, and it's the one most "casual" testers expose to end users. The linguistically grounded word. Count whitespace-delimited tokens that are actually present in the source text. This is closer to how a linguist or a reading researcher would count. You cannot ship both silently. Either pick one and document it, or expose the formula in a tooltip and let the user see the math. The 5-character convention has a long history in typing research (see Wikipedia's coverage of the words-per-minute metric), and it's still the right default for general-purpose typing products because it normalizes across languages and punctuation density. The Time Window Is Where Most Bugs Hide A naive implementation measures Date.now() from the first keypress to the last keypress and divides. That's wrong in three ways that show up in real bug reports: Idle gaps inflate the denominator unfairly. If a user pauses for 12 seconds to think, their WPM collapses even though their burst speed was fine. The common fix is to stop the clock after, say, 3 seconds of no input, or to compute WPM over the active interval and surface "active time" alongside "elapsed time." Cold-start padding distorts short runs. The first keypress almost always takes longer than the average character. For runs under 10 seconds, either run a warm-up prompt (most competitive testers do this) or display a disclaimer that sub-15-second runs are indicative, not definitive. Backspace handling changes the meaning of the score. Does correcting a typo count against the user? Industry convention is "yes for accuracy, no for raw speed" — you compute raw CPM over all characters committed, and accuracy as correct / total_attempted. Don't conflate the two into a single score, or your accuracy and speed will appear to trade off against each other when they actually don't. If you instrument the active-time vs. elapsed-time split, you'll also catch a class of "are they really typing?" bots: if elapsed time exceeds active time by a large factor, you're probably looking at a paste event, not keystrokes. What You Measure vs. What the User Sees A reasonable internal model has three numbers: Quantity Formula Surface to user? Raw CPM total_keys / active_minutes Sometimes, as "raw" Net WPM (correct_chars / 5) / active_minutes Yes, primary metric Accuracy correct_chars / total_chars Yes, secondary metric The trap is letting "gross WPM" leak into the UI. Gross WPM rewards sloppy typing because it includes errors in the numerator; once a user notices that fixing typos lowers their score, they stop fixing typos, and the product has taught them the wrong thing. Always display the corrected (net) WPM. For keystroke handling, the event you'll listen for is the keydown event on a focusable element. Capture event.key, normalize for layout differences (Shift should not count as a character, modifier-only keys should be ignored), and decide your policy on IME composition events up front. If your test supports non-Latin scripts, you'll need to read from the input event instead, because keydown fires per Latin key press and double-counts for CJK input methods. Picking a Corpus Without Accidentally Building a Bias Engine Corpus selection is the silent politics of a typing test. Two questions to answer in your design doc: Dictionary vs. prose. A common-words dictionary produces higher and more consistent scores, but it trains only short, common tokens. Prose produces lower scores and more variance, but it surfaces real bigram weaknesses (more on bigrams below). Most serious tools offer both; pick a default and make the alternative one click away. Domain. Programming-language tokens (function, return, const) have dramatically different character distributions than English prose. If your user base is developers, a code-flavored corpus is more honest. But also consider keyboard layout: the same text typed on QWERTY vs. Dvorak vs. Colemak will produce wildly different WPM numbers, so don't let a "global leaderboard" mix layouts unless you've normalized for that. There's an accessibility angle here too. For users on screen readers or alternative input devices, the "competition" framing is actively hostile. At minimum, your test should allow pausing, should not auto-fail on long pauses, and should expose a "practice mode" that reports per-character latency rather than a single summary number. The Bigram Heatmap: The Single Most Useful Diagnostic You'll Add Once the headline metric works, the highest-leverage feature you can ship next is a per-bigram latency map. A bigram is just a two-character sequence; there are ~676 of them in English lowercase plus space. Plotting mean latency per bigram reveals exactly where a user hesitates, and it's much more actionable than "your WPM is 52." The implementation is straightforward: For each completed session, group keystrokes into pairs (th, he, e, s, ...). For each pair, record the inter-key interval in milliseconds. Render a grid where rows and columns are characters; cell color encodes mean latency. Sort the slowest bigrams to the top of a sidebar. Once a user sees that their ed, th, and tion transitions are slow, they can drill those specifically, and your product is now a training tool, not just a measurement tool. Shipping Checklist for a v1 Typing Test Use this list verbatim in your PR template: Time source is performance.now(), not Date.now(), to avoid clock-skew artifacts. WPM formula is documented in the UI tooltip and matches the code, character for character. Accuracy is reported separately from speed, and the formula is in the tooltip. Backspace behavior is explicit: errors counted in accuracy, ignored in raw WPM. The clock stops after a configurable idle threshold (3 seconds is a sensible default). Sessions under a minimum duration (15 seconds) display a confidence note. The corpus file is versioned and the version is shown in results. Layout is recorded (auto-detected when possible) and shown on the leaderboard. Pause/resume is supported and does not reset progress. The event handler correctly ignores modifier keys and handles IME composition. Paste is detected (event.inputType === 'insertFromPaste') and either rejected or flagged. Results are exportable as JSON for users who want to track their own history. If all twelve boxes are checked, your test will survive a code review from someone who actually knows the domain. Frequently Asked Questions What's a reasonable default for the idle-timeout threshold? Three seconds is the consensus in most consumer-facing typing tools. Shorter than that and thinking pauses get punished; longer and the user gets ambiguous results after walking away. Make it configurable in your advanced settings. Should I count capitalized words differently from lowercase ones? No, if you're using the 5-character-word convention. Capitalization adds one keystroke (Shift + letter) but only when starting a sentence or proper noun, so it doesn't materially shift the average. If you're using token-based counting, capitalization is irrelevant because the token is the same. How do I prevent paste-based cheating in a public leaderboard? Detect inputType === 'insertFromPaste' on the input event and disqualify the run. Be transparent about this in your rules. Also display the active-vs-elapsed time ratio; humans rarely sustain above a 1.2x ratio, while pasted runs typically show near-perfect 1.0x because they were applied in a single event. My users complain that their scores dropped after I "fixed" the formula. What do I do? This is almost always because the old formula was gross WPM and the new one is net WPM, or because you tightened the idle timeout. Don't roll back. Instead, ship a "score history" feature so users can see their own trend line, and announce the change clearly. Honest measurement always costs a few leaderboard positions in the short term, and that's the right trade-off. This article was drafted with AI assistance and reviewed for technical accuracy before publishing.