Time-to-Interactive dalam pengembangan mobile: apa itu, metrik dan pengukuran

Apa itu Time-to-Interactive

Time-to-Interactive adalah metrik kinerja yang mencatat saat halaman atau aplikasi siap untuk interaksi penuh dengan pengguna. Dalam konteks web, TTI didefinisikan sebagai waktu dari awal navigasi hingga saat tiga kondisi terpenuhi: halaman telah menampilkan konten yang berguna (First Contentful Paint), thread utama telah bebas setidaknya selama 5 detik, dan semua pendengar peristiwa telah terdaftar. Dalam aplikasi seluler, TTI adalah waktu dari peluncuran Activity hingga inisialisasi UI selesai, ketika semua status dimuat, animasi dikonfigurasi, dan pengguna dapat menekan tombol apa pun tanpa penundaan.

Metrik ini sangat penting untuk aplikasi di mana interaksi pertama sangat kritis — layar masuk, pencarian, pemesanan. Jika TTI melebihi 5 detik, pengguna menganggap aplikasi “beku” dan dapat menutupnya. Menurut data Google (Web Vitals Report, 2025), halaman dengan TTI kurang dari 3,8 detik menunjukkan konversi 24% lebih banyak dibandingkan halaman dengan TTI lebih dari 7 detik. Perbedaan terasa bahkan pada 500 ms — penelitian Amazon menunjukkan kerugian pendapatan 1% untuk setiap 100 ms keterlambatan.

Bagaimana TTI dihitung

Algoritma perhitungan TTI didefinisikan dalam spesifikasi W3C dan diimplementasikan dalam alat Lighthouse. Perhitungan dimulai dengan First Contentful Paint (FCP) — saat browser merender piksel konten pertama. Kemudian algoritma mencari “jendela hening” — interval waktu 5 detik di mana tidak ada tugas yang lebih lama dari 50 ms di thread utama. TTI dicatat pada tugas terakhir sebelum jendela ini. Jika jendela hening tidak ditemukan hingga 15 detik, TTI dianggap sama dengan waktu tugas panjang terakhir. Algoritma ini memastikan bahwa TTI mencerminkan kesiapan nyata untuk interaksi, bukan hanya momen rendering.

Dalam aplikasi seluler (Android/iOS) tidak ada padanan yang tepat dari spesifikasi W3C, tetapi konsepnya sama. TTI dapat diukur dengan mencatat stempel waktu di onResume (awal peluncuran) dan di callback bingkai pertama ketika semua operasi asinkron selesai. Pustaka Firebase Performance memungkinkan penentuan trace khusus dengan awal dan akhir sesi interaktif pengguna. Misalnya, startTrace(”tti”) di Application.onCreate dan stopTrace() setelah inisialisasi semua SDK dan rendering bingkai pertama selesai.

Contoh trace khusus untuk TTI

Kode dalam Kotlin menunjukkan pengukuran TTI melalui Firebase Performance. Trace dimulai di Application.onCreate dan berhenti setelah reportFullyDrawn pertama.

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 dan FID: perbedaan

Dalam ekosistem Core Web Vitals ada beberapa metrik dan TTI sering disamakan dengan First Contentful Paint (FCP) dan Largest Contentful Paint (LCP). FCP adalah waktu rendering piksel konten pertama, yang tidak menjamin interaktivitas. LCP adalah waktu rendering elemen konten terbesar (gambar, blok teks). TTI mengukur bukan rendering, melainkan kesiapan untuk interaksi. Perbedaannya kritis: FCP mungkin 1,2 detik, tetapi jika thread utama diblokir oleh pemuatan bundel JS, TTI bisa mencapai 8 detik.

First Input Delay (FID) mengukur penundaan antara tindakan pertama pengguna dan saat browser mulai memproses peristiwa. FID adalah “kualitas interaktivitas”, sedangkan TTI adalah “waktu hingga interaktivitas”. Jika TTI menunjukkan setelah berapa detik antarmuka menjadi responsif, FID menunjukkan seberapa responsifnya. TTI yang baik tanpa FID yang baik tidak mungkin, karena jika thread utama diblokir, TTI akan tinggi dan FID — setiap interaksi akan tertunda. Dalam aplikasi seluler, padanan FID adalah Touch Latency — penundaan antara sentuhan layar dan reaksi UI.

TTI dalam aplikasi seluler

