Time-to-Interactive في تطوير التطبيقات: ما هي، المقياس والقياسات

ما هو Time-to-Interactive

Time-to-Interactive هو مقياس أداء يحدد اللحظة التي تصبح فيها الصفحة أو التطبيق جاهزاً للتفاعل الكامل مع المستخدم. في سياق الويب، يُعرّف TTI بأنه الوقت من بدء التصفح حتى اللحظة التي تتحقق فيها ثلاثة شروط: عرضت الصفحة محتوى مفيداً (First Contentful Paint)، وكان الخيط الرئيسي خالياً لمدة 5 ثوانٍ على الأقل، وتم تسجيل جميع مستمعي الأحداث. في تطبيقات الهاتف المحمول، TTI هو الوقت من بدء تشغيل النشاط حتى اكتمال تهيئة واجهة المستخدم بالكامل، عندما يتم تحميل جميع الحالات وتكوين الرسوم المتحركة ويمكن للمستخدم النقر على أي زر دون تأخير.

هذا المقياس مهم بشكل خاص للتطبيقات حيث يكون التفاعل الأول حاسماً — شاشات تسجيل الدخول والبحث وإتمام الطلب. إذا تجاوز TTI 5 ثوانٍ، يرى المستخدم التطبيق وكأنه «متجمد» وقد يغلقه. وفقاً لـ Google (تقرير Web Vitals، 2025)، تُظهر الصفحات التي يقل فيها TTI عن 3.8 ثوانٍ تحويلات أكثر بنسبة 24% مقارنة بالصفحات التي يزيد فيها TTI عن 7 ثوانٍ. يُلاحظ الفرق حتى عند 500 مللي ثانية — تظهر أبحاث Amazon خسارة 1% من الإيرادات لكل 100 مللي ثانية من التأخير.

كيف يُحسب TTI

تم تعريف خوارزمية حساب TTI في مواصفات W3C وتنفيذها في Lighthouse. يبدأ الحساب بـ First Contentful Paint (FCP) — لحظة عرض أول بكسل من المحتوى بواسطة المتصفح. ثم تبحث الخوارزمية عن «نافذة هدوء» — فترة زمنية مدتها 5 ثوانٍ لا تتجاوز خلالها أي مهمة في الخيط الرئيسي 50 مللي ثانية. يتم تعيين TTI عند آخر مهمة قبل هذه النافذة. إذا لم يتم العثور على نافذة هدوء خلال 15 ثانية، يتم تعيين TTI مساوياً لوقت آخر مهمة طويلة. تضمن هذه الخوارزمية أن يعكس TTI الاستعداد الفعلي للتفاعل، وليس مجرد لحظة العرض.

في تطبيقات الهاتف المحمول (Android/iOS)، لا يوجد معادل دقيق لمواصفات W3C، لكن المفهوم هو نفسه. يمكن قياس TTI عن طريق التقاط طابع زمني في onResume (بدء التشغيل) وفي رد اتصال الإطار الأول عند اكتمال جميع العمليات غير المتزامنة. يتيح Firebase Performance إنشاء تتبع مخصص مع بداية ونهاية جلسة التفاعل للمستخدم. على سبيل المثال، startTrace(“TTI”) في Application.onCreate و stopTrace() بعد تهيئة جميع حزم SDK وعرض الإطار الأول.

مثال على تتبع مخصص لـ TTI

يُظهر كود Kotlin قياس TTI باستخدام Firebase Performance. يبدأ التتبع في 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 — التأخير بين لمس الشاشة واستجابة واجهة المستخدم.

TTI في تطبيقات الهاتف المحمول

في تطبيقات الهاتف المحمول الأصلية، مفهوم TTI ليس موحداً كما هو الحال في الويب، لكن أهميته لا تقل. في Android، TTI هو الوقت من النقر على أيقونة التطبيق حتى اللحظة التي تصبح فيها واجهة المستخدم تفاعلية بالكامل: RecyclerView قابل للتمرير، الأزرار تستجيب للنقرات، الرسوم المتحركة تعمل بسلاسة. لقياس TTI في Android، يُستخدم مزيج من reportFullyDrawn (API 29+) و FrameMetricsAggregator. reportFullyDrawn هو استدعاء يقوم به التطبيق عندما يعتبر المطور أن واجهة المستخدم جاهزة. يلتقط النظام هذه اللحظة ويضمّنها في تقرير Android Vitals.

في iOS، معادلات TTI هي Time to First Frame و Time to Responsive. يجمع MetricKit بيانات وقت التشغيل مقسمة إلى مراحل — تحميل الملف التنفيذي، تهيئة الأطر، عرض الإطار الأول. توصي Apple ألا يتجاوز Time to First Frame 400 مللي ثانية، وأن يتم تحقيق التفاعل الكامل في غضون ثانيتين. إذا كان التطبيق يعرض شاشة عنصر نائب ثم يقوم بتحميل المحتوى، يُحسب TTI ليس من الإطار الأول بل من اللحظة التي يكون فيها المحتوى الفعلي جاهزاً للتفاعل.

قياس TTI في Android عبر FrameMetrics

يتتبع كود 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 مللي ثانية")
        metrics.reset()
    }
}

طرق تحسين TTI

يتضمن تحسين TTI ثلاثة اتجاهات: تقليل عبء العمل في الخيط الرئيسي، التحميل المؤجل للمكونات غير الحرجة، والعرض التدريجي. الاتجاه الأول هو تقليل العمليات المتزامنة: استبدال SharedPreferences بـ DataStore، نقل تهيئة SDK إلى خيط خلفي، التحميل البطيء لوحدات Dagger/Hilt. الثاني هو التحميل المؤجل: الشاشات غير المرئية عند بدء التشغيل (الأوراق السفلية، مربعات الحوار، الألسنة) يجب تهيئتها بعد الإطار الأول. الثالث هو العرض التدريجي: عرض شاشة هيكلية أولاً، ثم تحميل المحتوى على أجزاء.

في Android، طريقة فعالة هي استخدام مكتبة App Startup مع مهيآت مرتبة. على سبيل المثال، يمكن جعل مهيئ Firebase Analytics اختيارياً وتأخيره لمدة ثانيتين بعد بدء التشغيل. في iOS، المعادل هو Initialization Dependencies مع علامة lazy. للويب، الطرق الرئيسية هي تقسيم الحزمة (code splitting)، هز الشجرة (tree shaking)، التحميل المسبق/الربط المسبق للموارد الحرجة، و defer لـ JS غير المحظور. يقدم 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، تختلف حسب المنصة وعمق التحليل. على الويب، الأداة الرئيسية هي Lighthouse في Chrome DevTools. يقوم Lighthouse بتشغيل تدقيق ويعرض TTI بالمللي ثانية، بالإضافة إلى تقديم توصيات محددة للتحسين. للمراقبة المستمرة، يُستخدم PageSpeed Insights (Google) — يجمع البيانات من تقرير تجربة مستخدم Chrome (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–5 ثوانٍ — متوسط، > 5 ثوانٍ — حرج، لأن مستخدمي التطبيقات أقل تسامحاً مع التأخير.

تهيئة Lighthouse CI

مثال على تهيئة Lighthouse CI للتحقق التلقائي من TTI في خط أنابيب CI/CD. عند تجاوز عتبة 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
        }
    }
};