こんにちは、デジタルトランスフォーメーション（DX）事業本部のエンジニアの中嶋です。

概要

ヌリカエコラム記事の Pagespeed Insights のモバイルスコアを、20 点台から 65 点まで改善した過程と振り返りについて紹介します。

ヌリカエコラム記事

ヌリカエは、外壁塗装業者紹介サービスです。

ヌリカエコラム記事は、ヌリカエで一括見積もりされるユーザ向けに提供しているコンテンツです。専門知識を持つライターが、施工相場や塗装材の種類など、外壁塗装に特化した詳細なコンテンツを執筆しています。

記事例:

www.nuri-kae.jp

課題

そうした専門知識を持つライターが執筆した記事も、読みづらければユーザーが離脱してしまい、届けたい情報が届かないので意味がありません。

この読みやすさは、以下の 3 つの要素に分解できます。

段落構成
文章自体の読みやすさ（短文にする、など）
ページ速度

この内、このページ速度を計測できる代表的なツールの一つが、PageSpeed Insights です。

改善前の PageSpeed Insights のモバイルスコアは、20 点台とかなり低く、画像の表示速度が遅いなどユーザビリティ上の課題や、SEO 上の悪影響の懸念がありました。

PageSpeed Insights のスコア改善活動

目標

以下の目標を最初に立てました。目標がなければ何も始まりません。

SEO 流入数上位 10 記事*1の各 Pagespeed Insights のモバイルスコアの平均点 ≧ 65

「65 点」の根拠は、一休.com のホテルページのモバイルスコアです*2。一休.com を選んだのは、以下の記事のように、サイトスピードの改善に取り組んでいることが主な理由です。

ヌリカエコラム記事に比べて、コンテンツ量が多く、より複雑な一休.com で 65 点以上のスコアを叩き出しているのは、並大抵のことではないと思います。そうした一休.com をベンチマークにすることは、改善施策を考える上での参考になりました。

user-first.ikyu.co.jp

期間

およそ、3 週間の期間で取り組みを行いました。

施策

ここでは、実際に行った改善施策を紹介します。各施策での改善点数はモバイルの点数で、あくまで目安です。

JavaScript のレンダリングブロックの解消

script タグを可能な限り body 要素の最後に移動し、defer 属性を付与して、JavaScript の読み込みによってブラウザのレンダリングを止めないようにしました。

developers.google.com

また、使われていなかった Optimizely 用 script タグを削除しました。この施策で最大 20 点前後スコアが上昇しました。

オフスクリーン画像の遅延ロード

lozad.js でオフスクリーン画像（スクロールするまで見えない画像）が、スクロールで現れるまでロードを遅らせるようにしました。これによって、ファーストビューで読み込まれる画像枚数を大幅に減らすことができます。

apoorv.pro

この施策で 20 点前後スコアが上昇し、画像の多い記事でも安定して 60 点前後が出るようになりました。

Imgix による画像圧縮配信

Imgix は、画像の加工や最適化をリアルタイムで行い、加工済み画像を CDN で配信してくれる SaaS です。Imgix による画像圧縮配信によって、ファーストビューに含まれる画像と、遅延ロードされる画像の表示を高速化できます。

Imgix では、元画像を保存しているストレージ（AWS S3 バケットなど）を Source と呼び、Source の接続情報を Imgix に指定するだけで、画像を簡単に Imgix から配信できるようになります。

コラム記事の画像は、AWS S3 バケットに格納しているため、バケットの権限を持った IAM ユーザのアクセスキーを Imgix に指定するだけで、画像が配信できます。

S3 バケットをそのまま利用できる利点は、アップロード側を一切改修しなくて済むことです。画像圧縮をアップロード時に行うと、元画像と圧縮済み画像の両方を管理しなければならない上、画像のアップロードに時間がかかってしまいます。そうした管理上の手間や執筆者のユーザビリティを Imgix がよしなに解決してくれます。

