Why a teleprompter scrolls faster than the words-per-minute it promises
A speed dial set to 130 words a minute can move your script at 200. We shipped that bug, found it, and fixed it — here is the arithmetic, and how to test any prompter in thirty seconds.
A teleprompter that paces itself by dividing its whole scroll range by your script's speaking time will scroll faster than the words-per-minute it displays, because the scroll range includes blank lead-in and run-out padding that contains no words. The error is worst on short scripts: on a 900px-tall window, a dial set to 130 wpm moved an 80-word script at roughly 200 wpm, a 300-word script at 150, and a 1,000-word script at 136. The fix is to pace the text's own height rather than the scroll range.
A teleprompter has one number that has to be true. Everything else about it — the mirroring, the fonts, the remote — is convenience. The speed is the product. If the dial says 130 words a minute and the script moves at 200, you are not reading a script, you are chasing one, and every take comes out breathless for reasons you cannot name.
Ours said 130 and moved at about 200. Here is how that happens, because the cause is not the speed dial, and it is not a rounding error. It is geometry.
Where the time goes
A scrolling prompter needs a speed in pixels per second. It knows two things: how long your script should take to say — word count divided by words per minute — and how far the page has to travel. The obvious move, and the one we made, is to divide one by the other:
pixels per second = total scroll distance ÷ speaking time
That looks like it finishes the script exactly when the words run out. It does. The trouble is what “total scroll distance” contains.
A prompter does not start with the first line jammed against the top of the screen. It starts it low, so you can see what is coming, and it leaves room below the last line so the final sentence can climb to a comfortable reading height instead of stopping at the bottom edge. That is lead-in and run-out padding, and in our case it was most of a screen at each end.
That padding is inside the scroll distance. It contains no words. So the formula above hands the script a time budget sized for your words, then spends part of it dragging blank screen past you — and the only way to still finish on time is to move the words faster than you asked.
The error is a function of how long your script is
Put the padding in one term and the text in the other and the overshoot falls out:
overshoot = 1 + (padding outside the viewport ÷ height of the text)
The padding is fixed by the layout. The height of the text grows with the script. So the error shrinks as scripts get longer — and on the short scripts people actually use to try a prompter out, it is enormous.
Our old layout put 85vh of padding above the script and 85vh below it. On a 900-pixel-tall window that leaves about 744 pixels of padding sitting inside the scroll range but outside the screen. Against a script set in our Large size — 64px, 1.5 line height, about six words to a line on a wide window — that gives:
| Script | Height of the text | Overshoot | Dial says 130 wpm, you get |
|---|---|---|---|
| 80 words | 1,344 px | 1.55× | ~200 wpm |
| 150 words | 2,400 px | 1.31× | ~170 wpm |
| 300 words | 4,800 px | 1.16× | ~150 wpm |
| 600 words | 9,600 px | 1.08× | ~140 wpm |
| 1,000 words | 16,032 px | 1.05× | ~136 wpm |
Those figures are computed from the layout, not timed with a stopwatch, and they move with your window height and text size — a shorter window or a larger font makes them worse. But the shape is the part that matters, and the shape is not a matter of opinion: the shorter your script, the further the prompter runs ahead of its own dial.
It is a nasty failure because it is invisible. There is no glitch to notice. The scroll is perfectly smooth, the number on screen is perfectly confident, and the only symptom is that you keep running out of breath and blaming yourself.
Test yours in thirty seconds
This works on any prompter that shows you an estimated runtime, which is most of them.
- Paste a script. Note the runtime the tool displays — call it R.
- Press start, and time the whole scroll with a stopwatch, from the moment it begins moving to the moment it stops.
- Compare.
A prompter that paces honestly cannot finish in R. It has to take longer, because after your last word crosses the reading position there is still run-out to travel, and before your first word arrives there is lead-in. Honest total time is R plus that transit.
So: if the total scroll time comes out equal to the displayed runtime, the padding is being charged to your speaking clock. The tool is finishing on time by moving your words faster than it said it would.
For the confirmation, run it twice — once with about 80 words, once with about 800 — and work out the effective pace each time by dividing the word count by the time the words themselves took to pass. If the two paces differ, and the short script comes out faster, you have found length-dependent error, and there is only one thing that causes it.
The fix
Pace the text, not the scroll range:
pixels per second = height of the text ÷ speaking time
Measured, in our case, from the first word to the last — we already wrap every word in a span to grey out what you have read, so the distance between the first and last of them is free to compute and exactly right.
That change has a consequence you have to handle, and it is probably why the broken version is attractive in the first place: once the words move at the honest speed, the padding has to be crossed at that speed too, and suddenly there is a long crawl through blank screen at each end. Dividing by the whole range hides that. It is a bug that disguises a layout problem.
So the layout has to be fixed as well, not papered over:
- Stop when the script is read, not when the scroll ends. The run-out exists so the last line can reach the reading position. Scrolling through the rest of it leaves the reader staring at an empty screen — at an honest pace, that was about fifteen seconds for us.
- Shorten the lead-in. Ours started the first line at the very foot of the screen, nearly a full viewport below the reading position. That is a long, slow nothing before the first word arrives. It now starts a little below the middle: 45vh in, 70vh out.
Together: the words move at the speed on the dial, and the blank screen at either end is short enough that nobody has to wait through it.
Why we are telling you
Partly because the arithmetic is useful to anyone building one of these, and it took us longer to find than it should have — the symptom reads like a speed-dial calibration problem, and it is not.
Mostly because the runtime figure on our bar is the same number the scroll is derived from, and we would rather you were able to check that than take our word for it. The test above works on us too. Run it.
LensCue is a free online teleprompter — no signup, no watermark, and your script never leaves your browser. There is also a script timer if you only need to know how long a script runs before you record it.