すぐにできる！ au 無料ゲームにおけるフロントエンドパフォーマンス改善事例

はじめに

こんにちは、フロントエンドエンジニアの中畑 (@yn2011) です。

au Webポータル無料ゲームでは様々なフロントエンドのパフォーマンス最適化に取り組んでいます。今回は、既に実施した最適化の中から対応コストが小さく、効果が分かりやすかったものを中心に、対応事例のご紹介をします。

なお、au Webポータル無料ゲームは Jamstack 構成となっており、Next.js (SSG) とヘッドレスCMS を利用しております。詳細な技術スタックについてはヘッドレス CMS 運用におけるデプロイと環境差分についてに記載がありますので、ぜひこちらもご覧ください。

パフォーマンスの最適化を行う前の状態で、Lighthouse の測定結果は以下のようになっていました。

指標	指標の意味	結果
First Contentful Paint	テキストまたは画像が初めてペイントされるまでにかかった時間	2.3 秒
Speed Index	ページのコンテンツが取り込まれて表示される速さ	3.7 秒
Largest Contentful Paint	最も大きなテキストまたは画像が描画されるまでにかかった時間	9.1 秒
Time to Interactive	ページが完全に操作可能になるのに要する時間	8.9 秒
Total Blocking Time	タスクの処理時間が 50 ミリ秒を上回った場合の、コンテンツの初回描画から操作可能になるまでの合計時間	1,720 ミリ秒
Cumulative Layout Shift	ビューポート内の視覚要素がどのくらい移動しているか	0

測定結果を見ると、Largest Contentful Paint、Total Blocking Time は特に改善の余地がありそうでした。今回は、この測定結果を元に、実装コストが小さく・既存の機能に対する影響も小さいと判断した以下の 3 つの最適化についてご紹介します。

au Webポータル無料ゲームのトップページは以下のようになっており、画面の大部分をゲームタイトルのバナー（ピックアップバナー）が占めています。

トップページにアクセスした際に、ピックアップバナーの画像を優先的に読み込むことで Largest Contentful Paint の数値を改善しユーザが体験する画面表示までの速度を高めることができます。

実装としては、以下のような要素を HTML に追加するだけで実現可能です。

<link rel="preload" href="https://url-to-image" as="image" />

au Webポータル無料ゲームでは、広告の表示やデータ分析のために外部ドメインに対してリクエストを行います。

リクエスト先の外部ドメインが予め分かっている場合には、事前に DNS Lookup、Initial Connection、SSL を済ませておくことでリクエストが要求されてからレスポンスを得るまでの時間を短縮することができます。

実装としては、以下のような要素を追加するだけで実現可能です。

<link rel="preconnect" href="//other.domain.com" />

Chrome DevTools の Network タブを利用して確認すると、preconnect 指定前は以下であったのに対し

preconnect 指定後に確認すると、各フェーズに使用される時間が短くなりました。

なお、preconnect の他に、dns-prefetch を属性値として指定する方法もあります。両者の特徴を比較すると、preconnect の方が多くの処理を事前に行うことができる反面、ブラウザのサポート範囲は dns-prefetch よりは狭いです。

以下のようにフォールバックとして両方を指定することも可能なそうですが、WebKit では動作しないという報告がありました。

<link rel="dns-prefetch preconnect" href="//other.domain.com" />

preconnect は、あくまでパフォーマンス改善のための nice to have な対応であり一部ブラウザが対応していなくても動作自体に影響はないため preconncet のみを利用する判断をしました。

au Webポータル無料ゲームでは、A/B テストを実施するために、Google オプティマイズを利用しています。そのため、Google オプティマイズのスクリプトを必ず読み込んでいました。

<script src="https://www.googleoptimize.com/optimize.js?id=OPT_CONTAINER_ID" />

しかし、A/B テストは常に実施しているわけではないため A/B テストを実施していない期間については不要なリソースの読み込みとスクリプトの実行が発生してしまっていました。

au Webポータル無料ゲームは、Next.js の SSG を利用しているので、 A/B テストを実施していなければビルド時に Google オプティマイズのスクリプトタグを含めないように変更しました。

A/B テストを実施しているかの判定は、利用しているヘッドレスCMS に特定のレコードが存在するかどうかで行っています。

実装としては以下のように、_app.tsx の getInitialProps で判定を行い Props にフラグを追加しました。

static async getInitialProps() {
  ...
  return { pageProps: {}, isOptimizeRunning: !!config.experiments && config.experiments.length > 0 }
}

この isOptimizeRunning を利用し、レンダー時にスクリプトタグを含めるかどうかを決定します。

  {isOptimizeRunning && (
    <script src="https://www.googleoptimize.com/optimize.js?id=%24%7BOPT_CONTAINER_ID" />
  )}

以上の最適化を行い、Lighthouse を再実行すると測定結果は以下になりました。

指標	前	後	改善率(%)
First Contentful Paint	2.3 秒	1.3 秒	43.48
Speed Index	3.7 秒	3.0 秒	18.92
Largest Contentful Paint	9.1 秒	6.2 秒	31.87
Time to Interactive	8.9 秒	8.6 秒	3.37
Total Blocking Time	1,720 ミリ秒	1,550 ミリ秒	9.88
Cumulative Layout Shift	0	0	0.00

画面描画に関する指標（First Contentful Paint、Speed Index、Largest Contentful Paint）を中心に大きく数値が改善しました。トータルのスコア自体も 38 → 44 と上昇しました。

au Webポータル無料ゲームで実施したフロントエンドパフォーマンスの最適化についてご紹介しました。

個人的には、パフォーマンスの最適化というと難しそう、調査や実装に多くの時間が必要になりそう、といった先入観がありましたが、意外と簡単に実装できて成果に繋げられるものもあるんだな、という学びがありました。

今回ご紹介したものは、実際に取り組んだパフォーマンスの最適化の中の一部であり、実際にはもっと実装の変更が大きく、既存機能への影響を考慮しなけばならないものも多くありました。それらについては、また別の機会にお伝えできればと思います。

最後までお読み頂きありがとうございました。