Time-to-Interactive no desenvolvimento mobile: o que é, métrica e medições

O que é Time-to-Interactive

Time-to-Interactive é uma métrica de desempenho que captura o momento em que uma página ou aplicativo está pronto para a interação completa do usuário. No contexto web, o TTI é definido como o tempo desde o início da navegação até o momento em que três condições são atendidas: a página exibiu conteúdo útil (First Contentful Paint), a thread principal ficou ociosa por pelo menos 5 segundos e todos os listeners de eventos estão registrados. Em aplicativos móveis, o TTI é o tempo desde o lançamento da Activity até a inicialização completa da UI, quando todos os estados estão carregados, as animações configuradas e o usuário pode tocar em qualquer botão sem atraso.

Esta métrica é especialmente importante para aplicativos onde a primeira interação é crítica — telas de login, pesquisa, checkout. Se o TTI exceder 5 segundos, o usuário percebe o aplicativo como “congelado” e pode fechá-lo. De acordo com o Google (Web Vitals Report, 2025), páginas com TTI inferior a 3.8 segundos mostram 24% mais conversões do que páginas com TTI superior a 7 segundos. A diferença é sentida mesmo em 500 ms — pesquisas da Amazon mostram uma perda de 1% na receita para cada 100 ms de atraso.

Como o TTI é calculado

O algoritmo de cálculo do TTI é definido na especificação W3C e implementado no Lighthouse. O cálculo começa com o First Contentful Paint (FCP) — o momento em que o navegador renderiza o primeiro pixel de conteúdo. Em seguida, o algoritmo procura uma “janela de silêncio” — um período de 5 segundos durante o qual nenhuma tarefa na thread principal excede 50 ms. O TTI é definido na última tarefa antes desta janela. Se nenhuma janela de silêncio for encontrada em 15 segundos, o TTI é igualado ao tempo da última tarefa longa. Este algoritmo garante que o TTI reflita a prontidão real para interação, não apenas o momento da renderização.

Em aplicativos móveis (Android/iOS), não existe um equivalente exato da especificação W3C, mas o conceito é o mesmo. O TTI pode ser medido capturando um timestamp em onResume (início da execução) e no callback do primeiro frame quando todas as operações assíncronas forem concluídas. O Firebase Performance permite criar um trace personalizado com início e fim da sessão interativa do usuário. Por exemplo, startTrace(“TTI”) no Application.onCreate e stopTrace() após todos os SDKs serem inicializados e o primeiro frame ser renderizado.

Exemplo de trace personalizado para TTI

O código em Kotlin demonstra a medição do TTI usando Firebase Performance. O trace começa no Application.onCreate e para após o primeiro 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 e FID: diferenças

No ecossistema Core Web Vitals, existem várias métricas, e o TTI é frequentemente confundido com First Contentful Paint (FCP) e Largest Contentful Paint (LCP). FCP é o tempo de renderização do primeiro pixel de conteúdo, que não garante interatividade. LCP é o tempo de renderização do maior elemento de conteúdo (imagem, bloco de texto). O TTI, no entanto, mede não a renderização, mas a prontidão para interação. A diferença é crítica: o FCP pode ser de 1.2 segundos, mas se a thread principal estiver bloqueada pelo carregamento do bundle JS, o TTI pode atingir 8 segundos.

First Input Delay (FID) mede o atraso entre a primeira ação do usuário e o momento em que o navegador começa a processar o evento. FID é a “qualidade da interatividade”, enquanto TTI é o “tempo até a interatividade”. Se o TTI mostra em quantos segundos a interface se torna responsiva, o FID mostra o quão responsiva ela foi. Um bom TTI é impossível sem um bom FID, porque se a thread principal estiver bloqueada, o TTI será alto e o FID atrasará qualquer interação. Em aplicativos móveis, o equivalente do FID é a Touch Latency — o atraso entre tocar na tela e a resposta da UI.

TTI em aplicativos móveis

