NaeNote

読者です 読者をやめる 読者になる 読者になる

NaeNote

気楽に生きたい外資コンサルのブログ

はてブ数を示す「XX users」の正体を知ってますか?(※追記あり)

テクノロジー テクノロジー-雑学・トリビア
このくらいシェアされています
スポンサーリンク
【おトク情報】 12月12日(月)まで!Amazonが本気の割引セール「CYBER MONDAY SALE」を開催中。会場はこちら!

はてなブックマーク数を示すテキスト

こんにちは、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以上の場合は403 forbiddenが返ってきます。

というわけで、今のしくみにおいて適切に表示可能なはてブ数の上限は20000であると言えます。

上限を超える可能性

さて、この上限値は今現在はてブ数が20000を超えるページが存在しないため設定されているものと推定されます。(他にも管理コストとサービスのバランスを考慮していると思いますが、詳細不明なので割愛)

では今後、はてブ数20000を超えるページがでてくる可能性はあるのか?

結論としては、近い将来ありうるです。

歴代史上最多はてブ数

まず、はてな史上もっともはてブを集めたページを調べてみました。(2016/05/23時点)

歴代はてブ多い順 / 全期間のランキング 1位~50位

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/25追記)
本記事の初回公開時点ではYahoo Japanトップページへブックマークをする実験の呼びかけの記載がありましたが、はてな運営から規約違反との指摘をいただき、記載を削除しました。ご迷惑をおかけしました。

上限に達したらどうなるか

では実際にはてブ数が20000を超えた場合に起こることや対応について予測してみましょう。

※以下、完全にぼく個人の想定に基づく予測です

当面は大丈夫?

さて、はてブ数の上限=gifファイルが準備されている数の上限、ということなので、おそらく

  • 内部データ上は正しくはてブが数は管理されている(20001以降のはてブデータが切り捨てられることはない)
  • ただし表示用のgif画像が存在しないので、「XX users」が表示されない

という状態になるように思います。したがって取り急ぎの対応としては、20001はてブ以上に対応したgif画像を準備するとなると予測できます。URLのフォーマット上は99999はてブまでは対応可能なはずですし、はてブ数を取得するプログラムへの影響もおそらく軽微なため、対応としては非常に軽いと思われます。

したがって、20000を超えたからと言ってだたちに影響はない、ということになります。たぶん。

ゆくゆくは大改変?(妄想)

ただし、将来のはてブ数の増加、およびはてブデータの管理方法まで突っ込んで考えた場合、話はそこまで単純ではない可能性があります。

はてブ数をクリックすると、いつ、誰が、どのようなタグやコメントをつけた上でブクマしたのか、というデータを見る事ができますよね。1つ1つのブクマのデータをきちんと保存しているのです。

では、はてブ数はどのように計算されるのか。単純に考えると「すべてのはてブデータに対し、対象となるWebページのURLで検索し、その件数を集計する」という処理になるはずです。SQLで言えばSELECT sum(1) FROM xxx WHERE ...といった感じのものですね。内部の設計やデータ構造にもよりますが、一般的にはあまり重いタイプの処理ではありません。

しかし、はてブデータの数が膨大になると処理速度の壁にぶち当たります。それこそたとえばFacebookばりにデータ件数が増えたなら、昔ながらのデータベースのしくみ(RDBMS)を使っていると技術的な制約によって処理が遅くなり、ゆくゆくは立ち行かなくなってしまう可能性があります。ブクマ数を表示するだけで5秒かかるとか絶対に嫌ですもんね。もちろんデータベースの内部的な設計を工夫することである程度までは対応できますが、やはり限界はあるし、工夫をすればするほどしくみ自体の管理運用が大変になってしまいコストもかかります。

したがって、ゆくゆくはいわゆるビッグデータ対応≒データベースのしくみの変更が必要になると思うんですが、これ実はとても大変です。一軒家で例えると「家屋には手を入れずに基礎だけコンクリからキャタピラに入れ替えて!」と言ってるようなもの。基礎が変われば上モノも少なからず影響を受けますよね。システムの基礎部分であるデータベースのしくみの変更は、旧来のしくみを前提に組まれたさまざまな処理を見直し&修正してあげる必要があるため、いろいろと大変なんです。

とはいえ、はてなのサービスは最近英語版も出しているみたいですし、世界展開も視野に入れる=ユーザ数が増えていくとなると、この大改変は避けて通れないかもねーと思ったりします。

つまり、はてブ上限20000の突破は通過点、ということ。まあ大変!(妄想)

結局何が言いたかったかというと

たかがブクマ、されどブクマ!

上限があるのには理由がある!

裏のしくみを見てみると考えるべきことは多い!

はてブ上限値の扱い(解放)については、必要になったタイミングでなにがしかの対応が入ると思います。状況を引き続きウォッチしていきたいと思います。

まとめ

というわけで、GT Metrixを使ってブログのパフォーマンスチューニングをしている中で見つけたはてブトリビア(+妄想)のご紹介でした。

はてブ数を表示する。ただそれだけのことですが、その中を深堀りしてみると可能な限り軽く、表示速度を早くしたい、というはてな陣営の涙ぐましい努力を垣間見ることができました。運営のみなさま、お疲れさまです&ありがとうございます!

ちなみに、はてなスターについても一部でgif画像を利用しているみたいですね。

はてなスターも一部は画像

今回は以上です。

スポンサーリンク