TV浏览器HTML5加载慢的根本原因是硬件、网络和渲染三重受限，需针对性优化：升级CDN支持Range请求、延迟加载视频、精简JS执行、内联关键CSS及压缩poster图。
TV浏览器的HTML5加载慢，根本原因是硬件+网络+渲染三重受限
TV浏览器（如WebOS、Tizen、Android TV内置WebView）不是桌面Chrome，它通常运行在低主频ARM芯片上，内存小、GPU弱、JavaScript引擎老旧，且默认禁用很多现代优化特性。用户感觉“卡”，往往不是代码写得差，而是TV端根本不支持你习以为常的加载逻辑——比如 preload="auto" 会被忽略，IntersectionObserver 可能未实现，甚至 fetch() 的超时行为都和桌面不一致。
video标签在TV上加载慢，别急着压缩MP4，先查CDN是否支持Range请求
TV浏览器对大视频文件极其敏感：若CDN或源站不支持HTTP Range Requests，浏览器就无法“边下边播”，只能等整个MP4下载完才开始解码——而一个100MB的720p视频，在2Mbps带宽下要等8分钟。这不是前端代码的问题，是服务端配置缺陷。
- 用浏览器开发者工具（如有）或curl检查响应头：
Accept-Ranges: bytes必须存在 - 避免直接用Nginx静态托管大视频；改用支持分片的CDN（如Cloudflare Stream、阿里云VOD、腾讯云点播），它们自动切片并返回
206 Partial Content - TV端不认
loading="lazy"，但可手动控制：
JS执行卡顿？关掉console.log，禁用所有非必要polyfill
TV浏览器的V8或JavaScriptCore版本普遍滞后（例如Tizen 5.5仍用V8 6.9），Promise.allSettled()、Object.fromEntries() 等API需polyfill，但引入core-js会吃掉几十MB内存并拖慢首屏。更糟的是，很多TV系统会把console.log() 同步刷到日志服务，一次打印就卡住主线程200ms+
- 构建时用Babel只转译目标环境缺失的语法（如设
targets: { browsers: ['samsung 5.5', 'webos 5.0'] }），不全量引入polyfill - 上线前删除所有
console.*，可用if (false) console.log(...)让UglifyJS自动剔除 - 避免使用
requestIdleCallback——多数TV浏览器不支持，降级逻辑反而增加判断开销
首屏白屏超5秒？用“fake HTML”提前渲染骨架，但别碰DOM操作
TV浏览器解析HTML慢，且CSSOM阻塞严重。与其等完整DOM树建完再渲染，不如在里内联极简CSS，用纯HTML画出占位结构（如灰色块模拟按钮/海报图），等JS加载后再补交互。关键：这个骨架必须是静态HTML，不能靠JS动态document.write()或innerHTML插入——TV端DOM API调用延迟极高，容易卡死。
立即学习“前端免费学习笔记（深入）”；
- 内联关键CSS不超过2KB，用
这类无继承、无动画规则 - poster图必须小于50KB，用WebP格式；TV浏览器对JPEG解码慢，PNG又太大
- 禁止在
window.onload里批量操作DOM节点，改用setTimeout(fn, 0)让出主线程，给TV浏览器喘息时间
async脚本。真正起效的，是把每个资源都当成“可能永远加载不完”来设计。 
