＠cosmeのコンテンツページ表示速度を約半分にした話

はじめに

4月からアイスタイルにジョインした suezawan といいます。
ブランドオフィシャル というサービスの開発エンジニアをしています。

ジョインして最初にした仕事が、
@cosmeのコンテンツページで表示速度が遅い問題を改善することでしたので、
実際に取り組んだことをお伝えしようかと思います。

また、ページ表示速度に課題があることは社内でも認識しており、
@cosmeを利用している人にとってより良い体験ができるよう、
日々改善に取り組んでおりますので引き続きサービスをご利用いただけると、なかの人としては嬉しいです。

なぜやるのか

サイトに訪れたユーザは、ページ表示速度が遅いと離脱していきます。
ECサイトなどではこれは致命的ですし、次またサイトを訪れるリピーターにもなってくれません。

　読み込み時間が0.1秒減ると、売上が1%増加
　ページ読み込み時間が1秒増えると、コンバージョン数が7%減少
　ページ読み込み時間が1秒増えると、PVが11％減少
　ページ読み込み時間が1秒増えると、ユーザーの満足度が16％減少

　引用 : 0.1秒の遅れが、1%の売上に影響する!? ページ表示速度の影響力と改善法まとめ

　また、2018年7月に導入を予定とされている、Google検索結果のアルゴリズム変更（通称 Speed Update）もあるので、
　ユーザにとって妨げにならないページ表示速度を維持し続ける必要があります。

　この ”Speed Update” （と私たちは呼んでいます）は、ユーザーに本当に遅い体験を提供しているようなページについてのみ影響し、ごくわずかな割合のクエリにしか影響しません。 　そのページがどのような技術を用いて制作されたかに関係なく、すべてのページに同じ基準を適用します。

　引用 : ページの読み込み速度をモバイル検索のランキング要素に使用します

どうやって解決するか

　本番環境にNew Relic などのAPM (Application Performance Monitoring) がインストールされており、
　ボトルネックが可視化されているといいのですが、残念ながらはいっていない状況でしたので、
　今回は本番DBのSlowQuery解析、および開発環境にインストール済みの XHProfによる解析の2軸で対応します。

1. SlowQuery解析

　一定期間に出力されたSlowQueryから、今回改善すべきページで発行されているクエリがないかを選別します。
　具体的には、アプリケーション側で発行するクエリとの照らし合わせの作業になります。

　また選別するポイントとしては、下記のパターンを探します。
　・定常的に発生しているか
　・特定のタイミングで発生していないか
　前者の場合はクエリかデータ量の見直し、後者の場合はバッチ処理とバッティングしていないか、
　ある条件（レアケース）を満たす場合に発生していないかを疑います。

　今回の改善対象ページでは、SlowQuery対象となっているクエリはありませんでした。
　もしあった場合は、クエリの見直し必要に応じてデータ量の削減や、インデックス設定などの対応などを行います。

2. パフォーマンス解析＠XHProf

　XHProfは、アプリケーションがリクエストを応答するまでの処理内容を可視化までしてくれるツールです。
開発環境アプリケーションを、XHProfで計測した結果が下記になります。

赤色の箇所が最も処理時間がかかっている部分、黄色がその次となります。
またその処理が実行されるまでの経路も可視化されるため、
なぜその処理がボトルネックになっているのかのアプローチへの手助けもしてくれます。

今回はfgetsが実行されているところで数秒かかっていることが分かりました。
あるコンテンツを表示するために、特定のAPIを取得したコンテンツ数分コールしている処理が原因でした。
API単体でみれば応答速度は問題ないのですが、「塵も積もれば・・・」というやつです。
API応答(0.2sec) × 10回コール = 2.0sec のように結果として応答速度に影響がでてしまいます。

今回は、API自体を高速化することは時間の関係で難しかったため、取得結果をcache化して対応することにします。

　参考 : xhprofの読み方

cacheサーバのリソースチェック＠Zabbix

　cacheサーバにはmemcachedを利用しているので今回cache化するコンテンツもmemcachedに保持させます。
　気を付けるべきこととしては、当たり前ですが下記に注意します。

・最大同時接続数 max connection に達しないか
・key長
・cacheするコンテンツサイズ

　cache化した後はmemcachedのリソースが想定より多く消費されていないかをチェックするために、
Zabbixでmemcachedのリソースを確認します。
※ 弊社では、監視ツールの1つにZabbixを利用しています。

　参考 : memcachedではキーの長さに制限がある

計測＠Lighthouse

　Lighthouseを使用し、First Meaningful Paint値で効果計測します。
　「First Meaningful Paint」は、ユーザーにとって意味がある表示が行われたタイミングを指し、
ページ表示速度の指標として一般的によく利用されている値です。

　下記のグラフは、GoogleスプレッドシートのSPARKLINE関数を利用して作成しています。
　基準値に対し、グラフバーで表示してくれるので、ぱっと見でどうなったかがわかりやすいです。

=SPARKLINE(値, {"charttype", "bar";"max", 基準値;"color1", "#E24340"})

　オレンジ色のグラフがbefore 、赤色のグラフがafterになります。左の数値が応答速度で単位はmsecです。

　ページ表示速度が、5.4sec(Before) -> 2.8sec(After) になったので、約半分まで改善できています！

　参考 : Lighthouseでwebサイトのパフォーマンスを計測する

さいごに

改善するためのアプローチから効果測定までを記事にまとめてみましたが、いかがでしたでしょうか。
実際に改善業務にあたるときに、なにから手につけたらいいか迷うエンジニアの助けになれば嬉しいです！

弊社では、ガンガン改善していくエンジニアを絶賛募集しています。
カジュアル面談やってるので、興味ありましたら応募宜しくお願いします！