موبائل ڈویلپمنٹ میں Time-to-Interactive: تعریف، میٹرک اور پیمائش

Time-to-Interactive کیا ہے

Time-to-Interactive ایک کارکردگی کا میٹرک ہے جو اس لمحے کو قید کرتا ہے جب کوئی صفحہ یا ایپلیکیشن صارف کے مکمل تعامل کے لیے تیار ہوتی ہے۔ ویب سیاق و سباق میں، TTI کو نیویگیشن کے آغاز سے اس لمحے تک کے وقت کے طور پر بیان کیا جاتا ہے جب تین شرائط پوری ہوتی ہیں: صفحہ نے مفید مواد ظاہر کیا (First Contentful Paint)، مرکزی تھریڈ کم از کم 5 سیکنڈ کے لیے غیر فعال رہا، اور تمام ایونٹ سننے والے رجسٹرڈ ہیں۔ موبائل ایپلیکیشنز میں، TTI Activity لانچ سے مکمل UI ابتدا تک کا وقت ہے، جب تمام حالتیں لوڈ ہو جاتی ہیں، اینیمیشنز ترتیب دی جاتی ہیں اور صارف بغیر تاخیر کے کسی بھی بٹن کو دبا سکتا ہے۔

یہ میٹرک خاص طور پر ان ایپلیکیشنز کے لیے اہم ہے جہاں پہلا تعامل اہم ہوتا ہے — لاگ ان اسکرینز، تلاش، چیک آؤٹ۔ اگر TTI 5 سیکنڈ سے تجاوز کر جائے تو صارف ایپ کو “منجمد” سمجھتا ہے اور اسے بند کر سکتا ہے۔ Google (Web Vitals Report، 2025) کے مطابق، 3.8 سیکنڈ سے کم TTI والے صفحات 7 سیکنڈ سے زیادہ TTI والے صفحات کے مقابلے میں 24% زیادہ تبدیلیاں دکھاتے ہیں۔ فرق 500 ms پر بھی محسوس ہوتا ہے — Amazon کی تحقیق ہر 100 ms تاخیر پر 1% آمدنی کے نقصان کو ظاہر کرتی ہے۔

TTI کا حساب کیسے لگایا جاتا ہے

TTI حساب الگورتھم W3C تصریح میں بیان کیا گیا ہے اور Lighthouse میں لاگو کیا گیا ہے۔ حساب First Contentful Paint (FCP) سے شروع ہوتا ہے — وہ لمحہ جب براؤزر مواد کا پہلا پکسل رینڈر کرتا ہے۔ پھر الگورتھم “خاموش ونڈو” تلاش کرتا ہے — 5 سیکنڈ کی مدت جس کے دوران مرکزی تھریڈ پر کوئی کام 50 ms سے زیادہ نہ ہو۔ 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 ms سے زیادہ نہ ہو اور مکمل انٹرایکٹیویٹی 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", "انٹرایکٹو ہونے کا وقت: $ttiMs ms")
        metrics.reset()
    }
}

TTI بہتری کے طریقے

TTI کی بہتری میں تین سمتیں شامل ہیں: مرکزی تھریڈ پر کام کا بوجھ کم کرنا، غیر اہم اجزاء کا تاخیری لوڈنگ، اور تدریجی رینڈرنگ۔ پہلی سمت ہم وقت کارروائیوں کو کم سے کم کرنا ہے: SharedPreferences کو DataStore سے تبدیل کرنا، SDK کی ابتدا کو پس منظر کے تھریڈ میں منتقل کرنا، Dagger/Hilt ماڈیولز کو سست لوڈ کرنا۔ دوسری تاخیری لوڈنگ ہے: شروع میں نظر نہ آنے والی اسکرینز (نیچے کی شیٹس، ڈائیلاگ، ٹیبز) پہلے فریم کے بعد شروع کی جانی چاہئیں۔ تیسری تدریجی رینڈرنگ ہے: پہلے ایک کنکال اسکرین دکھائیں، پھر مواد کو حصوں میں لوڈ کریں۔

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