弊社LPのパフォーマンス改善してみた

はじめまして、HRBrain新卒エンジニアの古山です。

私事ではありますが、肥大化しつつあった我が肉体が、最近では継続的な食事制限により萎縮してきた気がします（自称）。

さて、この記事では新卒エンジニアである僕が勉強の一環として取り組んだ 「Webサイトパフォーマンスの改善」に関して、ご紹介したいと思います。

サイトパフォーマンスを改善させようと思った訳

以前から弊社LPのパフォーマンスに関しては、課題感を持ちつつも優先度が低く、後回しにしていた結果

 ・　パフォーマンスの低さが体感できるほど表示速度が遅いと感じた
 ・　競合LPと弊社LPをPage Speed Insightというパフォーマンス解析ツールで定量的に比較して、圧倒的に下回ってる
 ・　サイトパフォーマンスによりSEO、CVRにも影響が出てくる

という課題を改めて認知したので、改善することになりました。

改善する前の弊社LPのパフォーマンス

他社のLPと比較（Page Speed Insight）すると

・A社
 - SP：34
 - PC：66

・B社
 - SP：21
 - PC：67

・C社
 - SP：36
 - PC：80

・D社
 - SP：32
 - PC：68

これに対して弊社LPは

・HRBrain LPパフォーマンス
 - SP：16
 - PC：29

SPパフォーマンス（改善前） f:id:furuyama_yuta:20190605192604p:plain PCパフォーマンス（改善前）

Oh....

Page Speed Insightにて計測

どこまでパフォーマンスを改善するか（目標）

今回新卒エンジニアの僕が勉強の一環として取り組んでいるので、「目指せパフォーマンス100点！」ではなく、この状況で現実的な目標設定として他社のパフォーマンスの平均値を目標値として設定しました。

・弊社LPパフォーマンス改善目標値
 - SP：30
 - PC：70

結論どこまでパフォーマンスが向上したか

パフォーマンス向上施策のご紹介の前に、「サイトパフォーマンス改善施策」を行って実際にどれほど弊社LPのパフォーマンスが改善されたのか...

SPパフォーマンス（改善後） f:id:furuyama_yuta:20190606140256p:plain

PCパフォーマンス（改善後） f:id:furuyama_yuta:20190606140318p:plain

PCは目標値まで達しず、まだまだ満足できる数値ではないですが、 SPが16→39、 PCが29→57 というように改善されました。

サイトパフォーマンスが低評価だった理由

・画像サイズが大きい
・画像遅延ロードを導入していなかったので初回レンダリングが遅かった
・日本語webフォントデータのサイズが膨大で読み込みが遅い

他にもサイトパフォーマンスが低評価だった理由は色々ありますが、上記3つの改善を行うだけでもパフォーマンスは改善されます。

実際に取り組んだサイトパフォーマンス改善施策

さて、どのような施策で弊社LPのパフォーマンスをSP：16→39、PC：29→57まで向上させたのかご紹介させていただきます。

1. 画像遅延ロード

まずが誰もが行っているであろう画像圧縮をTinyPNGというツールを利用して画像ファイルの圧縮を行いました。それでも対してパフォーマンスが改善されなかったので、画像遅延ロードを行いました。

画像遅延ロードとは、
通常ページ読み込み時に全ての画像を取りにいき、最低限の操作を受け付けるまで時間がかかります。
それに対して画像遅延ロードは必要に応じて必要な分だけのファイルを読み込みます（ページのスクロールに応じて随時必要な画像を取りに行く）。必要ではない画像（ページの下の方の画像など）の読み込みを後回しにして、画像以外のCSSやJSファイルの読み込みが先に行われます。
そうすることで、表示速度を速くすることができます。

弊社LPではFirstView以外の画像はほとんどvue-lazyload を導入し、遅延ロードを行っているので初回レンダリング速度を速くしております。

vue-lazyloadを導入して本ブログの画像を遅延ロードする

日本語Webフォントを制御する

webサイトをブラウザで表示し、テキストをレンダリングする過程にはフォントの読み込み作業が存在します。フォントを読み終えるまではテキストを表示させないという機能がブラウザには組み込まれています。

ここは日本なので日本語フォントを導入しているWebサイトが大多数だと思いますが、日本語フォントを導入する場合には注意が必要です。日本語フォントは外国語に比べ、漢字（一般的に使われない第2水準漢字含め）、ひらがな、カタカナが存在するのでフォントデータのサイズも膨大になります。その膨大なフォントデータをサーバから読み込ませるとなると、ページの読み込み時間が長くなり、ユーザにストレスを与えることになります。

そこでcssプロパティであるfont-displayを適応しました。これを利用すると「フォントが利用可能となるまでの間、テキストを表示するのかしないのか」を制御することができます。

font-displayの値

 - auto: デフォルト値。

 - swap: 即座に代替フォントを表示し、フォントのダウンロード完了後に切り替える

 - fallback: フォントがダウンロードできていないはじめのうちは代替えフォントで表示され、目的のフォントがダウンロードされ次第入れ替わる。しかし、ダウンロードに時間が掛かりすぎると代替えフォントの表示のままになる

 - optional: ほぼ代替えフォントでの表示になる。そのため目的のフォントのダウンロードさえもするかどうかはブラウザ次第

font-displayは以前までは下記のように@font-faceブロック内に記述する必要がありました。

@font-face{
  font-style: normal;
  font-weight: 400;
  font-display: swap;  
}

しかし、2019/5/21にGoogle Fonts公式アカウントにて、Google Fontsが font-display: swap に対応することが正式に発表されました。

Web developers! Now you can specify the font-display property that you want for your Google Fonts - so you can make text appear faster, or not display until the font has loaded...

Eg https://t.co/KPgqpIEisB

Docs https://t.co/hHkJ0Gy7a8

Playground https://t.co/YZWRSDj1TV
— Google Fonts (@googlefonts) 2019年5月20日

ついに公式機能として font-display: swap がサポートされるようになったので、使い方も簡単です。 Google FontsのCSSを読み込んでいるlinkタグのhref属性の末尾に「&display=swap」を加えるだけです。

<link href="https://fonts.googleapis.com/css?family=Noto+Sans+JP&display=swap" rel="stylesheet">

ここは日本なので日本語webフォントを使用しているwebサイトが大多数だと思います。日本語フォントを使っていてもOSに組み込まれているFont使っている場合は問題にはなりませんが、 GoogleWebFontなどサーバから日本語フォントを読み込む場合はサイトにアクセスしてきたユーザーにストレスを与えないために、このfont-displayプロパティは大いに役に立つ存在になるはずです。

最後に

サイトパフォーマンスの最適化は、SEOによる集客面でも、CVR向上の面でも非常に重要なポイントです。サイトにアクセスしたユーザがより快適にサイトを扱えるように今回ご紹介した施策を最低限やってみてもいいかもしれません。

今回は弊社LPで取り組んだ「サイトパフォーマンス改善施策」のうち

・画像圧縮、画像遅延読み込み
・日本語webフォントの制御

についてご紹介させていただきました。

今回残念ながらPCパフォーマンスが目標値に達しませんでしたが、ユーザがより快適にサイトを扱えるように日々サイトパフォーマンス改善施策を実行していこうと思います。