こんにちは、NAEです。
コンテンツの有用さを表す指標として、はてなユーザのみでなく幅広いネットユーザやサービスに利用されている「はてブ数」。赤の太字に下線、ピンクの背景というスタイルは多くの方になじみのあるものと思います。
さて、何気なく目にしているコイツが一体何モノなのか。その正体とは?なぜそうなったのか?背景を無駄に深掘りすると見えてくるものとは?
今回はそんなお話。
実はgif画像です
どこからどうみても文字でしょ!なこのパーツ、実は小さなgif画像でできています。
たとえばはてブ数が1の場合、
という感じで、はてブ数に応じたgif画像が1つ1つ準備されています。
(そのため、はてなブログのテーマやCSSをいくら変えてもここのフォントは変えられません)
テキストを使わない理由
テキストと画像を比べると一般的にはテキストのほうが軽いと思いますよね。
でも、ここはもう一歩深く踏み込んでみましょう。画像とテキスト、各々の場合について軽さ(表示の早さ)を比較する思考実験をしてみたいと思います。
※以下、テクニカルで細かい話が続くので、興味のない方は「勝敗まとめ」まで飛ばしてください。
比較項目は、ダウンロードの開始からデータが表示されるまでの流れに沿って以下の通り。技術的にはもっとたくさんの要素が絡むんですが、画像vsテキストという比較に直接関与しない要素が大きく影響するもの(DNSルックアップの速度や接続先CDNサーバとの接続確立までの時間など)は今回は無視しています。
- データをダウンロードするまで
- 1.ダウンロードが必要なデータサイズ
- 2.キャッシュの利用可否
- ダウンロード済のデータを表示するまで
- 3.レンダリング速度
比較1:データサイズ
比較結果:gif画像の勝利
- テキストの場合:× 420~ バイト
- gif画像の場合:◯ 100 ~ 200 バイト
データサイズが小さほうが当然ダウンロード時間が短くて済むため、gif画像の圧倒的勝利です。
詳細は以下をどうぞ。
テキストの場合
HTMLに用いるタグやクラス名に依存するものの、以下ソースの場合で文字数は最小で141文字、データサイズは約420バイトです。もしフォントサイズなどを追加で指定する場合はサイズはもっと増えます。
<div class="htb-cnt"><span class="htb-num"></span> users</div>
.htb-cnt{color:red;font-weight:bold;text-decoration:underline;background:pink;}
その他前提事項
- はてブ数を取得するJavascriptは画像の場合でも必要なので割愛
- ただしはてブ数を挿入する箇所を識別するためのspan要素は記述
- 文字コードはUTF-8(1文字3バイト)を想定
gif画像の場合
画像のデータサイズは主に画像の縦横の大きさと内容に依存します。したがってデータサイズはてブ数の桁数によりますが、独自の調査によると
- 大きさ:35~69px × 13px
- サイズ:100~200バイト
のようです。
比較2:キャッシュの利用可否
比較結果:差分なし
- テキストの場合:◯ 利用可能
- gif画像の場合:◯ 利用可能
ブラウザキャッシュとは、1回表示したページやその中で使われている画像をPCやスマホ側に保存しておくことで、2回目以降表示するときにダウンロードの必要をなくし、ページを高速に表示させるためのしくみです。そのため、一般的にはブラウザキャッシュが効く=軽くなる、と言うことができます。
PCやスマホ内にキャッシュ済のデータがあるか判断する際はそのデータのありか(URL)を検索条件として使います。データの中身がテキストであろうと画像であろうと、URLが決まればキャッシュのしくみを使うことができます。
したがって、テキストの場合もgif画像の場合もキャッシュは利用可能です。
比較3:レンダリング速度
比較結果:gif画像の勝利
- テキストの場合:△ 「 users」の描画 → はてブ数の取得 → はてブ数の描画 → CSSの読み込み → HTMLの走査 → 装飾の適用
- gif画像の場合:◯ はてブ数の取得 → 対応するgif画像をインラインで描画
レンダリングとは、PCやスマホにダウンロードされたデータをブラウザに表示するための処理を指します。
処理の順番はコードの書き方などに依存するので詳細は割愛しますが、必要なステップはおおよそ上に書いたとおりです。定性的な比較になってしまいますが、テキストの方が処理のステップが多く、またHTMLの走査という比較的重めの処理が必要であるため、表示に時間がかかるものと推定されます。(とはいえそこまで影響があるわけではないと思いますが・・・)
一方gif画像は、単に指定された小さなファイルを読み込むのみなので今回の場合はテキストよりも早いのでは?と推定されます。
したがって、レンダリング速度はgif画像の勝ちとします。
勝敗まとめ
以上まとめると、思考実験による定性的な比較ではgif画像の方が優勢であることがわかりました。表示を軽くするにはgif画像を使うほうがよさそうです。
評価項目 | テキスト | gif画像 |
---|---|---|
1.データサイズ | × | ◯ |
2.キャッシュの利用可否 | ◯ | ◯ |
3.レンダリング速度 | △ | ◯ |
はてブ数の上限はいくつか
さて、gif画像を使う理由がわかったところで、次に気になるのはgif画像で準備されているはてブ数の上限は?ということ。
さっそく調べてみましょう。まずははてブ数1の場合から。
どうやらURLの最後のgifファイル名がはてブ数に対応しているようです。命名規則は5桁数字.gif。つまりはてブ数99999まで対応しているのかな?
と思ったら、どうやら上限値は20000のようです。20001以上のURLにアクセスすると403 forbiddenが返ってきます。
- 20000はてブ
- 20001はてブ
- 画像・・・なし(403 forbidden)
- URL・・・http://cdn.b.st-hatena.com/images/users/gif/normal/20001.gif
というわけで、はてな運営側としては「まさか20000もはてブされることなんてないだろう」と思っているようです。
上限を超える可能性
この上限値は、今現在はてブ数が20000を超えるページが存在しないため設定されているものと推定されます。
では今後、はてブ数20000を超えるページができる可能性はあるのか?
結論としては、近い将来ありうるです。
歴代史上最多はてブ数
まず、はてな史上もっともはてブを集めたページを調べてみました。(2016/05/23時点)
1位:Yahoo Japan 14203ユーザ 初ブクマ日:1989/01/05
1位は日本人が愛してやまないYahoo Japanでした。ちなみに2位はTwitter(9119ユーザ)、Googleは6位(7443ユーザ)、Amazonは11位(6143ユーザ)です。
英語の勉強法がGoogleより上位に食い込んでいたり、論文の書き方や肩こりの解消法が10位以内に入っていたりと、どことなくはてなっぽさを感じますね。
したがって、Yahoo Japanにもう6000回ブックマークがつけばはてブ数20000を超えることができます。
はてブのアクティブユーザ数
一方、今後のはてブ数の伸びしろを見極めるため今現在のはてなのアクティブユーザ数を見てみます。
はてなと言えば先日東証マザーズに上場しました。そこでIR情報を漁ってみたところ、2016年2月24日開示資料「成長可能性に関する説明資料」の7ページ目に「2015年7月時点のアクティブユーザは5400万人」という記載があります。
そう、なんと日本人の3人に1人がはてなのサービスを利用していることに!(ほんとかよ)
残念ながらアクティブユーザと判断する基準およびサービスごとの利用者の割合は開示されていません。そこで仮にアクティブユーザ数は全はてなユーザの1%、はてブ利用者をそのうち10%と厳しめの想定で資産すると・・・
5.4万人が今現在はてブを利用していることになります。Yahoo Japanがはてブ20000に達するまで必要なはてブ数は残り約6000。つまり、はてブユーザの10人に1人+αがYahoo Japanをはてブするとはてブ上限20000に到達する計算になります。
なんだかいけそうな気がしてきましたね。
実験・・・する?
さて、このブログの読者は2016/05/23時点で約60人。
影響力は微々たるものですが、せっかく調べたので実験してみたいというのが正直なところ。
みなさまYahoo Japanをはてブして何が起こるか試してみませんか(ゲス顔)。
まとめ
というわけで、GT Metrixを使ってブログのパフォーマンスチューニングをしている中で見つけたはてブトリビアのご紹介でした。
はてブ数を表示する。ただそれだけのことですが、その中を深堀りしてみると可能な限り軽く、表示速度を早くしたい、というはてな陣営の涙ぐましい努力を垣間見ることができました。運営のみなさま、お疲れさまです&ありがとうございます!
ちなみに、はてなスターについても一部でgif画像を利用しているみたいですね。
今回は以上です。