Why TypingKit has a Mac app
Thirty milliseconds a browser can't give back.
A typing trainer lives on one number: the time from the key going down to the letter changing on the screen. In a browser, that is 30 to 50 milliseconds. In a native Mac text view, it is about two and a half. We measured both before we wrote a line of the app, and the difference is the reason TypingKit for Mac exists.
Three parts of every key
Whatever you type into, three things stand between your finger and the letter.
- The system delivers the key. macOS turns the key press into an event and hands it to the app in front. About two milliseconds with a real keyboard, and no app can change it.
- The app does its work. It decides whether the key was right, colors the letter, moves the caret. On typingkit.com this takes about 2 ms; in the Mac app, half a millisecond. Neither is anything you could feel.
- The letter gets to the screen. This is where they part. A web page does not draw when your key arrives: the browser notes the change and paints it at its next animation frame, and the compositor puts that frame on the screen at the refresh after. On a 60 Hz display that is one to two frames, 16 to 33 ms, before the screen's own refresh. A native text view draws the letter inside the key press, and macOS shows it at the very next refresh.
What we measured
| Native Mac text view | typingkit.com in Chromium | |
|---|---|---|
| Key to drawn, median | 2.4 ms | 32 to 48 ms |
| 95th percentile | 4.1 ms | 40 to 56 ms |
| The system delivering the key | 1.9 ms | 0.2 ms* |
| The app's own work per key | 0.5 ms | 1.4 to 2.1 ms |
Mac: 500 keys of A Tale of Two Cities typed at 75 words per minute on a real keyboard, in the first version of the typing area the app is built on, on a 60 Hz 5K display. Browser: 600 keys of Pride and Prejudice sent through Chromium's own input path on the same display, timed with the browser's Event Timing API (which rounds to 8 ms), against the dev server and the live site. *Keys sent inside the browser skip the system's part, so the browser's total is if anything a little low. The screen's own refresh comes on top of both.
Why the website can't close the gap
Our first guess was our own code. It was not: the web reader handles a key in about two milliseconds, and the rest of the time is the browser waiting for its next frame. No page can paint before that frame. Drawing on a canvas, or moving the letters with transforms, still waits for it. The fix was never going to be inside the browser.
So we built the Mac app
TypingKit for Mac puts the whole chapter in one native text view and changes one or two letters per key, so macOS lays out only the line you are on. Around that typing area is the rest of TypingKit, with the same rules down to the code: the seventeen books in sittings with a review for every chapter, the library of passages with the ghost of your best run and replays, the typing test, and the EPUBs you bring yourself. It signs in to the same account as typingkit.com, so your place in a book follows you between the two.
See it on your own Mac
Numbers like these depend on the keyboard, the display and the Mac. The app measures every key, so you don't have to take ours: open Settings › Readout and turn on Show the time from each key to the screen. While you type a chapter or a test, a line under the text shows the last key, the median and the 95th percentile.
Does it matter?
At 75 words per minute a key comes every 160 milliseconds; at 120, every 100. Forty milliseconds is a large share of that: the letter trails your finger instead of keeping up with it. Plenty of people never notice, and practice on the website works just as well for them. We noticed it ourselves: on the web, the text felt a step behind our fingers, and that is where this started. The Mac app is for typists who feel it, and for anyone who wants a window of their own on the desk for typing.
