Reading Time Estimates: What the Minutes Actually Mean

Reading time in minutes is usually word count divided by words per minute. The entire claim sits on the speed constant. Silent reading of general English prose is often placed between 200 and 250 words per minute. Technical documentation, legal text and dense philosophy are slower. Skimming is faster. A single constant applied to every page on a site will be wrong for some of them by design.

A code block is not read at prose speed. Neither is a comparison table or a multi-level checklist. Some calculators ignore non-prose blocks; others count every token the same way. Ignoring them underestimates time on tutorial pages; counting them as prose overestimates time on pages that readers scan rather than read line by line. Decide which behaviour matches your content and keep it consistent.

Images do not add words, but they add time. A figure that needs interpretation can cost as much attention as a short paragraph. Video embeds dominate the visit when autoplay is off and the reader actually presses play. A pure word-based estimate on a media-heavy page is a lower bound, not a realistic total. Some sites add a flat number of seconds per image; that is still crude, but better than pretending images are free.

Chinese reading time is based on characters per minute, not words per minute, with common estimates ranging from roughly 300 to 500 characters per minute. Applying an English words-per-minute model to Chinese text is meaningless. Mixed-language pages need separate estimates or a clearly labelled hybrid.

Round to whole minutes, and avoid false precision like 6.4 minutes. Prefer ranges when the content type varies widely, or pair the number with a short label such as average silent reading. If the page is primarily a tool with a short explanation, consider omitting reading time entirely; the metric was designed for articles.

Whatever speed you choose, document it next to the feature. When someone later complains that a page takes longer, you can say which assumption was used. Changing the constant later will shift every page at once, which is fine if you treat the number as relative rather than absolute.

For a mostly English technical blog, 220 words per minute on body text, excluding navigation and footers, is a reasonable starting point. Exclude pure code blocks from the count or weigh them lower. Revisit the constant if analytics show that average engaged time is consistently far above or below the estimate.

Reading time helps on long articles and distracts on tool pages, changelogs and short announcements. If the estimate is under two minutes, omitting it often looks more professional than advertising a trivial duration. When you do show it, keep the label honest: estimated reading time based on word count is clearer than a bare 7 min that implies measurement.

If average engaged time on a class of articles is consistently double your estimate, lower the words-per-minute constant for that class. If users bounce in seconds, the problem is rarely the reading-time label; it is title, intro or page speed. Recalibrate quarterly at most. Daily tweaks to the constant create noise without teaching you anything about content quality.

If the business wants every post to look short, pressure will appear to raise the words-per-minute constant until times look flattering. Resist that. An honest longer estimate filters the wrong readers less painfully than a two-minute promise that becomes a twelve-minute slog. Keep the constant in version control next to the feature so changes are reviewable rather than silent.