ECサイト高速化の必要性 | ZETA CX シリーズ

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

最近MarkeZineで

スマホでのECサイト利用、応答速度「5秒未満」でも36％が離脱【ジャストシステム調査】
URL:https://markezine.jp/article/detail/32806

という記事がありました。※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が悪化している可能性も大ということになります。