Time-to-Interactive mobil inkişafda: bu nədir, metrikası və ölçmələr

Time-to-Interactive nədir

Time-to-Interactive səhifə və ya tətbiqin istifadəçi ilə tam qarşılıqlı əlaqəyə hazır olduğu anı qeyd edən performans metrikasıdır. Veb kontekstində TTI naviqasiyanın başlanğıcından üç şərtin yerinə yetirildiyi ana qədər olan vaxt kimi təyin olunur: səhifə faydalı məzmun göstərdi (First Contentful Paint), əsas thread ən azı 5 saniyə sərbəst idi və bütün hadisə dinləyiciləri qeydiyyatdan keçdi. Mobil tətbiqlərdə TTI — bütün vəziyyətlərin yükləndiyi, animasiyaların qurulduğu və istifadəçinin heç bir gecikmə olmadan istənilən düyməni sıxa biləcəyi Activity-nin işə salınmasından UI-in tam inisializasiyasına qədər olan vaxtdır.

Metrika xüsusilə ilk qarşılıqlı əlaqənin kritik olduğu tətbiqlər üçün vacibdir — daxil olma ekranları, axtarış, sifariş vermə. Əgər TTI 5 saniyədən çox olarsa, istifadəçi tətbiqi “donanmış” kimi qəbul edir və onu bağlaya bilər. Google məlumatlarına görə (Web Vitals Report, 2025), TTI-si 3.8 saniyədən az olan səhifələr TTI-si 7 saniyədən çox olan səhifələrə nisbətən 24% daha çox konversiya göstərir. Fərq hətta 500 ms-də hiss olunur — Amazon tədqiqatları hər 100 ms gecikmə üçün gəlirin 1% itkisini göstərir.

TTI necə hesablanır

TTI hesablama alqoritmi W3C spesifikasiyasında müəyyən edilmiş və Lighthouse alətində tətbiq edilmişdir. Hesablama First Contentful Paint (FCP) — brauzerin məzmunun ilk pikselini göstərdiyi andan başlayır. Sonra alqoritm “səssizlik pəncərəsi” axtarır — əsas thread-də 50 ms-dən uzun tapşırıqların olmadığı 5 saniyəlik vaxt intervalı. TTI bu pəncərədən əvvəlki son tapşırıqda qeydə alınır. Əgər səssizlik pəncərəsi 15 saniyəyə qədər tapılmazsa, TTI son uzun tapşırığın vaxtına bərabər hesab olunur. Bu alqoritm TTI-nin sadəcə render anını deyil, qarşılıqlı əlaqəyə real hazırlığı əks etdirməsini təmin edir.

Mobil tətbiqlərdə (Android/iOS) W3C spesifikasiyasının dəqiq analoqu yoxdur, lakin konsepsiya eynidir. TTI onResume-da (başlanğıc vaxtı) və bütün asinxron əməliyyatlar tamamlandıqda ilk frame-in callbackində vaxt damğasını qeyd etməklə ölçülə bilər. Firebase Performance kitabxanası istifadəçinin interaktiv sessiyasının başlanğıcı və sonu ilə custom trace təyin etməyə imkan verir. Məsələn, Application.onCreate-də startTrace(”tti”) və bütün SDK-ların inisializasiyası və ilk frame-in renderi başa çatdıqdan sonra stopTrace().

TTI üçün custom trace nümunəsi

Kotlin kodu Firebase Performance vasitəsilə TTI ölçümünü nümayiş etdirir. Trace Application.onCreate-də başlayır və ilk reportFullyDrawn-dan sonra dayanır.

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 və FID: fərqlər

Core Web Vitals ekosistemində bir neçə metrika mövcuddur və TTI tez-tez First Contentful Paint (FCP) və Largest Contentful Paint (LCP) ilə qarışdırılır. FCP interaktivliyi zəmanət verməyən məzmunun ilk pikselinin göstərilmə vaxtıdır. LCP məzmunun ən böyük elementinin (şəkil, mətn bloku) göstərilmə vaxtıdır. TTI isə renderi deyil, qarşılıqlı əlaqəyə hazırlığı ölçür. Fərq kritikdir: FCP 1.2 saniyə ola bilər, lakin əsas thread JS paketinin yüklənməsi ilə bloklanıbsa, TTI 8 saniyəyə çata bilər.

First Input Delay (FID) istifadəçinin ilk hərəkəti ilə brauzerin hadisəni emal etməyə başladığı an arasındakı gecikməni ölçür. FID “interaktivlik keyfiyyəti”, TTI isə “interaktivliyə qədər olan vaxt”dır. TTI interfeysin neçə saniyədən sonra cavab verə biləcəyini göstərirsə, FID onun nə qədər cavab verə biləcəyini göstərir. Yaxşı TTI olmadan yaxşı FID mümkün deyil, çünki əsas thread bloklanıbsa, TTI yüksək olacaq və FID — istənilən qarşılıqlı əlaqə gecikəcək. Mobil tətbiqlərdə FID-in analoqu Touch Latency — ekrana toxunma və UI reaksiyası arasındakı gecikmədir.

Mobil tətbiqlərdə TTI

