Time-to-Interactive در توسعه موبایل: چیست، معیار و اندازه‌گیری‌ها

Time-to-Interactive چیست

Time-to-Interactive یک معیار عملکرد است که لحظه‌ای را ثبت می‌کند که صفحه یا برنامه برای تعامل کامل با کاربر آماده است. در زمینه وب، TTI به عنوان زمان از شروع ناوبری تا لحظه‌ای تعریف می‌شود که سه شرط برآورده می‌شوند: صفحه محتوای مفید را نمایش داده است (First Contentful Paint)، نخ اصلی حداقل به مدت ۵ ثانیه آزاد بوده و تمام شنوندگان رویداد ثبت شده‌اند. در برنامه‌های موبایل، TTI زمان از راه‌اندازی Activity تا مقداردهی اولیه کامل UI است، زمانی که همه حالت‌ها بارگذاری شده، انیمیشن‌ها تنظیم شده و کاربر می‌تواند بدون تأخیر روی هر دکمه‌ای کلیک کند.

این معیار به ویژه برای برنامه‌هایی که اولین تعامل در آنها حیاتی است مهم می‌باشد — صفحه‌های ورود، جستجو، ثبت سفارش. اگر TTI از ۵ ثانیه بیشتر شود، کاربر برنامه را «یخ‌زده» تلقی کرده و ممکن است آن را ببندد. طبق داده‌های Google (Web Vitals Report، 2025)، صفحاتی با TTI کمتر از ۳.۸ ثانیه ۲۴٪ تبدیل بیشتری نسبت به صفحاتی با TTI بیش از ۷ ثانیه نشان می‌دهند. تفاوت حتی در ۵۰۰ میلی‌ثانیه نیز قابل احساس است — تحقیقات Amazon کاهش ۱٪ درآمد به ازای هر ۱۰۰ میلی‌ثانیه تأخیر را نشان می‌دهد.

TTI چگونه محاسبه می‌شود

الگوریتم محاسبه TTI در مشخصات W3C تعریف شده و در ابزار Lighthouse پیاده‌سازی شده است. محاسبه با First Contentful Paint (FCP) — لحظه‌ای که مرورگر اولین پیکسل محتوا را رندر کرده است — آغاز می‌شود. سپس الگوریتم به دنبال «پنجره سکوت» می‌گردد — بازه زمانی ۵ ثانیه‌ای که در آن هیچ وظیفه‌ای طولانی‌تر از ۵۰ میلی‌ثانیه در نخ اصلی وجود نداشته باشد. TTI در آخرین وظیفه قبل از این پنجره ثبت می‌شود. اگر پنجره سکوت تا ۱۵ ثانیه پیدا نشود، TTI برابر با زمان آخرین وظیفه طولانی در نظر گرفته می‌شود. این الگوریتم تضمین می‌کند که TTI آمادگی واقعی برای تعامل را منعکس می‌کند، نه فقط لحظه رندر.

در برنامه‌های موبایل (Android/iOS) معادل دقیق مشخصات W3C وجود ندارد، اما مفهوم یکسان است. TTI را می‌توان با ثبت مهر زمانی در onResume (شروع راه‌اندازی) و در callback اولین فریم هنگامی که تمام عملیات‌های ناهمگام تکمیل شدند، اندازه‌گیری کرد. کتابخانه Firebase Performance امکان تعریف trace سفارشی با شروع و پایان جلسه تعاملی کاربر را فراهم می‌کند. به عنوان مثال، startTrace(«tti») در Application.onCreate و stopTrace() پس از اتمام مقداردهی اولیه تمام SDKها و رندر اولین فریم.

مثال trace سفارشی برای TTI

کد به زبان Kotlin اندازه‌گیری TTI را از طریق Firebase Performance نشان می‌دهد. Trace در 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 ممکن است ۱.۲ ثانیه باشد، اما اگر نخ اصلی با بارگذاری باندل JS مسدود شده باشد، TTI می‌تواند به ۸ ثانیه برسد.

First Input Delay (FID) تأخیر بین اولین اقدام کاربر و لحظه‌ای که مرورگر پردازش رویداد را آغاز کرده است را اندازه‌گیری می‌کند. FID «کیفیت تعامل‌پذیری» است، در حالی که TTI «زمان تا تعامل‌پذیری» است. اگر TTI نشان می‌دهد که رابط پس از چند ثانیه پاسخگو شده است، FID نشان می‌دهد که چقدر پاسخگو بوده است. TTI خوب بدون FID خوب غیرممکن است، زیرا اگر نخ اصلی مسدود شده باشد، TTI بالا خواهد بود و FID — هر تعاملی به تأخیر می‌افتد. در برنامه‌های موبایل، معادل FID Touch Latency — تأخیر بین لمس صفحه و واکنش UI است.

TTI در برنامه‌های موبایل

در برنامه‌های بومی موبایل، مفهوم TTI به اندازه وب استانداردسازی نشده است، اما اهمیت آن کمتر نیست. در Android، TTI زمان از کلیک روی آیکون برنامه تا لحظه‌ای است که UI کاملاً تعاملی است: RecyclerView اسکرول می‌شود، دکمه‌ها به لمس واکنش نشان می‌دهند، انیمیشن‌ها بدون لکنت کار می‌کنند. برای اندازه‌گیری TTI در Android از ترکیب reportFullyDrawn (API 29+) و FrameMetricsAggregator استفاده می‌شود. reportFullyDrawn فراخوانی است که برنامه در لحظه‌ای که توسعه‌دهنده UI را آماده می‌داند انجام می‌دهد. سیستم این لحظه را ثبت کرده و آن را در گزارش Android Vitals قرار می‌دهد.