Em aplicativos móveis nativos, o conceito de TTI não é tão padronizado quanto na web, mas sua importância não é menor. No Android, o TTI é o tempo desde tocar no ícone do aplicativo até o momento em que a UI está totalmente interativa: RecyclerView rola, botões respondem a toques, animações funcionam suavemente. Para medir o TTI no Android, usa-se uma combinação de reportFullyDrawn (API 29+) e FrameMetricsAggregator. reportFullyDrawn é uma chamada que o aplicativo faz quando o desenvolvedor considera a UI pronta. O sistema captura este momento e o inclui no relatório Android Vitals.

No iOS, os equivalentes do TTI são Time to First Frame e Time to Responsive. O MetricKit coleta dados de tempo de inicialização divididos em fases — carregamento do executável, inicialização de frameworks, renderização do primeiro frame. A Apple recomenda que o Time to First Frame não exceda 400 ms e que a interatividade completa seja alcançada em até 2 segundos. Se o aplicativo mostra uma tela placeholder e depois carrega conteúdo, o TTI é calculado não a partir do primeiro frame, mas a partir do momento em que o conteúdo real está pronto para interação.

Medição do TTI no Android via FrameMetrics

O código em Kotlin rastreia o primeiro frame interativo usando FrameMetricsAggregator. O callback é acionado após a conclusão do primeiro frame iniciado pelo usuário.

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

Métodos de otimização do TTI

A otimização do TTI envolve três direções: redução da carga na thread principal, carregamento adiado de componentes não críticos e renderização progressiva. A primeira direção é minimizar operações síncronas: substituir SharedPreferences por DataStore, mover a inicialização de SDK para uma thread em segundo plano, carregamento preguiçoso de módulos Dagger/Hilt. A segunda é o carregamento adiado: telas que não são visíveis na inicialização (bottom sheets, diálogos, abas) devem ser inicializadas após o primeiro frame. A terceira é a renderização progressiva: primeiro mostrar uma tela esqueleto, depois carregar o conteúdo em partes.

No Android, um método eficaz é usar a biblioteca App Startup com inicializadores ranqueados. Por exemplo, o inicializador do Firebase Analytics pode ser tornado opcional e atrasado em 2 segundos após a inicialização. No iOS, o equivalente são Initialization Dependencies com a flag lazy. Para a web, os métodos principais são code splitting, tree shaking, preload/preconnect para recursos críticos e defer para JS não bloqueante. O Google Lighthouse fornece recomendações específicas: “Eliminate render-blocking resources” e “Defer offscreen images” afetam diretamente o TTI.

Code Splitting no React Native

Exemplo de divisão do bundle no React Native usando React.lazy e Suspense. O componente HeavyScreen é carregado apenas quando o usuário navega para essa tela, reduzindo o TTI da tela inicial.

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

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

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

Ferramentas para medir o TTI

Várias ferramentas estão disponíveis para medir o TTI, variando por plataforma e profundidade de análise. Na web, a ferramenta principal é o Lighthouse no Chrome DevTools. O Lighthouse executa uma auditoria e exibe o TTI em milissegundos, além de fornecer recomendações específicas para melhoria. Para monitoramento contínuo, usa-se o PageSpeed Insights (Google) — ele coleta dados do Chrome User Experience Report (CrUX) de usuários reais. Em aplicativos nativos, o TTI é medido através do Android Vitals (Google Play Console) e do MetricKit (Apple).

Para monitoramento em produção, ferramentas populares incluem Firebase Performance Monitoring (traces personalizados), Datadog RUM (Real User Monitoring) e Sentry Performance. Essas ferramentas não apenas mostram o TTI, mas também permitem rastrear a correlação entre o TTI e métricas de negócio — conversão, abandono, tempo de sessão. Limiares recomendados: < 3.8 s — bom, 3.8–7 s — precisa melhorar, > 7 s — crítico. Para aplicativos nativos, os limiares são mais rigorosos: < 2 s — bom, 2–5 s — médio, > 5 s — crítico, pois usuários de aplicativos móveis são menos tolerantes a atrasos.

Configuração do Lighthouse CI

Exemplo de configuração do Lighthouse CI para verificação automatizada do TTI em um pipeline CI/CD. Quando o limite de 3.8 segundos é excedido, o build é marcado com um aviso.

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