Nobody wants to wait 8 seconds for a TV app to load. But startup time on smart TVs is worse than on phones or tablets because the hardware is slower, the web engines are older, and the initialization path for a streaming app involves more work than most apps. This guide covers how to measure startup time properly, where the time actually goes, and what you can do about it.
Measuring startup time correctly
Before optimizing, you need a reliable measurement. “Startup time” means different things in different contexts:
Cold start is the time from app launch (user selects the app on the TV home screen) to the first interactive screen. This is the number that matters most to users and platform certification.
Warm start is resuming from a backgrounded state. This is usually much faster because the web engine is already initialized. It still matters, but it is less of a problem.
Time to first paint is when the first pixels appear. This is not the same as time to interactive. A splash screen or loading indicator counts as first paint but not as startup complete.
Time to interactive is when the user can actually do something: navigate, select content, or start playback. This is the metric that correlates with user satisfaction.
How to measure on each platform:
On Samsung Tizen and LG webOS, use the Web Inspector’s Performance tab. Start recording before launching the app, then mark the point where the first interactive screen renders. The timeline will show you exactly where the time goes.
On Google TV, use Android Studio’s profiler or Systrace. Mark the point where your Activity’s first frame is drawn.
On Roku, use the BrightScript profiler and log timestamps at key initialization points.
Run the measurement at least 5 times and use the median. Startup time varies due to system state, so a single measurement is not reliable.
Where startup time goes
A typical web-based smart TV app startup breaks down roughly like this:
-
Platform initialization (0.5-2s): The web engine starts, loads your index.html, begins parsing. You cannot control this directly.
-
JavaScript parsing and execution (0.5-3s): Your app bundle is parsed and executed. This is often the biggest contributor you can control. A 2 MB minified JavaScript bundle takes noticeably longer to parse on a 2020 Samsung TV than on a modern phone.
-
Initial API calls (0.5-2s): Authentication check, configuration fetch, content catalog request. These happen over the network and are bounded by network latency and API response time.
-
Layout and rendering (0.2-1s): The first screen’s DOM is constructed, styled, and painted. Complex layouts with many images take longer.
-
Image loading (0.5-2s): Hero images, poster art, and background images for the first screen. Large images on slow connections add significant time.
Totaled up, a naive implementation can easily hit 5-10 seconds of cold start time on a mid-range smart TV. The goal is to get it under 3 seconds.
Bundle size reduction
The single most impactful optimization is reducing the amount of JavaScript that needs to be parsed at startup.
Code splitting. Do not ship a single monolithic bundle. Split your code so that the initial load only includes what the first screen needs. Route-based splitting is the most common approach: the code for the player, settings, search, and other screens loads on demand when the user navigates to them.
Tree shaking. Ensure your bundler (webpack, Rollup, esbuild) is eliminating dead code. Common culprits: importing an entire utility library when you use one function, including development-only code in production bundles, bundling polyfills for features you do not use.
Dependency audit. Check the size of each dependency. A date formatting library that adds 80 KB gzipped is not worth it if you only format dates in two places. Write a small formatter instead.
Target output. If your minimum supported Chromium version is 69 (2020 Samsung TVs), you still need to transpile and polyfill some features, but you do not need to target ES5. Shipping modern JavaScript where possible reduces bundle size because transpiled code is larger than the original.
API call parallelization
Sequential API calls are a common startup bottleneck. If your initialization makes 4 API calls and each takes 300ms, sequential execution costs 1.2 seconds. Parallel execution costs 300ms.
Identify independent calls. Authentication check, feature flags, content catalog, and user profile are often independent. Fire them all at once with Promise.all (or equivalent).
Identify dependent calls. If the content catalog request requires an auth token, you cannot parallelize them. But you can parallelize everything that does not depend on auth, and start the auth-dependent calls as soon as the token arrives.
Preconnect. Use <link rel="preconnect"> for your API domains so the TCP/TLS handshake happens during HTML parsing rather than waiting for JavaScript to make the first request.
Lazy loading and deferred initialization
Not everything needs to happen at startup:
Analytics initialization. Start collecting events immediately but defer the analytics SDK initialization (which might involve a network call and significant JavaScript execution) until after the first screen is interactive.
Player preloading. Do not initialize the video player until the user navigates to a playback screen. Player initialization can consume significant memory and CPU.
Below-the-fold content. If the first screen has a scrollable content rail below the fold, load that content after the above-the-fold content is rendered and interactive.
Secondary features. Search, settings, user profile, and other non-primary features should not block startup. Load their code and data on demand.
Caching for subsequent launches
The first cold start is always the slowest. Make subsequent launches faster with caching:
Cache API responses. Store the last successful content catalog response in local storage. On the next launch, render the cached catalog immediately and refresh it in the background. The user sees content instantly while fresh data loads.
Cache the critical rendering path. If your app uses a configuration endpoint to determine layout or feature availability, cache the last response. Use the cached version at startup and validate in the background.
Image caching. Most smart TV platforms cache images at the browser level, but verify that your cache headers are set correctly. Hero images that are re-downloaded on every launch waste time.
Platform-specific considerations
Samsung Tizen: startup time is a certification requirement. Samsung may reject apps that take too long to show the first screen. Profile on the oldest device in your support matrix.
LG webOS: similar certification expectations. The webOS app lifecycle means your app may be fully unloaded and re-launched more often than on other platforms.
Roku: channel startup time is measured and displayed by the system. The Roku OS shows a “loading” screen while your channel initializes. Optimize to minimize the time the user spends on this system screen.
Google TV: cold start time is affected by the device’s memory pressure. If the system recently killed background apps to free memory, your app launches into a clean environment. If not, memory pressure during startup can slow things down.
Startup time optimization is iterative. Measure, identify the biggest contributor, fix it, measure again. The first round of optimization usually yields the biggest gains. After that, improvements get smaller and the tradeoffs get harder.