この記事は、Advent Calendar 24日目の記事です。
イブですねイブ！！
Introduction
僕ら Wantedly のエンジニアは、12/21日、12/22日に開発合宿をしてきました！
今回の合宿の目標は「Wantedly 全体を20%スピードアップ」する事で、当初はかなり厳しい目標だと感じましたが、午前 6:00 までの不眠不休での頑張りにより、 28% のスピードアップに成功しました！！
アプローチ
アプローチはシンプルで、NewRelic でサイト全体のパフォーマンスを確認して、ボトルネックを徹底的に潰しました。
Wantedly においては、募集を閲覧する画面である projects/:project_id へのリクエストが圧倒的に多く、サイト全体の 58% の時間が募集閲覧画面で使われていました。そこでまずは projects/:project_id に狙いを定めて、徹底的な高速化をおこなしました。
募集閲覧画面の高速化
募集閲覧画面を見たときに、まず気になったのはロードする JavaScript のサイズでした。Wantedly では共通で使われる JavaScript コードは出来るだけ結合して1つのファイルにして、ページを遷移した際にも同じ JavaScript を使う事でキャッシュにヒットさせる事を狙っていました。
しかし、 projects/:project_id のページ単体で見ると不要な JavaScript コードも多く含まれていた事、さらには projects/:project_id に関しては Facebook へのシェアなどで直接訪問するユーザーも多かった事から、必要な JavaScript コードに絞って読み込む事で、JavaScript の読み込みや実行にかかる時間を極力抑えるようにしました。
また、一部のコードにおいて script タグが html の途中で読み込まれて DOM の render がブロックされている箇所があったので、それも 最後に JavaScript を読み込む ベストプラクティスに全てのページが強制的に従う仕組みを作りました。
募集ウィジェットの高速化
NewRelic でパフォーマンスを見ていて気付いたのが、「募集ウィジェットへのリクエスト」が極めて多い事でした。様々な箇所で募集ウィジェットの読み込みが行われている為、1つ1つの response は早いものの積み重なってサイト全体に対して大きな影響を持っていました。
募集ウィジェットについては、リソースを出来るだけ削除するアプローチをとりました。もともとは JavaScript で表現していた AutoLayout を css だけで表現する様に書き換えて、さらに css もサーバーサイドでレンダリングする html 内に style タグとして直接書き込むことで、css のリクエストを減らしました。
結果、元々高速なページでありながら、3分の1以下に DOMContentsLoaded time を削減する事が出来ました。
まとめ
ボトルネックをきちんと把握してパフォーマンス向上対象を狙い撃ちする事で、劇的な高速化を達成できました。
アプローチ自体はありきたりなシンプルなものであるものの、きちんとボトルネックを捉える事の重要性を感じた 2日間でした。