در iOS معادل TTI معیارهای Time to First Frame و Time to Responsive هستند. MetricKit داده‌های زمان راه‌اندازی را با تفکیک فازها جمع‌آوری می‌کند — بارگذاری فایل اجرایی، مقداردهی اولیه فریمورک‌ها، رندر اولین فریم. Apple توصیه می‌کند که Time to First Frame از ۴۰۰ میلی‌ثانیه تجاوز نکند و تعامل‌پذیری کامل در عرض ۲ ثانیه حاصل شود. اگر برنامه یک صفحه placeholder نشان می‌دهد و سپس محتوا را بارگذاری می‌کند، TTI نه بر اساس اولین فریم، بلکه بر اساس لحظه‌ای که محتوای واقعی برای تعامل آماده است محاسبه می‌شود.

اندازه‌گیری TTI در Android از طریق FrameMetrics

کد به زبان Kotlin اولین فریم تعاملی را با FrameMetricsAggregator ردیابی می‌کند. Callback پس از اتمام اولین فریم آغاز شده توسط کاربر فعال می‌شود.

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", "زمان تا تعاملی: $ttiMs ms")
        metrics.reset()
    }
}

روش‌های بهینه‌سازی TTI

بهینه‌سازی TTI شامل سه جهت است: کاهش حجم کار در نخ اصلی، بارگذاری تأخیری مؤلفه‌های غیر بحرانی و رندر پیش‌رونده. جهت اول — به حداقل رساندن عملیات همزمان: جایگزینی SharedPreferences با DataStore، انتقال مقداردهی اولیه SDK به نخ پس‌زمینه، بارگذاری تنبل ماژول‌های Dagger/Hilt. دوم — بارگذاری تأخیری: صفحه‌هایی که در هنگام شروع قابل مشاهده نیستند (bottom sheets، دیالوگ‌ها، تب‌ها) باید بعد از اولین فریم مقداردهی اولیه شوند. سوم — رندر پیش‌رونده: ابتدا یک صفحه اسکلت نشان داده می‌شود، سپس محتوا به تدریج بارگذاری می‌شود.

در Android یک روش مؤثر استفاده از کتابخانه App Startup با رتبه‌بندی مقداردهی‌کننده‌ها است. به عنوان مثال، مقداردهی‌کننده Firebase Analytics را می‌توان اختیاری کرد و اجرای آن را ۲ ثانیه پس از شروع به تأخیر انداخت. در iOS معادل آن Initialization Dependencies با پرچم lazy است. برای وب، روش‌های کلیدی عبارتند از code splitting (تقسیم باندل)، tree shaking (حذف کد مرده)، preload/preconnect برای منابع حیاتی و defer برای JS غیرمسدودکننده. Google Lighthouse توصیه‌های مشخصی ارائه می‌دهد: «Eliminate render-blocking resources» و «Defer offscreen images» به طور مستقیم بر TTI تأثیر می‌گذارند.

Code splitting در 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 چندین ابزار وجود دارد که از نظر پلتفرم و عمق تحلیل متفاوت هستند. در وب، ابزار اصلی Lighthouse در Chrome DevTools است. Lighthouse یک ممیزی اجرا می‌کند و TTI را به میلی‌ثانیه نمایش می‌دهد و همچنین توصیه‌های مشخصی برای بهبود ارائه می‌دهد. برای نظارت مستمر از PageSpeed Insights (Google) استفاده می‌شود — داده‌های Chrome User Experience Report (CrUX) را از کاربران واقعی جمع‌آوری می‌کند. در برنامه‌های بومی، TTI از طریق Android Vitals (Google Play Console) و MetricKit (Apple) اندازه‌گیری می‌شود.

برای نظارت بر تولید، Firebase Performance Monitoring (custom traces)، Datadog RUM (Real User Monitoring) و Sentry Performance محبوب هستند. این ابزارها نه تنها TTI را نشان می‌دهند، بلکه امکان ردیابی همبستگی بین TTI و معیارهای تجاری — تبدیل، ریزش، زمان جلسه — را فراهم می‌کنند. توصیه می‌شود مقادیر آستانه تعیین شود: < ۳.۸ ثانیه — خوب، ۳.۸–۷ ثانیه — نیاز به بهبود دارد، > ۷ ثانیه — بحرانی. برای برنامه‌های بومی، آستانه‌ها سخت‌تر هستند: < ۲ ثانیه — خوب، ۲–۵ ثانیه — متوسط، > ۵ ثانیه — بحرانی، زیرا کاربران برنامه‌های موبایل نسبت به تأخیر تحمل کمتری دارند.

پیکربندی Lighthouse CI

مثال پیکربندی Lighthouse CI برای بررسی خودکار TTI در خط لوله CI/CD. در صورت تجاوز از آستانه ۳.۸ ثانیه، ساخت با اخطار علامت‌گذاری می‌شود.

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