こんにちは、HOMELY制作チームです。今年の6月、このサイト自身の高速化をやりました。結果だけ先に書くと、サーバーがページを返し始めるまでの時間（TTFB）が、約0.5秒から0.055秒になりました。およそ10倍です。
制作会社としては、ここで「表示速度を改善して問い合わせが〇%増えました」と続けたいところです。お客様に高速化を提案するときの、いちばん分かりやすい説得材料になるからです。
でも、書けません。問い合わせが増えたかどうか、分からないからです。増えたとも減ったとも言えない。その理由も含めて、自社サイトの高速化で正直に分かった3つのことを書きます。
1. 「速くすれば問い合わせが増える」の半分正しいところ
通説：表示速度は問い合わせに直結する
「表示に3秒かかると半分の人が離脱する」といった話は、Googleをはじめ多くの調査で繰り返し示されています。Googleは2018年に、表示速度をスマートフォン検索の順位要因に加えると公式に発表しました。速いサイトのほうが、読まれ、検索で有利で、問い合わせにつながる。この通説は正しいです。
でも、「速くしたから増えた」と言えるのは、前後を測っていた会社だけ
ここからが本題です。
6月に高速化する前、このサイトの問い合わせ数を月別に記録していたかというと、していませんでした。フォームからの送信はメールで届く。メールは処理したら終わり。「先月は何件だったか」を数える仕組みが無かった。だから速くした後に増えたかどうか、比べる相手がいない。
さらに、6月以降このサイトでは記事の連載を始めています。仮に問い合わせが増えていても、速度のせいか記事のせいか、分けられません。効果が分かるのは、測る仕組みを先に作った会社だけ。高速化を提案する側が、自分のサイトでそれをしていなかった。これが1つ目の正直な結果です。
2. 1982年、IBMは「0.4秒」に線を引いた
少し歴史の話をします。
1982年、IBMの研究者ウォルター・ドハティらが、コンピュータの応答時間と作業者の生産性の関係を調べた論文を出しました。当時のコンピュータは、命令を打ってから応答が返るまで数秒待つのが普通でした。研究の結論は、応答が0.4秒を切ると、作業者の思考が途切れず、生産性が応答時間の短縮分以上に上がる、というものでした。「ドハティのしきい値」と呼ばれます。
40年以上前の話ですが、人間の側は変わっていません。ページが返ってくるまで0.5秒待つのと、0.055秒で返ってくるのとでは、読む人の「思考の途切れ方」が違う。数字にすると小さく見えますが、店の入口のドアが重いか軽いかの違いです。重いドアの店は、入らなかった人の数を知ることができない。入らなかった人は記録に残らないからです。
私たちは高速化を「増やす施策」ではなく「失わない施策」と呼んでいます。増えた分は測れるが、失っていた分は測れない。だから「増えました」と言いにくいのは、ある意味で当然でもあります。
3. 高速化で分かった、残り2つのこと
2つ目：遅さの原因は「凝った機能」ではなく「掃除していないゴミ」だった
高速化というと、サーバーを高いプランに変える、画像を全部作り直す、といった大がかりな話を想像されます。
このサイトで最初に見つかったのは、1.3GBまで育っていたエラーログのファイルでした。開発時のデバッグ設定が本番でも有効になったままで、細かい警告が何年も書き足され続けていた。ページを表示するたびに、この巨大なファイルに追記していたわけです。設定を切り、ファイルを消した。それだけで体感が変わりました。
その上でページキャッシュ（一度作ったページを保存して次の人に使い回す仕組み）を入れて、0.5秒が0.055秒になりました。費用はゼロです。遅さの原因の多くは、機能ではなく、誰も見ていないゴミでした。お客様のサイトで高速化を提案するとき、いまは最初にゴミを探します。
3つ目：画像の最適化で、元に戻せない失敗をした
正直に書きます。画像を軽くするツールを入れたとき、設定の初期値が「既存の大きな画像を縮小する」になっていることに気づかず、206枚の元画像が1920ピクセル幅に不可逆に縮小されました。バックアップは取っていませんでした。
このサイトの用途では1920ピクセルあれば実害はほぼ無いのですが、印刷用の元データとして残しておきたい写真を、同じ手順で扱っていたら取り返しがつかなかった。以後、画像ツールを入れるときは「既存画像を触る設定」を先に切り、バックアップを取ってから動かすようにしています。速くする作業には、戻せない操作が混ざっている。これが3つ目です。
ついでに書くと、画像の変換は約5,000ファイルのうち600弱で止めています。全部やるより、記事に使われている画像から順にやるほうが効くと判断したからです。全部やらないと意味がない、というものではありません。
4. HOMELYならどうするか
もしHOMELYがあなたの会社の担当者で、これから高速化するなら、順番はこうです。
- 先に測る。問い合わせ数（フォーム送信数）を月別に数える仕組みを作る。数えるだけなら、フォームの送信をスプレッドシートに記録するだけで足ります
- ゴミを探す。巨大なログ、使っていないプラグイン、切り忘れたデバッグ設定。費用ゼロで一番効く
- 戻せる状態で触る。バックアップを取り、画像ツールの「既存を変更」設定を切ってから動かす
3か月後に、問い合わせ数と速度を並べて見る。増えていれば「増えた」と言えるし、変わらなくても「失っていた分を止めた」とは言えます。
このサイトは、順番を間違えました。だから「増えた」とは書けません。あなたのサイトでは、測ってから速くしてください。
サイトの「ゴミ」と「重いドア」を無料で点検します。
サーバー応答時間、肥大化したファイル、使われていないプラグインを確認し、費用ゼロで直る項目と、戻せない操作が含まれる項目を分けてお伝えします。→ お問い合わせ
