首屏优化很容易变成一串动作清单：压缩图片、拆包、上 CDN、懒加载、预加载、减少请求。每个动作都可能有效，但如果没找到瓶颈，优化就像盲人摸象。页面慢到底是 HTML 慢、主包大、图片晚到、字体阻塞、接口等待，还是渲染主线程被占住，答案不同，解法完全不同。
我会先看 LCP 和资源瀑布，而不是直接改代码。LCP 告诉你用户看到主要内容的时间，资源瀑布告诉你时间花在哪里。先定位瓶颈，再选择策略，通常比把所有优化都做一遍更省力。
先确定首屏主角是谁
LCP 优化的第一步，是找出页面里真正的最大内容元素。它可能是头图、标题块、商品卡、视频封面，也可能是一个动态渲染出来的内容区。主角不同，优化方向不同。
如果 LCP 是图片，就要看图片尺寸、格式、加载优先级和 CDN；如果 LCP 是文本，就要看字体、CSS 和 HTML 到达时间；如果 LCP 是接口数据，就要看服务端和渲染等待。
不要把“首屏”当成页面顶部的抽象区域。用户感知的是具体内容什么时候出现，指标也会落到具体元素上。
先找到首屏主角，再谈优化动作。
实验室分数只能说明一部分
本地跑 Lighthouse 很方便，但它不等于真实用户体验。公司网络稳定、机器性能强、缓存状态干净，和用户在移动网络、低端设备、冷启动场景下看到的页面不一样。实验室工具适合定位问题，不适合直接代表结论。
我通常会把数据分成两类：实验室数据用来分析链路，真实用户数据用来判断影响。实验室里能看到资源瀑布、长任务和渲染阻塞；线上 RUM 能看到不同地区、设备和网络条件下的真实 LCP 分布。
如果只有实验室分数，很容易优化成“报告好看”；如果只有线上均值，又很难知道该改哪里。两者放在一起，才比较接近工程判断。
资源瀑布比总耗时更有用
总耗时只能说明慢，资源瀑布能告诉你为什么慢。DNS、连接、HTML、CSS、JS、图片、接口，每一段都有可能成为关键路径。只看 bundle 大小，可能会错过接口排队；只看接口耗时，又可能忽略字体阻塞。
排查时把瀑布图按关键路径标出来：哪些资源必须先到，哪些可以延后，哪些互相阻塞。关键路径之外的资源不一定急着优化。
比如一个页面加载了很多图，但 LCP 是首张主图，那么先优化主图优先级，比批量压缩所有小图更直接。相反，如果 LCP 元素等接口数据才能渲染，主图再小也不会让用户更早看到核心内容。
主图优化要同时看尺寸和优先级
很多首屏问题最后落在主图上。图片太大当然会慢，但只压缩还不够。图片是否被 CSS 背景隐藏、是否被懒加载错误延后、是否缺少宽高导致布局抖动、是否在多个候选尺寸里选错，都可能拖慢 LCP。
首屏主图通常不应该懒加载。它是用户最先需要看到的内容，应该明确给出尺寸、使用合适格式，并让浏览器知道它很重要。移动端还要避免下载桌面端大图，响应式图片不是装饰，而是节省真实时间。
图片优化也要有视觉底线。过度压缩会让首屏看起来廉价，尤其是产品图、封面图和展示类页面。好的优化不是把图片压到最小，而是在清晰度和加载速度之间找到稳定平衡。
瀑布图能说明时间花在哪里。
下面这段可以作为排查顺序，不是固定流程，但能避免一上来乱改：
- 1. 找到 LCP 元素
- 2. 看 LCP 元素依赖哪些关键资源
- 3. 标出资源瀑布上的等待关系
- 4. 检查首屏前是否有长任务阻塞渲染
- 5. 只优化关键路径上的资源
- 6. 上线后用 RUM 按设备和网络分组验证
JS执行慢会拖住渲染
资源下载完不等于页面能显示。主线程如果忙着解析大包、执行初始化、处理复杂计算，渲染也会被拖住。很多页面的瓶颈不是网络，而是 JS 执行和布局计算。
可以用 Performance 面板看长任务，找出首屏前是否有不必要的初始化。埋点 SDK、富文本编辑器、非首屏组件、复杂图表，都可能提前抢占主线程。
优化策略可以是延后加载、按需初始化、拆分任务、服务端预渲染或减少首屏组件复杂度。关键是别把所有责任都推给网络。如果主线程一直忙，资源再早下载完也显示不出来。
预加载要服务关键路径
preload、prefetch、preconnect 都不是越多越好。预加载错误资源会抢带宽，反而让真正关键的内容更慢。先确定 LCP 元素需要什么，再决定预加载什么。
如果 LCP 是主图，可以给主图更高优先级；如果是字体渲染，可以处理字体加载策略；如果是接口数据，则可能要优化服务端响应或做骨架与流式渲染。
预加载的验收也要看指标变化，而不是看代码里多了标签。没有改善 LCP 的预加载，很可能只是增加复杂度。特别是在移动网络下，带宽更窄，错误优先级的代价更明显。
不同瓶颈对应不同优化策略。
缓存要区分首访和复访
缓存对复访很有效，但不能掩盖首访问题。很多团队本地调试时缓存已经命中，以为页面很快；真实新用户第一次打开，仍然要下载 HTML、CSS、JS、字体和图片。首访体验差，用户未必会给你第二次机会。
所以报告里最好分开看 cold load 和 warm load。首访看关键资源体积、CDN、服务端响应和首屏渲染；复访看缓存命中、版本更新、Service Worker 策略和资源失效。两种场景混在一起，会把问题平均掉。
缓存策略也不能只追求长时间。资源如果带 hash，可以长期缓存；HTML 通常要更谨慎；接口数据要看业务实时性。缓存错了，用户看到旧数据，比慢一点还麻烦。
优化结果要分场景看
实验室环境和真实用户环境差异很大。公司网络、开发机、无缓存首访、弱网移动端、老设备，看到的瓶颈可能不同。只在本地 Lighthouse 里拿高分，不代表线上用户变快。
上线后要看 RUM 数据，按设备、网络、地区、页面类型拆分。某些优化对桌面无感，却能显著改善移动弱网；也可能相反。比如移除一个首屏长任务，在高端设备上变化不大，在低端设备上可能非常明显。
最终结论应该写清适用场景：这次优化改善的是哪类用户、哪个页面、哪个阶段。这样下一次优化不会重复走弯路。
先改最短的关键路径
首屏优化最怕把范围拉得太大。拆包、服务端渲染、图片系统、缓存策略，每一项都能做很久。如果团队没有先找到关键路径，最后可能改了很多，却没有明显改善用户看到主要内容的时间。
我会先选一个页面、一类用户、一个指标做闭环。比如只优化商品详情页移动端首访 LCP，先从主图优先级和接口等待入手，观察 p75 是否下降。闭环跑通以后，再推广到类似页面。
优化不是把所有建议都执行一遍，而是持续缩短用户真正等待的那条路径。能说清“这次慢在谁身上、为什么这么改、上线后看哪个指标”，才算是可维护的首屏优化。
服务端时间不能被前端优化掩盖
有些页面的 LCP 慢，前端改了很久也不明显，因为 HTML 或首屏接口本身就慢。服务端响应、数据库查询、缓存穿透、接口串行调用，都会把首屏起点往后推。浏览器还没拿到关键内容，前端没有多少发挥空间。
排查时要把 TTFB 和接口耗时单独拉出来看。如果 HTML 慢，就先看服务端渲染、缓存和边缘节点；如果首屏数据接口慢，就看接口是否可以并行、是否可以裁剪字段、是否可以提前缓存。不要把所有慢都归因到 JS 包大。
有时最有效的优化不是“前端少做一点”，而是“服务端早给一点”。比如首屏只需要标题、主图和价格，就不要等一堆非首屏推荐数据一起返回。把关键内容先返回，剩下的内容后补，用户感知会明显不同。
字体策略也会影响首屏观感
中文页面很容易忽略字体加载。自定义字体如果体积大、加载晚，可能造成文本不可见或闪烁。对于以文字为主的页面，标题和正文是否能尽快显示，会直接影响用户对首屏速度的判断。
字体策略要根据页面类型取舍。品牌官网可能愿意为字体质感付出一点加载成本；工具型后台和内容页通常更应该优先可读性。可以考虑系统字体、字体子集、font-display 策略，或者只在局部标题使用特殊字体。
不要为了统一视觉，把所有页面都绑到一个大字体文件上。首屏优化里，审美和性能不是敌人，但需要明确优先级。用户看不到内容时，再漂亮的字体也没有意义。
骨架屏不能替代真实内容
骨架屏能降低等待焦虑，但它不等于 LCP 优化。用户最终要看到真实标题、图片、商品或正文。骨架屏出现得很快，真实内容很晚，指标和体验仍然不会好。
骨架屏适合用在数据确实需要等待、且布局稳定的场景。它不适合掩盖接口慢，也不适合做得比真实内容还复杂。一个过度设计的骨架屏，甚至可能增加首屏 DOM 和样式负担。
比较健康的做法是：骨架屏负责稳定布局，真实内容负责尽快到达。不要让骨架屏成为团队逃避关键路径优化的理由。
第三方脚本要有首屏准入规则
很多页面首屏变慢，最后发现是第三方脚本太多。统计、客服、广告、热力图、AB 实验、风控，每一个脚本都有理由提前加载，但浏览器不会因为理由充分就变快。
首屏前加载的第三方脚本要有准入规则：是否影响首屏核心功能，是否必须同步执行，是否可以延后，失败是否会阻塞页面。不能回答这些问题，就不应该默认进入关键路径。
尤其是营销和内容页面，第三方脚本经常越积越多。每次只加一个，单看都不重；半年后一起执行，主线程就被切得很碎。性能治理要有账本，知道首屏前到底加载了哪些外部能力。
验收要看 p75 而不是单次最快
优化上线后，不能只拿一次最快截图证明成功。Web 性能更适合看分位数，比如 p75 LCP。它比平均值更能反映多数用户体验，也不容易被极端快或极端慢的数据带偏。
验收还要分组：移动端和桌面端分开，首访和复访分开，弱网和正常网络分开。一次优化可能只改善某个组，这并不是失败，前提是你的目标本来就是那个组。
我会在发布前写清三个数字：优化前目标组 p75 是多少，预期下降到多少，观察窗口多久。如果没有达到，回滚还是继续调整也要提前说清。这样性能优化才不会变成“感觉快了”。
别把所有页面套同一套方案
首页、详情页、搜索页、后台看板、文章页，它们的首屏主角不一样。首页可能是头图和导航，详情页可能是商品信息，搜索页可能是首批结果，后台看板可能是关键指标。不同页面套同一套优化方案，往往会浪费时间。
比如后台看板如果首屏关键是指标卡，图表库可以延后；文章页如果关键是标题和正文，评论和推荐可以后加载；商品详情如果关键是主图和价格，就要先保证图片和价格信息到达。页面目标不同，关键路径就不同。
所以首屏优化最好从页面画像开始：用户打开这个页面第一眼最需要什么？这个内容依赖哪些资源？哪些资源可以晚一点？只要这个问题答清楚，很多优化选择会自然收敛。
一个更稳的工作闭环
最后，我会把首屏优化拆成四步闭环。第一步定位：找 LCP 元素、资源瀑布和长任务。第二步决策：只选关键路径上的一两个问题。第三步上线：小范围发布并保留回滚。第四步验证：用 RUM 看目标用户的 p75 变化。
这个闭环看起来慢，但比盲目执行十条优化建议更可靠。真正拖慢页面的常常只有一两段关键等待，把它们找出来，收益会比平均用力更明显。
首屏优化不是为了追求一个漂亮分数，而是让用户更早看到他打开页面真正想看的东西。只要围绕这个目标，技术取舍就会清楚很多。