モバイル開発におけるTime-to-Interactive：定義、指標、測定

Time-to-Interactiveとは

Time-to-Interactiveは、ページやアプリケーションがユーザーの完全なインタラクションに備えられる瞬間を捉えるパフォーマンス指標です。ウェブのコンテキストでは、TTIはナビゲーション開始から3つの条件が満たされるまでの時間として定義されます：ページが有用なコンテンツを表示した（First Contentful Paint）、メインスレッドが少なくとも5秒間アイドル状態であった、すべてのイベントリスナーが登録された。モバイルアプリケーションでは、TTIはアクティビティ起動からUIの初期化が完了するまでの時間であり、すべての状態が読み込まれ、アニメーションが設定され、ユーザーが遅延なく任意のボタンをタップできるようになります。

この指標は、最初のインタラクションが重要であるアプリケーション（ログイン画面、検索、チェックアウト）にとって特に重要です。TTIが5秒を超えると、ユーザーはアプリを「フリーズした」と認識し、閉じてしまう可能性があります。Google（Web Vitals Report、2025）によると、TTIが3.8秒未満のページは、TTIが7秒を超えるページよりも24%多くのコンバージョンを示しています。その差は500ミリ秒でも感じられます。Amazonの調査では、100ミリ秒の遅延ごとに1%の収益損失が生じることが示されています。

TTIの計算方法

TTIの計算アルゴリズムはW3C仕様で定義され、Lighthouseに実装されています。計算はFirst Contentful Paint（FCP）から始まります。これは、ブラウザがコンテンツの最初のピクセルをレンダリングする瞬間です。次に、アルゴリズムは「静寂ウィンドウ」を探します。これは、メインスレッドで50ミリ秒を超えるタスクがない5秒間の期間です。TTIは、このウィンドウの前の最後のタスクに設定されます。15秒以内に静寂ウィンドウが見つからない場合、TTIは最後の長時間タスクの時間に設定されます。このアルゴリズムにより、TTIはレンダリングの瞬間だけでなく、インタラクションに対する実際の準備状態を反映することが保証されます。

モバイルアプリケーション（Android/iOS）には、W3C仕様の正確な同等物はありませんが、概念は同じです。TTIは、onResume（起動開始）と、すべての非同期操作が完了した最初のフレームのコールバックでタイムスタンプをキャプチャすることで測定できます。Firebase Performanceを使用すると、ユーザーのインタラクティブセッションの開始と終了を含むカスタムトレースを設定できます。たとえば、Application.onCreateでstartTrace(“TTI”)を呼び出し、すべてのSDKが初期化されて最初のフレームがレンダリングされた後にstopTrace()を呼び出します。

TTIのカスタムトレース例

Kotlinコードは、Firebase Performanceを使用したTTI測定を示しています。トレースはApplication.onCreateで開始され、最初のreportFullyDrawnの後に停止します。

class App : Application() {

    private var ttiTrace: Trace? = null

    override fun onCreate() {
        super.onCreate()
        ttiTrace = Firebase.performance
            .newTrace("tti")
        ttiTrace?.start()
    }

    fun stopTtiTrace() {
        ttiTrace?.stop()
        ttiTrace = null
    }
}

TTI、FCP、LCP、FIDの違い

Core Web Vitalsエコシステムにはいくつかの指標があり、TTIはFirst Contentful Paint（FCP）やLargest Contentful Paint（LCP）と混同されることがよくあります。FCPはコンテンツの最初のピクセルがレンダリングされる時間であり、インタラクティブ性を保証するものではありません。LCPは最大のコンテンツ要素（画像、テキストブロック）のレンダリング時間です。しかし、TTIはレンダリングではなく、インタラクションへの準備状態を測定します。その違いは重要です。FCPは1.2秒でも、メインスレッドがJSバンドルの読み込みでブロックされている場合、TTIは8秒に達する可能性があります。

First Input Delay（FID）は、ユーザーの最初のアクションからブラウザがイベント処理を開始するまでの遅延を測定します。FIDは「インタラクティブ性の品質」であり、TTIは「インタラクティブ性までの時間」です。TTIがインターフェースが応答するまでの秒数を示すのに対し、FIDはその応答性の度合いを示します。メインスレッドがブロックされている場合、TTIは高くなり、FIDはあらゆるインタラクションを遅延させるため、良好なTTIは良好なFIDなしでは不可能です。モバイルアプリケーションでは、FIDの同等物はTouch Latency（タッチレイテンシ）です。これは、画面をタッチしてからUIが応答するまでの遅延です。

モバイルアプリケーションにおけるTTI

ネイティブモバイルアプリケーションでは、TTIの概念はウェブほど標準化されていませんが、その重要性は変わりません。Androidでは、TTIはアプリアイコンをタップしてからUIが完全にインタラクティブになるまでの時間です：RecyclerViewがスクロールし、ボタンがタップに反応し、アニメーションがスムーズに動作します。AndroidでTTIを測定するには、reportFullyDrawn（API 29+）とFrameMetricsAggregatorの組み合わせを使用します。reportFullyDrawnは、開発者がUIの準備ができたと判断したときにアプリが行う呼び出しです。システムはこの瞬間をキャプチャし、Android Vitalsレポートに含めます。