Dalam aplikasi seluler native, konsep TTI tidak se-standar di web, tetapi kepentingannya tidak kurang. Di Android, TTI adalah waktu dari klik ikon aplikasi hingga saat UI sepenuhnya interaktif: RecyclerView dapat digulir, tombol merespons sentuhan, animasi berjalan tanpa tersendat. Untuk mengukur TTI di Android digunakan kombinasi reportFullyDrawn (API 29+) dan FrameMetricsAggregator. reportFullyDrawn adalah panggilan yang dilakukan aplikasi pada saat pengembang menganggap UI siap. Sistem mencatat momen ini dan memasukkannya ke dalam laporan Android Vitals.

Di iOS, padanan TTI adalah metrik Time to First Frame dan Time to Responsive. MetricKit mengumpulkan data waktu peluncuran yang dipecah menjadi fase-fase — pemuatan file eksekusi, inisialisasi framework, rendering bingkai pertama. Apple merekomendasikan agar Time to First Frame tidak melebihi 400 ms dan interaktivitas penuh tercapai dalam 2 detik. Jika aplikasi menampilkan layar placeholder lalu memuat konten, TTI dihitung bukan dari bingkai pertama, tetapi dari saat konten nyata siap untuk interaksi.

Mengukur TTI di Android melalui FrameMetrics

Kode dalam Kotlin melacak bingkai interaktif pertama menggunakan FrameMetricsAggregator. Callback diaktifkan setelah bingkai pertama yang dimulai oleh pengguna selesai.

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", "Waktu hingga interaktivitas: $ttiMs ms")
        metrics.reset()
    }
}

Metode optimasi TTI

Optimasi TTI mencakup tiga arah: mengurangi beban kerja di thread utama, pemuatan tertunda komponen tidak kritis, dan rendering progresif. Arah pertama — minimalisasi operasi sinkron: mengganti SharedPreferences dengan DataStore, memindahkan inisialisasi SDK ke thread latar belakang, pemuatan malas modul Dagger/Hilt. Kedua — pemuatan tertunda: layar yang tidak terlihat saat startup (bottom sheets, dialog, tab) harus diinisialisasi setelah bingkai pertama. Ketiga — rendering progresif: pertama tampilkan layar kerangka, kemudian konten dimuat secara bertahap.

Di Android, metode yang efektif adalah menggunakan pustaka App Startup dengan peringkat inisialisator. Misalnya, inisialisator Firebase Analytics dapat dibuat opsional dan eksekusinya ditunda 2 detik setelah startup. Di iOS, padanannya adalah Initialization Dependencies dengan bendera lazy. Untuk web, metode utama adalah code splitting (pemisahan bundel), tree shaking (penghapusan kode mati), preload/preconnect untuk sumber daya kritis, dan defer untuk JS yang tidak memblokir. Google Lighthouse memberikan rekomendasi spesifik: “Eliminate render-blocking resources” dan “Defer offscreen images” secara langsung memengaruhi TTI.

Code splitting di React Native

Contoh pemisahan bundel di React Native menggunakan React.lazy dan Suspense. Komponen HeavyScreen hanya dimuat ketika pengguna menavigasi ke layar ini, mengurangi TTI layar awal.

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

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

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

Alat untuk mengukur TTI

Untuk mengukur TTI ada beberapa alat yang berbeda berdasarkan platform dan kedalaman analisis. Di web, alat utamanya adalah Lighthouse di Chrome DevTools. Lighthouse menjalankan audit dan menampilkan TTI dalam milidetik, serta memberikan rekomendasi spesifik untuk perbaikan. Untuk pemantauan berkelanjutan digunakan PageSpeed Insights (Google) — mengumpulkan data dari Chrome User Experience Report (CrUX) dari pengguna nyata. Dalam aplikasi native, TTI diukur melalui Android Vitals (Google Play Console) dan MetricKit (Apple).

Untuk pemantauan produksi, Firebase Performance Monitoring (custom traces), Datadog RUM (Real User Monitoring), dan Sentry Performance populer. Alat-alat ini tidak hanya menampilkan TTI, tetapi juga memungkinkan pelacakan korelasi antara TTI dan metrik bisnis — konversi, churn, durasi sesi. Disarankan untuk menetapkan nilai ambang: < 3,8 dtk — baik, 3,8–7 dtk — perlu perbaikan, > 7 dtk — kritis. Untuk aplikasi native, ambangnya lebih ketat: < 2 dtk — baik, 2–5 dtk — sedang, > 5 dtk — kritis, karena pengguna aplikasi seluler kurang toleran terhadap keterlambatan.

Konfigurasi Lighthouse CI

Contoh konfigurasi Lighthouse CI untuk pemeriksaan otomatis TTI di pipeline CI/CD. Jika ambang 3,8 detik terlampaui, build ditandai dengan peringatan.

// 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
        }
    }
};