hikoharu's blog

エンジニアリング、プロダクトについて考えていること。twitter: @hikoharu06

GTmetrix使ってサイトのパフォーマンス改善した

これは何

ブラウザアプリをGTmetrixというサイトのパフォーマンス計測するサービス使って、速度面でのボトルネックを特定して解決した話

https://gtmetrix.com/

そもそもなぜやろうと思ったか

最近、SEOやらコンテンツマーケティングやらに興味が出てきて、グロースハック的なmeetupに行っている。 その中である人が、「グロースハックには色々施策あるけど、一番コスパのいい施策は速度改善」と言っていたのが印象的だった。 実際に自分がプロダクトオーナーやっているサービスで試してみた

実際やってみた

これが最初に計測した時

f:id:hikoharu06:20180802160803p:plain

屈辱のF評価。。。。 どの項目が悪いか調べると

  • Serve scaled images: 必要以上に大きい画像を用意して、cssでサイズ調整している

  • Enable gzip compression: gzip圧縮を使っていない

  • Leverage browser caching: ブラウザキャッシュが有効になっていない

が問題なのがわかる。

なので、それぞれ

  • Serve scaled images: 画像のサイズ調整

  • Enable gzip compression: nginxでcss,javascriptgzipするようにnginx.conf設定変更

  • Leverage browser caching: nginxで静的ファイルを30日間ブラウザキャッシュするようにnginx.conf変更(ブラウザキャッシュはブラウザ側の設定だけだと思っていたので、nginxにも設定あるの初めて知った)

結果が

f:id:hikoharu06:20180802160742p:plain

喜びのA評価!!

まとめ

まだサービスが動くようになってから、数ヶ月ということもあり2〜3時間程度で対応できた。nginx周りで少し詰まったので、知識ある人なら1時間以内とかでできると思う ただこれが1年運用したとかになると、膨大な修正を入れなければならず、永遠塩漬けになる未来が見える。。。

持論だけど速度改善(にとどまらず改善系全般)は担当者がちょっと手が空いた2時間くらいで「やってみるか」という状態にいかに保つことが重要だと思う。

  • マメにリファインメントして、課題の粒度を細かくしておく
  • 計測方法、修正方法の確立
  • チームの文化(空いたらその分機能開発ではなく、改善に力を注ぐ)

のを常に実行しようというのが改めて身にしみた