読了時間とは、テキストを最初から最後まで読み通すのに必要な推定時間です。日本語では 1 分あたり 400〜600 文字、英語では 200〜250 語という値が目安として広く使われます。ブログやニュースサイトで表示が一般化したきっかけの一つは Medium で、同社は 2014 年 6 月に自サイトの算出方法を公開しています。そこで使われている前提は 1 分あたり約 275 語で、上記の目安より速い値です。つまり同じ原稿でも、どの前提値を採るかで表示される分数は変わります。

計算そのものは単純で、本文の総文字数 (または単語数) を 1 分あたりの読書速度で割り、端数を切り上げます。2,000 語の記事なら、200 語/分では 10 分、275 語/分では 8 分です。日本語では 1 分 500 文字前後を採る実装が多く、技術文書や専門書を想定する場合は 300〜400 文字程度に下げます。画像やコードブロックを含む記事では、閲覧時間を加算する方法もあります。Medium は前述の公開情報の中で、インライン画像 1 枚目に 12 秒、2 枚目は 11 秒と 1 枚ごとに 1 秒ずつ減らし、10 枚目以降は一律 3 秒を加算する方式を説明しています。画像 1 枚 12 秒を単純に掛け続けると、画像が多い記事で読了時間が非現実的に伸びるためです。

読了時間を表示する目的は、読者が読み始める前に分量を把握できるようにすることです。「約 3 分で読めます」と書かれていれば、まとまった時間が取れないときでも読むかどうかを判断しやすくなります。書き手にとっては、記事を分割するか構成を絞るかを検討する材料になります。ただし、表示したことでどれだけ読まれ方が変わるかを一般化した数値は公表されていないため、効果は自サイトの計測で確かめる前提で扱います。

実装面では、サーバーサイドで事前計算する方法と、クライアントサイドで JavaScript により動的に算出する方法があります。静的サイトジェネレーターでは、ビルド時に各記事の読了時間を計算してメタデータとして埋め込むのが一般的です。Hugo はページ変数 .ReadingTime を標準で持ち、Gatsby では gatsby-transformer-remark が timeToRead を提供します。WordPress にも読了時間を表示するプラグインが複数あります。事前計算方式で気をつけるのは、本文を修正したあとに再計算されないまま古い分数が残る事故です。読了時間はメタデータではなく本文から導出される値なので、生成の順序を本文の確定後に固定しておきます。

算出範囲の決め方も、実装ごとにずれる部分です。見出し、図のキャプション、脚注、コード、表、コメント欄のうちどこまでを対象にするかで語数は変わります。コードや表は読み飛ばす読者と 1 行ずつ追う読者に分かれるため、どう扱っても全員に合う値にはなりません。端数の切り上げにも癖があり、300 文字の記事も 600 文字の記事も「1 分」と表示されます。短い記事が並ぶサイトでは、分数だけでは長短の差が伝わらないので、文字数を併記するほうが実用的です。

よくある誤解として、読了時間は正確でなければならないと考えるケースがあります。読書速度は個人差が大きく、同じ人でも題材や集中度で変わるため、正確な予測はそもそも成立しません。重要なのは正確さよりも一貫性で、サイト内のすべての記事に同じ前提値と同じ算出範囲を適用することが信頼につながります。実際より短く見せて読み始めを促す運用は、読み終わらなかった読者の期待を裏切るため、長期的には勧められません。

文字数カウントとの関連では、読了時間は文字数から直接導出される指標です。目標文字数を決めた時点で読了時間も決まるので、企画段階で「何分で読める記事にするか」から逆算して文字数を置く進め方もできます。5 分で読める日本語記事なら 500 文字/分の前提で 2,500 文字前後です。なお、読了時間の長短そのものを検索順位の指標に使うと公表している検索エンジンはありません。読者が読み通せる分量に収めることが目的であり、特定の分数に合わせて水増しや削減をする理由にはなりません。