国内の利用事例も多くあり、おすすめです。

made.livesense.co.jp user-first.ikyu.co.jp

この施策によって、5 点前後スコアが上昇しました。

不要な CSS の削除

使われていないスタイルを 30% 削減することで、2 〜 3 点スコアが上昇しました。

改善結果

結果、ヌリカエコラム記事の Pagespeed Insights のスコアを、20 点台から 65 点まで改善することができました!

Google Search Console 上からもモバイルのページ表示速度の改善が観測されました。

f:id:nyamadori:20191213002915p:plain — Google Search Console での変化

振り返り

結果について

ページ表示速度は、PageSpeed Insights のスコアが示すとおり、以前に比べて大幅に改善された
一方、ヌリカエコラム記事のようなシンプルな記事サイトにおいて、65 点は高くないスコアだと思う
- より複雑な一休.com が、70 点台にまで改善できているなら、感覚的には、ヌリカエコラム記事は 80 〜 90 点台まで改善できそう

他に考えられる施策

よりスコアを上げるには、以下の施策が考えられます。

レンダリングブロック CSS の削減
JavaScript の実行時間削減
サーバのレスポンススピード改善

他の施策を行う上での課題

レンダリングブロック CSS の削減
- Rails の Asset Pipeline 上で、レンダリングブロックすべき CSS とそうでない CSS をよしなに分離して、style タグを生成したいがどうすればよいか
  - よしなにできなくても、手動でならやれそうだが、今回はやりきれなかった
JavaScript の実行時間削減
- コラム記事に必要最小限の js だけロードするようにしたい
サーバのレスポンススピード改善
- 内製 CMS サービスと、ヌリカエ本体サイトサービス間の API レイテンシが存在する
  - 現状のスコアであれば、それほど目立ったレイテンシーはないが、90 点台まで目指すなら解決したい

進め方

やりきれていない部分は多いものの、施策の進め方については多くの収穫がありました。

何度も PageSpeed Insights を実行するのは面倒なので、スコアを自動で計測し、スコアの中央値を出すスクリプトを作った
- 改善活動の初期は、スコアがブレるため、施策に効果があったのか否かが分かりづらかった
  - はじめのうちは、何度か PageSpeed Insights を回して、スコアの最大値が上がれば改善されたとみなした
- 活動の初期から計測スクリプトを作っておけば、スコアの増減で悩むことは少なく済んだと思う
  - PageSpeed Insights は API があるので、それを使って計測スクリプトを作ることができる
    - 参考: PageSpeed Insights API を使ってみる | Google Developers
他社サイト（一休.com）を参考に、打つべき施策を絞り込めた
- 表示速度の改善記事は、様々な情報があり迷いがち
- 一定やりきっているサイトを参考にすることで、施策の迷いが減った
新規サービス（今回は Imgix）を使うときは、いち早く社内サービス利用申請を出す
- 各社実施状況は異なると思いますが、利用規約の法務チェックや、セキュリティチェックなど予想以上に時間がかかることがある
- 意外と忘れがちなクリティカルパスである

まとめ

今回の施策によって、ヌリカエコラム記事の Pagespeed Insights のモバイルスコアが、20 点台から 65 点まで改善した
- 施策ごとのポイント増加は以下のとおり（あくまで目安）
  - JavaScript のレンダリングブロックの解消 → +20 点
  - オフスクリーン画像の遅延ロード → +20 点
  - 不要な CSS の削除 → +2 〜 +3 点
  - Imgix による画像圧縮配信 → +5 点
その一方、やりきれていないところが多くあり、スコアは改善の余地がある
- 考えられる追加の施策や、追加施策の課題をあげた
施策の進め方については多くの収穫があった
- PageSpeed Insights のスコアを自動で計測するスクリプト
- 他社サイトを参考に打つべき施策を絞り込む
- 新規サービス（今回は Imgix）を使うときは、いち早く社内サービス利用申請を出す