iOSでは、TTIの同等物はTime to First FrameとTime to Responsiveです。MetricKitは、実行可能ファイルの読み込み、フレームワークの初期化、最初のフレームのレンダリングといったフェーズに分割された起動時間データを収集します。Appleは、Time to First Frameが400ミリ秒を超えず、完全なインタラクティブ性が2秒以内に達成されることを推奨しています。アプリがプレースホルダー画面を表示してからコンテンツを読み込む場合、TTIは最初のフレームからではなく、実際のコンテンツがインタラクションの準備できた時点から計算されます。

FrameMetricsを使用したAndroidでのTTI測定

Kotlinコードは、FrameMetricsAggregatorを使用して最初のインタラクティブフレームを追跡します。ユーザーが開始した最初のフレームが完了すると、コールバックが起動されます。

class TtiTracker(private val activity: Activity) {

    private val metrics = FrameMetricsAggregator()
    private var startTime = 0L

    fun onStart() {
        startTime = System.nanoTime()
        metrics.add(activity.window)
    }

    fun onFirstFrame() {
        val ttiMs = (System.nanoTime() - startTime) / 1_000_000
        Log.d("TTI", "Time to Interactive: $ttiMs ms")
        metrics.reset()
    }
}

TTI最適化の方法

TTIの最適化には、メインスレッドの負荷軽減、非クリティカルコンポーネントの遅延読み込み、プログレッシブレンダリングの3つの方向性があります。最初の方向性は、同期操作の最小化です：SharedPreferencesをDataStoreに置き換え、SDKの初期化をバックグラウンドスレッドに移動し、Dagger/Hiltモジュールを遅延読み込みします。2つ目は遅延読み込みです：起動時に表示されない画面（ボトムシート、ダイアログ、タブ）は、最初のフレームの後に初期化する必要があります。3つ目はプログレッシブレンダリングです：最初にスケルトン画面を表示し、その後コンテンツを部分的に読み込みます。

Androidでは、ランク付けされたイニシャライザを持つApp Startupライブラリを使用することが効果的な方法です。たとえば、Firebase Analyticsのイニシャライザをオプションにして、起動後2秒遅らせることができます。iOSでは、同等のものはlazyフラグを使用したInitialization Dependenciesです。ウェブの場合、主要な方法はコード分割、ツリーシェイキング、クリティカルリソースのプリロード/プリコネクト、ノンブロッキングJSのためのdeferです。Google Lighthouseは具体的な推奨事項を提供します：「Eliminate render-blocking resources」と「Defer offscreen images」はTTIに直接影響します。

React Nativeでのコード分割

React NativeでReact.lazyとSuspenseを使用したバンドル分割の例。HeavyScreenコンポーネントは、ユーザーがその画面に移動したときにのみ読み込まれ、初期画面のTTIを低減します。

import React, { lazy, Suspense } from 'react';

const HeavyScreen = lazy(() =>
    import('./screens/HeavyScreen')
);

const App = () => (
    <Suspense fallback={<Loading />}>
        <HeavyScreen />
    </Suspense>
);

TTI測定ツール

TTIを測定するためのツールはいくつかあり、プラットフォームや分析の深度によって異なります。ウェブでは、主要なツールはChrome DevToolsのLighthouseです。Lighthouseは監査を実行し、TTIをミリ秒単位で出力するとともに、改善のための具体的な推奨事項を提供します。継続的なモニタリングには、PageSpeed Insights（Google）を使用します。これは、実際のユーザーからのChrome User Experience Report（CrUX）のデータを収集します。ネイティブアプリでは、TTIはAndroid Vitals（Google Play Console）とMetricKit（Apple）を介して測定されます。

プロダクションモニタリングには、Firebase Performance Monitoring（カスタムトレース）、Datadog RUM（リアルユーザーモニタリング）、Sentry Performanceなどの人気ツールがあります。これらのツールはTTIを表示するだけでなく、TTIとコンバージョン、離脱、セッション時間などのビジネス指標との相関関係を追跡することもできます。推奨しきい値：< 3.8秒 — 良好、3.8～7秒 — 改善が必要、> 7秒 — 重大。ネイティブアプリの場合、しきい値はより厳格です：< 2秒 — 良好、2～5秒 — 平均、> 5秒 — 重大。モバイルアプリユーザーは遅延に対する許容度が低いためです。

Lighthouse CIの設定

CI/CDパイプラインで自動的にTTIをチェックするためのLighthouse CI設定の例。3.8秒のしきい値を超えた場合、ビルドは警告付きでマークされます。

// lighthouserc.js
module.exports = {
    ci: {
        assert: {
            assertions: {
                'interactive': ['warn', {
                    maxNumericValue: 3800
                }],
                'first-contentful-paint': ['error', {
                    maxNumericValue: 1800
                }]
            }
        },
        collect: {
            startServerCommand: 'npm start',
            url: ['http://localhost:3000'],
            numberOfRuns: 3
        }
    }
};