ECサイト高速化の必要性

サイトの表示速度が遅い要因

最近MarkeZineで

という記事がありました。※MarkeZineより引用

ECに限らずWebサイトは表示が遅いほど離脱を招いてしまうのは周知の事実ですが、PCよりスマホのほうがさらにそういった傾向は顕著になることは容易に予想できます。

ちなみに個人的には5秒というのはかなり長い（遅い）という気がしますが。

スマホはPCよりもスキマ時間で使われる事が多いのと、アクティブな利用者がPCよりも相対的に若いことなどもあり、表示にもたつくようではTVのザッピングのようにあっという間に他のサイトやアプリに跳ばれてしまうでしょう。

ところでサイトの表示の速い遅いというのはいろいろな要素によって決まります。

ネットの回線の速い遅い、利用しているデバイスの速い遅い（端末自体のスペックだけではなく、同時に動かしているアプリの数なども）などのサイトの実装の良し悪しではない部分もありますが、サイトにおいてはレスポンスとなるデータの返却が速いか遅いかということになります。

ただこのレスポンスの速い遅いというのは、というかレスポンスが速いのは問題ないので、もしレスポンスが遅い場合「何が原因で遅いのか」はケースバイケースです。

トップページの表示が遅いようであれば、サイトが稼働しているサーバなりクラウド環境のCPUかストレージ（DB含む）が遅い可能性が高いでしょうし、当社の得意分野であるサイト内の検索結果の表示が遅いようであれば、CPUやストレージに加えてメモリが足りない、単にロジックの出来が良くないなどの可能性もあります。

チューニングはボトルネック解消の連続

ところでこういった場合に一番遅い部分をいわゆるボトルネックと呼びますが、ボトルネックではない部分を高速化してもサイトの表示はほとんど速くなりません。

チューブとかホースで一番細い部分をほっておいてそれ以外を太くしてもそこを通る物体(水など)の量は増えないのと同じことです。

ちなみに話は逸れますが、組織の強化とかビジネスプロセスなどにおいてはボトルネックではなくウィーケストリンクという表現が使われることがあります。

鎖の輪で一番弱い部分をほっておいてそれ以外の輪を強くしても結局その鎖の引張強度はちっとも上がらないということです。

ボトルネックにしてもウィーケストリンクにしても、最大の原因を解消することが重要です。

ただし、最大の原因を解消した場合、ボトルネックは別の箇所に移ることになりますが、その新しいボトルネックが解消したボトルネックと1%くらいしか変わらない場合、残念ながら全体性能は1%しか向上しないということになります。

逆に新しいボトルネックは解消したボトルネックに比べてかなりマシだった場合、全体性能は大幅に向上することになります。

こうしたボトルネックの解消、いわゆるチューニングは地道な作業の繰り返しです。

ボトルネックが大幅に解消した事例

昔の話なのでテクノロジーとしてはあまり参考になりませんが、ボトルネックがほんのちょっとしたことで大幅に解消した事例として、私が1990年代に大規模なメールサーバの設計をしていた際、候補となるマシンが2つありました。

もう20年以上前のことなので名前を挙げてしまうと、一つはHPのNシリーズ、もう一つはSUNのEシリーズでした。

NシリーズはEシリーズの倍くらいの値段の上、CPUもPA-RISCというかなり速いチップを搭載していたため、有望なのはNシリーズかと思ってテストをしたところ、微妙にEシリーズの方が速いという意外な結果となりました。

ちなみにストレージはどちらのケースでもEMCに接続していたので条件は同じです。

そこでシステムコールを見てみると、当時HPはまだHP-UX 10.xというOSで、メールの配信先となるユーザが記載されているファイル、その当時はまだ/etc/passwdや/etc/shadowという時代でしたが、そのファイルがテキストファイルでそのスキャンにかなり時間を取られていることがわかりました。

SUNはSolaris 2.6くらいだったと思いますが、nscdというデーモンがバイナリ化したファイルを読む実装だったためHPよりもハードは遅くても全体性能としては速かったということです。

ちなみにシステムコールの結果をHPに伝えて、OSをHP-UX 11.xにアップグレードしたところ一気に性能が数倍速くなり、結果としてHPを採用したということがありました。

HPもHP-UX 11.xではpwgrdというSUNのnscdと同様のデーモンを実装していたので、ハードの寄与する割合が大きくなったためだと思われます。

当時のHP-UXはまだ10.xのほうが安定していたのでメーカーも最初は10.xを推奨していたのですが、11.xのほうが当時メールサーバとしてはメリットが大きかった、ということになります。

このように、チューニングの目的は全体性能なので、ボトルネックをまず調べるということは大変重要です。

もちろん、ボトルネックを調べずにハードをアップグレードしてもそれなりに高速化はされますが、もしボトルネックがロジックとか実装によるものである場合、一気に大幅な高速化を実現することもあるということです。

逆に言えば、それをせずにハードのアップグレードをするとROIが悪化している可能性も大ということになります。

ECで最も高速化が難しい部分の一つである検索

この記事でも

『優先すべきロジックや適切な並び順は扱う商材によって異なるが、商材を問わず圧倒的に必要とされる技術があると山崎さんは言う。それは、「処理速度」だ。』

と述べていますが、CXにしてもUXにしても常に最重要視するべきなのは処理速度、それも全体処理速度です。※ECzineより引用

検索というのはサイト内、特にECサイト内においてももっとも高速化が難しい部分の一つです。

検索結果として何が最適かは、時間が経てば変化しますし、同じタイミングでもユーザーによっても変化します。

また同じユーザー、同じタイミングでも場所が違えば、デバイスが違えば、など様々な条件で変化しうるのが検索結果です。

その検索結果を高速に出力するために当社はとにかく高速化にこだわって製品開発をしてきました。

このため、検索ではない画面においても当社の検索エンジンを使うほうが表示が高速になるという現象が起こることもしょっちゅう起こります。

例えばトップ画面やカテゴリトップにおいても、そこで表示すべき商品群を検索結果として扱うほうが速く表示できるというケースです。

特に検索に限った話ではなく、ECサイトが遅くて困っているようなケースがあれば、是非ご相談ください。