从资源、网络、渲染、计算、缓存到服务端协同，这六个维度几乎覆盖了首屏加载优化的所有环节。下面整理每个维度具体的实践步骤和检查点，遵循先易后难、低成本高收益的原则，按顺序走一遍就能压榨出首屏的大部分优化空间。
资源层：减体积，按需加载
开启打包工具的压缩与 Tree-shaking，确保剔除未引用代码；第三方库按需引入，比如 antd 只引首屏组件、lodash 用 lodash-es 的按需导入。路由用动态 import（React.lazy+Suspense 或 Vue defineAsyncComponent）做代码分割，首屏只打包核心业务代码，再通过 splitChunks 抽离公共依赖。图片全部转成 WebP 或 AVIF，老浏览器做降级；字体只打包首屏需要的字符子集。非首屏图片、视频用 Intersection Observer 实现懒加载并放好占位；非核心第三方库（ECharts、地图）等触发时再初始化。最后，清理首屏中不需要的 DOM、代码块和静态资源，避免内联大段 JS/CSS，只内联核心样式或必要的渲染逻辑。
检查时关注：打包后未压缩的首屏 JS ≤ 200KB，CSS ≤ 50KB；没有全量引入的第三方库；首屏图片全是 WebP/AVIF 且做了 srcset/sizes 响应式适配；所有非首屏资源都挂了懒加载；没有未引用的冗余代码（可用 webpack-bundle-analyzer 或 vite-bundle-visualizer 扫一遍）。> 图片体积超过 200KB 时考虑渐进式加载——先显示模糊缩略图，再换原图。
网络层：提速度，减请求
首屏小 CSS/JS 尽量合并，小图标用雪碧图或 iconfont 代替独立图片，多次接口请求能合并的就合并成一个批量接口。所有静态资源都部署到就近 CDN，并把静态资源域名和接口域名分开。推动服务端开启 HTTP/2 或 HTTP/3，配合 Keep-Alive。首屏关键资源（核心 JS/CSS、主图）加 <link rel="preload">；跨域的 CDN 或接口域名用 <link rel="preconnect"> 预建连接；再用 <link rel="priority"> 标记首屏核心资源的优先级，让浏览器先加载。
检查点：首屏 HTTP 请求总数 ≤ 20 个（包括接口和静态资源）；所有静态资源都走了 CDN 且配置了跨域（别忘了 Access-Control-Allow-Origin）；服务端已启 HTTP/2 或 HTTP/3 及 Keep-Alive；首屏关键资源做了预加载/预连接，没有加载顺序错乱；没有首屏无效请求或重复请求，接口数据已经聚合。注意，preload 只用在对首屏渲染不可或缺的资源上，用多了反而带来竞争。
渲染层：避阻塞，快渲染
操作 DOM 时尽量批量进行——用 DocumentFragment 或先移出文档流，别频繁增删改。首屏 DOM 层级控制在 5 层以内，扁平化结构。动画和过渡一律用 opacity 和 transform，借 GPU 加速，避免修改宽高、位置这类会触发重排的属性。CSS 放在 <head> 里，非核心 JS 放 body 末尾并加上 defer 或 async；首屏关键 CSS 直接内联，其余的异步加载。做一个轻量骨架屏（纯 CSS 或极简 DOM），数据未到前先渲染出来，杜绝白屏。保证首屏的静态内容可以脱离异步数据和第三方库独立渲染。
检查：打开 Performance 面板，确认没有频繁的重排重绘，单次耗时 ≤ 50ms；动画都用 transform/opacity；JS 不阻塞 DOM 解析，核心 CSS 已内联；有骨架屏，没有白屏；DOM 层级 ≤ 5，无多余节点；首屏渲染不依赖异步数据。
计算层：离主线程，减耗时
大计算量工作——比如过滤、排序、格式化、复杂算法——统统丢给 Web Worker，只把最终结果传回主线程。首屏 JS 只保留渲染必须的逻辑，埋点、统计、工具方法等非核心东西全放到 DOMContentLoaded 之后执行。顺便检查下首屏里的算法复杂度，能 O(n²) 变 O(n) 的别手软。ECharts、地图、富文本这类非首屏必须的库，等到用户真正触发或者进入对应模块时再初始化。别在主线程上搞嵌套循环或深递归，耗时操作要么异步，要么拆成小段分批次跑。
检查：耗时计算都已移入 Worker，主线程无超过 50ms 的长任务；首屏 JS 精简，没在 DOMContentLoaded 之前绑无关逻辑；没有耗时算法或嵌套递归；非核心库首屏未初始化。注意 Worker 通信只传轻量结果，别把大对象来回搬，否则通信开销会抵消收益。
缓存层：复资源，少请求
静态资源全部加哈希后缀，配置强缓存 Cache-Control: max-age=31536000；接口用协商缓存（ETag/Last-Modified）。基于 Workbox 封装 Service Worker，预缓存首屏核心资源（HTML、核心 JS/CSS、首屏图片），非核心资源跑运行时缓存，并根据场景选缓存优先或网络优先。首屏常用的静态数据（字典、城市列表、配置）存 localStorage，更大的缓存直接塞 IndexedDB；二次访问时先读本地，再用接口兜底。缓存失效别靠手动，静态资源哈希一变就自然打破强缓存，接口通过时间戳或版本号控失效，避免脏数据。
检查：所有静态资源都有哈希和强缓存，接口配了协商缓存；首屏核心资源已 SW 预缓存，二次访问可以离线加载；首屏静态数据有本地缓存，不需要重复请求；有合理的缓存失效策略，无脏数据。谨记 SW 只缓存核心资源，localStorage 总大小控制在 5MB 以内。
服务端协同：前端提需求，服务端配合
跟服务端沟通好，开启 Gzip 或 Brotli 压缩，Brotli 压缩率更高优先选，对 JS/CSS/HTML 和接口数据都做压缩。首屏接口要求做数据聚合和字段裁剪，只返回首屏真正需要的字段，减少响应体积和耗时，理想情况下响应时间控制在 300ms 内。首页、官网这类对首屏要求极高的页面，可以配合做 SSR（Next.js/Nuxt.js）或 SSG，甚至用预渲染工具直接生成静态 HTML。服务侧接口做好限流和缓存，避免响应波动。
检查：压缩已开启，压缩率 ≥ 70%；首屏接口无冗余字段，响应 ≤ 300ms；高优先级页面已实现 SSR/SSG 或预渲染；接口没有响应缓慢的情况。SSR 虽好，但会增加服务端成本，普通业务页没必要强上，根据实际需求取舍。
验证与监控：验效果，控迭代
本地开发时，用 Chrome DevTools 的 Network 和 Performance 面板反复看首屏加载时间、请求数、卡顿和包体积；跑一遍 Lighthouse，得分至少 80 分。上线后，在不同网络（3G/4G/WiFi）和设备上模拟真实体验。接入 Fundebug、Sentry 或阿里云前端监控之类的平台，盯住 FCP、LCP、FID、CLS 这几个核心指标。最后，把性能指标纳入代码评审，发版前必做性能检测，禁止导致性能回退的代码合并。
检查：Lighthouse 得分 ≥ 80，LCP ≤ 2.5s、FID ≤ 100ms、CLS ≤ 0.1；各网络下加载时间符合预期；线上监控已就位；建立了性能管控流程。重点拿 3G 网络测，慢网下最容易暴露问题。
