Time-to-Interactive στην ανάπτυξη εφαρμογών για κινητά: τι είναι, μετρική και μετρήσεις

Τι είναι το Time-to-Interactive

Time-to-Interactive είναι μια μετρική απόδοσης που καταγράφει τη στιγμή κατά την οποία η σελίδα ή η εφαρμογή είναι έτοιμη για πλήρη αλληλεπίδραση με τον χρήστη. Στο πλαίσιο του ιστού, το TTI ορίζεται ως ο χρόνος από την έναρξη της πλοήγησης έως τη στιγμή που πληρούνται τρεις προϋποθέσεις: η σελίδα εμφάνισε χρήσιμο περιεχόμενο (First Contentful Paint), το κύριο νήμα ήταν ελεύθερο για τουλάχιστον 5 δευτερόλεπτα και όλοι οι ακροατές συμβάντων έχουν καταχωρηθεί. Στις εφαρμογές για κινητά, το TTI είναι ο χρόνος από την εκκίνηση μιας Activity έως την πλήρη αρχικοποίηση του UI, όταν όλες οι καταστάσεις έχουν φορτωθεί, οι κινούμενες εικόνες έχουν ρυθμιστεί και ο χρήστης μπορεί να κάνει κλικ σε οποιοδήποτε κουμπί χωρίς καθυστέρηση.

Η μετρική είναι ιδιαίτερα σημαντική για εφαρμογές όπου η πρώτη αλληλεπίδραση είναι κρίσιμη — οθόνες σύνδεσης, αναζήτησης, υποβολής παραγγελίας. Εάν το TTI υπερβαίνει τα 5 δευτερόλεπτα, ο χρήστης αντιλαμβάνεται την εφαρμογή ως “παγωμένη” και μπορεί να την κλείσει. Σύμφωνα με τα δεδομένα της Google (Web Vitals Report, 2025), οι σελίδες με TTI μικρότερο από 3.8 δευτερόλεπτα εμφανίζουν 24% περισσότερες μετατροπές από σελίδες με TTI μεγαλύτερο από 7 δευτερόλεπτα. Η διαφορά γίνεται αισθητή ακόμη και στα 500 ms — οι έρευνες της Amazon δείχνουν απώλεια εσόδων 1% για κάθε 100 ms καθυστέρησης.

Πώς υπολογίζεται το TTI

Ο αλγόριθμος υπολογισμού του TTI ορίζεται στην προδιαγραφή W3C και υλοποιείται στο εργαλείο Lighthouse. Ο υπολογισμός ξεκινά με το First Contentful Paint (FCP) — τη στιγμή που το πρόγραμμα περιήγησης απέδωσε το πρώτο εικονοστοιχείο περιεχομένου. Στη συνέχεια, ο αλγόριθμος αναζητά ένα “παράθυρο σιωπής” — ένα χρονικό διάστημα 5 δευτερολέπτων κατά το οποίο δεν υπήρχαν εργασίες μεγαλύτερες από 50 ms στο κύριο νήμα. Το TTI καταγράφεται στην τελευταία εργασία πριν από αυτό το παράθυρο. Εάν το παράθυρο σιωπής δεν βρεθεί εντός 15 δευτερολέπτων, το TTI θεωρείται ίσο με τον χρόνο της τελευταίας μεγάλης εργασίας. Αυτός ο αλγόριθμος εγγυάται ότι το TTI αντικατοπτρίζει την πραγματική ετοιμότητα για αλληλεπίδραση, όχι μόνο τη στιγμή της απόδοσης.

Στις εφαρμογές για κινητά (Android/iOS) δεν υπάρχει ακριβές αντίστοιχο της προδιαγραφής W3C, αλλά η ιδέα είναι η ίδια. Το TTI μπορεί να μετρηθεί καταγράφοντας μια χρονική σφραγίδα στο onResume (έναρξη εκκίνησης) και στην επιστροφή κλήσης του πρώτου καρέ, όταν όλες οι ασύγχρονες λειτουργίες έχουν ολοκληρωθεί. Η βιβλιοθήκη 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 μπορεί να είναι 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 κυλά, τα κουμπιά αντιδρούν στο άγγιγμα, οι κινούμενες εικόνες λειτουργούν χωρίς τραυλισμό. Για τη μέτρηση του 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 να μην υπερβαίνει τα 400 ms και η πλήρης διαδραστικότητα να επιτυγχάνεται εντός 2 δευτερολέπτων. Εάν η εφαρμογή εμφανίζει μια οθόνη placeholder και στη συνέχεια φορτώνει περιεχόμενο, το 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 ms")
        metrics.reset()
    }
}

Μέθοδοι βελτιστοποίησης TTI

Η βελτιστοποίηση του TTI περιλαμβάνει τρεις κατευθύνσεις: μείωση του όγκου εργασίας στο κύριο νήμα, καθυστερημένη φόρτωση μη κρίσιμων στοιχείων και προοδευτική απόδοση. Η πρώτη κατεύθυνση — ελαχιστοποίηση σύγχρονων λειτουργιών: αντικατάσταση SharedPreferences με DataStore, μεταφορά αρχικοποίησης SDK σε νήμα παρασκηνίου, τεμπέλικη φόρτωση αρθρωμάτων Dagger/Hilt. Η δεύτερη — καθυστερημένη φόρτωση: οθόνες που δεν είναι ορατές κατά την εκκίνηση (bottom sheets, παράθυρα διαλόγου, καρτέλες) θα πρέπει να αρχικοποιούνται μετά το πρώτο καρέ. Η τρίτη — προοδευτική απόδοση: πρώτα εμφανίζεται μια οθόνη σκελετού, στη συνέχεια το περιεχόμενο φορτώνεται σταδιακά.

Στο Android, μια αποτελεσματική μέθοδος είναι η χρήση της βιβλιοθήκης App Startup με κατάταξη αρχικοποιητών. Για παράδειγμα, ο αρχικοποιητής Firebase Analytics μπορεί να γίνει προαιρετικός και η εκτέλεσή του να καθυστερήσει κατά 2 δευτερόλεπτα μετά την εκκίνηση. Στο 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 και επιχειρηματικών μετρικών — μετατροπή, αποχώρηση, διάρκεια συνεδρίας. Συνιστάται ο καθορισμός οριακών τιμών: < 3.8 δ — καλό, 3.8–7 δ — χρειάζεται βελτίωση, > 7 δ — κρίσιμο. Για εγγενείς εφαρμογές, τα όρια είναι αυστηρότερα: < 2 δ — καλό, 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
        }
    }
};