Time-to-Interactive mobil ishlanmada: bu nima, metriki va o'lchovlar

Time-to-Interactive nima

Time-to-Interactive — bu sahifa yoki ilova foydalanuvchi bilan to'liq o'zaro aloqaga tayyor bo'lgan paytni qayd etadigan ishlash metrikasi. Veb kontekstida TTI navigatsiya boshlanishidan uchta shart bajarilgan paytgacha bo'lgan vaqt sifatida aniqlanadi: sahifa foydali tarkibni ko'rsatdi (First Contentful Paint), asosiy ip kamida 5 soniya davomida bo'sh edi va barcha hodisa tinglovchilari ro'yxatdan o'tkazildi. Mobil ilovalarda TTI — Activity ishga tushirilishidan UI to'liq ishga tushirilgunga qadar bo'lgan vaqt, barcha holatlar yuklangan, animatsiyalar sozlangan va foydalanuvchi hech qanday kechikishsiz istalgan tugmani bosishi mumkin.

Metrika, ayniqsa, birinchi o'zaro aloqa muhim bo'lgan ilovalar uchun juda muhim — kirish ekranlari, qidiruv, buyurtma berish. Agar TTI 5 soniyadan oshsa, foydalanuvchi ilovani “muzlab qolgan” deb qabul qiladi va uni yopishi mumkin. Google ma'lumotlariga ko'ra (Web Vitals Report, 2025), TTI 3.8 soniyadan kam bo'lgan sahifalar TTI 7 soniyadan ko'p bo'lgan sahifalarga nisbatan 24% ko'proq konversiyani ko'rsatadi. Farq hatto 500 ms da ham seziladi — Amazon tadqiqotlari har 100 ms kechikish uchun daromadning 1% yo'qotilishini ko'rsatadi.

TTI qanday hisoblanadi

TTI hisoblash algoritmi W3C spetsifikatsiyasida aniqlangan va Lighthouse vositasida amalga oshirilgan. Hisoblash First Contentful Paint (FCP) — brauzer tarkibning birinchi pikselini ko'rsatgan paytdan boshlanadi. Keyin algoritm “jinchilik oynasi” ni qidiradi — asosiy ipda 50 ms dan uzoq vazifalar bo'lmagan 5 soniyalik vaqt oralig'i. TTI ushbu oynadan oldingi oxirgi vazifada qayd etiladi. Agar jinchilik oynasi 15 soniyagacha topilmasa, TTI oxirgi uzoq vazifaning vaqtiga teng deb hisoblanadi. Ushbu algoritm TTI faqat render paytini emas, balki o'zaro aloqaga haqiqiy tayyorlikni aks ettirishini kafolatlaydi.

Mobil ilovalarda (Android/iOS) W3C spetsifikatsiyasining aniq analogi yo'q, ammo kontseptsiya bir xil. TTI onResume da (ishga tushirish boshlanishi) va barcha asinxron operatsiyalar tugagach, birinchi kadrning callbackida vaqt tamg'asini qayd etish orqali o'lchanishi mumkin. Firebase Performance kutubxonasi foydalanuvchining interaktiv sessiyasining boshlanishi va tugashi bilan maxsus trace-ni belgilash imkonini beradi. Masalan, Application.onCreate da startTrace(”tti”) va barcha SDK larni ishga tushirish va birinchi kadr renderi tugagandan so'ng stopTrace().

TTI uchun maxsus trace namunasi

Kotlin tilidagi kod Firebase Performance orqali TTI o'lchashni ko'rsatadi. Trace Application.onCreate da boshlanadi va birinchi reportFullyDrawn dan keyin to'xtaydi.

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 va FID: farqlar

Core Web Vitals ekotizimida bir nechta metrikalar mavjud va TTI ko'pincha First Contentful Paint (FCP) va Largest Contentful Paint (LCP) bilan aralashtiriladi. FCP interaktivlikni kafolatlamaydigan tarkibning birinchi pikselini ko'rsatish vaqti. LCP tarkibning eng katta elementi (tasvir, matn bloki) ni ko'rsatish vaqti. TTI esa render emas, balki o'zaro aloqaga tayyorlikni o'lchaydi. Farq muhim: FCP 1.2 soniya bo'lishi mumkin, ammo asosiy ip JS paketini yuklash bilan bloklangan bo'lsa, TTI 8 soniyaga yetishi mumkin.

First Input Delay (FID) foydalanuvchining birinchi harakati bilan brauzer hodisani qayta ishlashni boshlagan payt o'rtasidagi kechikishni o'lchaydi. FID “interaktivlik sifati”, TTI esa “interaktivlikkacha bo'lgan vaqt” dir. Agar TTI interfeys necha soniyadan so'ng javob berishini ko'rsatsa, FID uning qanchalik javob berishini ko'rsatadi. Yaxshi TTIsiz yaxshi FID mumkin emas, chunki asosiy ip bloklangan bo'lsa, TTI yuqori bo'ladi va FID — har qanday o'zaro aloqa kechiktiriladi. Mobil ilovalarda FID ning analogi Touch Latency — ekranga tegish va UI reaksiyasi o'rtasidagi kechikish.

Mobil ilovalarda TTI

