页面首屏迟迟不出现，单看总耗时很难判断该改哪里。更有效的做法是沿着请求从浏览器到服务器、再回到页面的顺序排查。网站核心页面加载链路的瓶颈诊断方法，重点不是盯住某个孤立指标，而是找出最先造成等待、且会影响首屏展示的环节。
先把慢的现象变成可比较的记录
在 Chrome DevTools 的 Network 面板中开启保留日志，选择实际受影响的页面，分别记录首次访问和再次访问的情况。首次访问更能暴露未缓存资源和连接开销；再次访问则能看出浏览器缓存是否有效。注意，“停用缓存”适合观察完整下载链路，但不能代表普通回访体验。
尽量固定设备、网络条件和页面状态，连续测几次并比较中位数。瀑布图中，前面一批请求若整体右移，可能是连接或服务器响应问题；只有少数资源很长，则应检查对应请求。不要把不同网络、不同缓存状态的结果直接比较。
按请求发生顺序定位等待
- 看请求是否迟迟没有开始。若资源长时间处于排队状态，可能是同一主机的并发请求较多、浏览器连接受限，或页面一次触发了过多资源。先按域名和资源类型分组，判断是普遍排队还是单个资源异常。
- 检查连接建立阶段。连接时间偏长时，比较不同域名的请求：若多个域名都慢，重点检查用户网络与边缘节点距离；若只有一个域名明显异常，再核对该域名的解析、连接复用和安全连接开销。CDN 可缩短部分用户到内容节点的传输距离，但不能替代对源站和页面请求数量的检查。
- 区分服务器等待和内容下载。请求发出后到首字节返回前等待较久，通常应检查应用处理、缓存命中、数据库查询或上游服务等待；响应已经开始但下载持续很久，则要看文件体积、带宽和传输稳定性。相同接口在不同时间都慢，更值得查服务端；只在特定网络慢，则先查传输路径。
- 确认资源是否挡住首屏。在瀑布图中标记首屏主要内容对应的请求。晚到的非首屏图片即使很大，也未必是当前问题；相反，关键字体、样式或主内容接口若迟迟未完成，可能让页面看起来一直没加载好。
- 回到渲染与设备负载。若关键请求已完成但画面仍迟迟不更新，检查主线程是否被大量脚本执行、布局计算或图片解码占用。换一台性能不同的设备复测，有助于区分网络等待与本地计算瓶颈。
把诊断结果转成下一步行动
网站核心页面加载链路的瓶颈诊断方法应形成“现象—证据—验证”的闭环。先选取瀑布图中最影响首屏的请求，再一次只改一个因素：例如减少非必要请求、压缩过大的资源、改善接口缓存，或优化服务端慢查询。改动后在相同网络和缓存条件下复测，确认等待阶段是否缩短，同时检查页面内容是否完整。
若浏览器瀑布图无法判断服务器内部耗时，可将请求时间、接口路径和服务端日志中的同一请求标识对应起来；若问题只在部分用户出现，则按地区、设备或网络类型分组查看真实用户监测数据。不要仅凭一次实验就归因，也不要为了缩短单项耗时牺牲首屏必需内容。
常见问题
首屏慢，先看服务器还是前端？
先看瀑布图：关键请求的服务器等待明显，就从服务端查起；请求已完成而画面未更新，再检查前端渲染和设备负载。
为什么首次访问和回访差异很大？
回访可能命中浏览器缓存，减少资源下载。应分别记录两种场景，避免用回访结果代表首次访问。
测一次就能定位吗？
通常不能。网络波动、缓存状态和服务器负载都会影响结果，应重复测量，并在相同条件下比较。
归根结底，网站核心页面加载链路的瓶颈诊断方法，是从首屏关键请求出发，逐段确认排队、连接、服务端等待、下载和渲染，找到有证据支持的第一个瓶颈，再针对性验证。