Yerli mobil tətbiqlərdə TTI konsepsiyası vebdəki qədər standartlaşdırılmayıb, lakin onun əhəmiyyəti az deyil. Android-də TTI tətbiq ikonasına klikdən UI-nin tam interaktiv olduğu ana qədər olan vaxtdır: RecyclerView sürüşür, düymələr toxunmalara reaksiya verir, animasiyalar problemsiz işləyir. Android-də TTI ölçmək üçün reportFullyDrawn (API 29+) və FrameMetricsAggregator birləşməsindən istifadə olunur. reportFullyDrawn — tətbiqin proqramçının UI-ni hazır hesab etdiyi anda etdiyi çağırışdır. Sistem bu anı qeyd edir və onu Android Vitals hesabatına daxil edir.

iOS-da TTI-nin analoqu Time to First Frame və Time to Responsive metrikalarıdır. MetricKit başlanğıc vaxtı haqqında məlumatları fazalara bölərək toplayır — icra olunan faylın yüklənməsi, freymvorkların inisializasiyası, ilk frame-in renderi. Apple tövsiyə edir ki, Time to First Frame 400 ms-dən çox olmasın və tam interaktivlik 2 saniyə ərzində əldə edilsin. Əgər tətbiq placeholder ekranı göstərib sonra məzmunu yükləyirsə, TTI ilk frame-ə görə deyil, real məzmunun qarşılıqlı əlaqəyə hazır olduğu ana görə hesablanır.

Android-də FrameMetrics vasitəsilə TTI ölçülməsi

Kotlin kodu FrameMetricsAggregator köməyi ilə ilk interaktiv frame-i izləyir. Callback istifadəçi tərəfindən başladılan ilk frame-in tamamlanmasından sonra işə düşür.

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", "İnteraktivliyə qədər vaxt: $ttiMs ms")
        metrics.reset()
    }
}

TTI optimallaşdırma metodları

TTI optimallaşdırması üç istiqaməti əhatə edir: əsas thread-də iş həcminin azaldılması, qeyri-kritik komponentlərin gecikməli yüklənməsi və proqressiv render. Birinci istiqamət — sinxron əməliyyatların minimuma endirilməsi: SharedPreferences-in DataStore ilə əvəz edilməsi, SDK inisializasiyasının fon thread-ə köçürülməsi, Dagger/Hilt modullarının lazy yüklənməsi. İkinci — gecikməli yükləmə: başlanğıcda görünməyən ekranlar (bottom sheets, dialoqlar, tablar) ilk frame-dən sonra inisializasiya edilməlidir. Üçüncü — proqressiv render: əvvəlcə skeleton ekran göstərilir, sonra məzmun hissə-hissə yüklənir.

Android-də effektiv metod — inisializatorların sıralanması ilə App Startup kitabxanasının istifadəsidir. Məsələn, Firebase Analytics inisializatoru istəyə bağlı edilə və onun icrası başlanğıcdan 2 saniyə gecikdirilə bilər. iOS-da analoq — lazy bayrağı ilə Initialization Dependencies-dir. Veb üçün əsas metodlar — code splitting (paketin bölünməsi), tree shaking (ölü kodun silinməsi), kritik resurslar üçün preload/preconnect və bloklamayan JS üçün defer-dir. Google Lighthouse konkret tövsiyələr verir: “Eliminate render-blocking resources” və “Defer offscreen images” birbaşa TTI-yə təsir edir.

React Native-də code splitting

React Native-də React.lazy və Suspense ilə paketin bölünməsi nümunəsi. HeavyScreen komponenti yalnız istifadəçi bu ekrana keçdikdə yüklənir və ilkin ekranın TTI-sini azaldır.

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

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

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

TTI ölçmə vasitələri

TTI ölçmək üçün platforma və analiz dərinliyinə görə fərqlənən bir neçə alət mövcuddur. Vebdə əsas alət Chrome DevTools-da Lighthouse-dur. Lighthouse audit işə salır və TTI-ni millisaniyələrlə göstərir, həmçinin yaxşılaşdırma üçün konkret tövsiyələr verir. Davamlı monitorinq üçün PageSpeed Insights (Google) istifadə olunur — real istifadəçilərdən Chrome User Experience Report (CrUX) məlumatlarını toplayır. Yerli tətbiqlərdə TTI Android Vitals (Google Play Console) və MetricKit (Apple) vasitəsilə ölçülür.

İstehsalat monitorinqi üçün Firebase Performance Monitoring (custom traces), Datadog RUM (Real User Monitoring) və Sentry Performance populyardır. Bu alətlər təkcə TTI-ni göstərmir, həm də TTI ilə biznes metrikaları — konversiya, itki, sessiya vaxtı arasında korrelyasiyanı izləməyə imkan verir. Hədd dəyərlərinin təyin edilməsi tövsiyə olunur: < 3.8 san — yaxşı, 3.8–7 san — yaxşılaşdırma tələb edir, > 7 san — kritik. Yerli tətbiqlər üçün həddlər daha sərtdir: < 2 san — yaxşı, 2–5 san — orta, > 5 san — kritik, çünki mobil tətbiq istifadəçiləri gecikmələrə daha az dözümlüdür.

Lighthouse CI konfiqurasiyası

CI/CD pipeline-da TTI-nin avtomatik yoxlanılması üçün Lighthouse CI konfiqurasiyası nümunəsi. 3.8 saniyə həddi aşıldıqda, qurğu xəbərdarlıqla qeyd olunur.

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