Mahalliy mobil ilovalarda TTI tushunchasi vebdagidek standartlashtirilmagan, ammo uning ahamiyati kam emas. Android da TTI ilova belgisini bosishdan UI to'liq interaktiv bo'lgunga qadar bo'lgan vaqt: RecyclerView aylanadi, tugmalar teginishlarga reaksiya beradi, animatsiyalar muammosiz ishlaydi. Android da TTI o'lchash uchun reportFullyDrawn (API 29+) va FrameMetricsAggregator kombinatsiyasi qo'llaniladi. reportFullyDrawn — bu dasturchi UI tayyor deb hisoblagan paytda ilova tomonidan amalga oshiriladigan chaqiruv. Tizim ushbu paytni qayd etadi va uni Android Vitals hisobotiga kiritadi.

iOS da TTI ning analogi Time to First Frame va Time to Responsive metrikalaridir. MetricKit ishga tushirish vaqti haqidagi ma'lumotlarni fazalarga bo'lib to'playdi — bajariladigan faylni yuklash, freymvorklarni ishga tushirish, birinchi kadrni render qilish. Apple Time to First Frame 400 ms dan oshmasligini va to'liq interaktivlik 2 soniya ichida erishilishini tavsiya qiladi. Agar ilova placeholder ekranini ko'rsatib, keyin tarkibni yuklasa, TTI birinchi kadr bo'yicha emas, balki haqiqiy tarkib o'zaro aloqaga tayyor bo'lgan payt bo'yicha hisoblanadi.

Android da FrameMetrics orqali TTI o'lchash

Kotlin tilidagi kod FrameMetricsAggregator yordamida birinchi interaktiv kadrni kuzatadi. Callback foydalanuvchi tomonidan boshlangan birinchi kadr tugagandan so'ng ishga tushadi.

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

TTI optimallashtirish usullari

TTI optimallashtirish uchta yo'nalishni o'z ichiga oladi: asosiy ipdagi ish hajmini kamaytirish, muhim bo'lmagan komponentlarni kechiktirib yuklash va progressiv render. Birinchi yo'nalish — sinxron operatsiyalarni minimallashtirish: SharedPreferences ni DataStore bilan almashtirish, SDK ishga tushirishni fon ipiga o'tkazish, Dagger/Hilt modullarini lazy yuklash. Ikkinchi — kechiktirilgan yuklash: ishga tushirishda ko'rinmaydigan ekranlar (bottom sheets, dialog oynalari, tablar) birinchi kadrdan keyin ishga tushirilishi kerak. Uchinchi — progressiv render: avval skeleton ekran ko'rsatiladi, keyin tarkib qismlarga bo'lib yuklanadi.

Android da samarali usul — ishga tushiruvchilarni tartiblash bilan App Startup kutubxonasidan foydalanish. Masalan, Firebase Analytics ishga tushiruvchisini ixtiyoriy qilish va uni ishga tushirishni 2 soniyaga kechiktirish mumkin. iOS da analog — lazy bayrog'i bilan Initialization Dependencies. Veb uchun asosiy usullar — code splitting (paketni bo'lish), tree shaking (o'lik kodni olib tashlash), muhim resurslar uchun preload/preconnect va bloklamaydigan JS uchun defer. Google Lighthouse aniq tavsiyalar beradi: “Eliminate render-blocking resources” va “Defer offscreen images” to'g'ridan-to'g'ri TTI ga ta'sir qiladi.

React Native da code splitting

React Native da React.lazy va Suspense yordamida paketni bo'lish namunasi. HeavyScreen komponenti faqat foydalanuvchi ushbu ekranga o'tganda yuklanadi va boshlang'ich ekranning TTI sini kamaytiradi.

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

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

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

TTI o'lchash vositalari

TTI o'lchash uchun platforma va tahlil chuqurligiga qarab farq qiluvchi bir nechta vositalar mavjud. Vebda asosiy vosita Chrome DevTools dagi Lighthouse dir. Lighthouse audit o'tkazadi va TTI ni millisekundlarda ko'rsatadi, shuningdek yaxshilash bo'yicha aniq tavsiyalar beradi. Doimiy monitoring uchun PageSpeed Insights (Google) ishlatiladi — u haqiqiy foydalanuvchilardan Chrome User Experience Report (CrUX) ma'lumotlarini to'playdi. Mahalliy ilovalarda TTI Android Vitals (Google Play Console) va MetricKit (Apple) orqali o'lchanadi.

Ishlab chiqarish monitoringi uchun Firebase Performance Monitoring (custom traces), Datadog RUM (Real User Monitoring) va Sentry Performance mashhur. Bu vositalar nafaqat TTI ni ko'rsatadi, balki TTI va biznes ko'rsatkichlari — konversiya, yo'qotish, sessiya vaqti o'rtasidagi korrelyatsiyani kuzatish imkonini beradi. Chegara qiymatlarini belgilash tavsiya etiladi: < 3.8 s — yaxshi, 3.8–7 s — yaxshilashni talab qiladi, > 7 s — muhim. Mahalliy ilovalar uchun chegaralar qattiqroq: < 2 s — yaxshi, 2–5 s — o'rtacha, > 5 s — muhim, chunki mobil ilova foydalanuvchilari kechikishlarga nisbatan kamroq bardoshlidir.

Lighthouse CI sozlamasi

CI/CD quvurida TTI ni avtomatik tekshirish uchun Lighthouse CI konfiguratsiyasi namunasi. 3.8 soniya chegarasi oshib ketganda, qurilish ogohlantirish bilan belgilanadi.

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