首屏耗时变长，别急着给服务器“加餐”，正确做法是把从输入网址到首屏绘制拆成网络、后端、加载、渲染四段，用开发者工具逐段测量，先揪出耗时大头再动手。
这个思路听着简单，但实际操作时大多数人会懵：瀑布图里那么多条线，到底看哪个？是DNS慢了还是TTFB高了？是JS执行阻塞了还是图片太大？别急，咱们一步一步拆。
首屏加载时间太长，先别急着加服务器
很多站长一看到首屏变慢,第一反应就是升级服务器带宽或CPU，说实话，我见过不少项目，服务器配置已经很高，但首屏还是慢得像蜗牛，原因根本不在后端。
首屏时间是从用户发起请求到浏览器完成首帧绘制的时间,这条路很长，你可以把它想象成一条流水线：DNS解析、TCP连接、发送HTTP请求、服务器处理、返回响应、浏览器下载资源、解析HTML、执行JS、渲染页面，任何一段卡住，整条流水线都得等。
排查的第一步不是改代码,而是先把这条流水线分成四段：
- 网络段：从输入域名到服务器响应，包括DNS、TCP、TLS握手。
- 后端段：服务器处理请求并返回首字节的时间，也就是TTFB（Time To First Byte）。
- 资源段：HTML、CSS、JS、图片、字体等文件的下载耗时。
- 渲染段：浏览器解析HTML、构建DOM树、执行脚本、绘制像素。
用Chrome DevTools的Performance面板重新加载页面，能直观看到各段时间，工具会直接给出四个指标，分别对应上面四段，先看哪个数字最大，就优先排查哪一段，别一上来就优化代码，那是本末倒置。
网站首屏速度慢是什么原因：从浏览器瀑布图逐段拆解
打开DevTools的Network面板,刷新页面，你会看到所有请求的瀑布图，每一行代表一个资源请求，横条长度就是它的总耗时，但注意，横条不是一蹴而就的，鼠标悬停在上面能看到更细的时间段划分，这才是逐段排查的核心。
瀑布图里每一段颜色代表什么
一个典型的请求耗时,按顺序分为这几个阶段：
- Queueing：请求排队等待的时间，浏览器对同域名并发连接数有限制，一般在6个左右，排队时间长，说明同一时间请求太多，或者前面的请求阻塞了。
- Stalled：请求已经发出但还没开始传输，可能是网络拥塞或代理配置问题。
- DNS Lookup
：域名解析时间，如果开启了DNS预解析，这个值会很小。
- Initial Connection：TCP三次握手的时间，如果用了HTTPS，还会加上TLS协商时间。
- TTFB：浏览器发送请求后，到收到服务器返回的第一个字节的时间，这个值直接反映后端处理能力。
- Content Download下载时间，大图片、大脚本都会让这段变长。
如何分辨DNS解析和TCP连接耗时
如果DNS Lookup超过200ms，大概率是DNS服务商的问题，可以换成更快的公共DNS，或者在页面里加预解析代码，但要注意，DNS解析在第一次访问时最慢，后续有缓存就会快很多，如果你每次刷新都慢，说明缓存没生效。
TCP连接时间通常在几十毫秒级别,如果Initial Connection经常超过100ms，要么是网络链路差，要么是服务器物理距离太远，这时候可以对比一下不同地域的访问速度，判断是不是CDN没覆盖到位。
TTFB高是后端问题还是网络问题
TTFB是首屏耗时排查中最重要的指标之一,行业共识认为，TTFB超过500ms就需要警惕了，那怎么区分是网络还是后端？
一个很简单的办法：用一个不带任何业务逻辑的静态页面去测，你直接访问服务器上的一个纯静态文件，比如/test.txt，看它的TTFB是多少，如果这个文件TTFB也高，说明是网络链路或服务器基础配置问题；如果这个文件TTFB很低，但动态页面的TTFB很高，那就是后端代码或数据库慢。
打开Performance面板,看“Server Response”区域，会直接标出服务器请求的时长，再配合后端日志，可以精确判断耗时是发生在中间件、数据库查询还是模板渲染上。
Content Download过长的典型场景
下载时间过长,基本都是文件体积和带宽的锅，比如一张未经压缩的2MB图片，在4G网络下下载耗时可能超过1秒，这时候不需要复杂的分析，直接在Network面板里按传输大小排序，找到体积最大的几个文件，然后压缩或换成WebP格式。
还有一种情况,是服务器没有开启Gzip或Brotli压缩，同样一份文本文件，开启压缩后体积能减少70%以上，检查响应头里的Content-Encoding字段，如果不是br或gzip，就该去改服务器配置了。
用Performance面板定位是解析还是渲染的瓶颈
资源下载完了,页面还没显示出来，那就得看渲染过程，Performance面板比Network更细，它能录制整个页面加载过程，并标出主线程上的每个任务。
慢在解析HTML还是执行JS
录制结束后,Main区域会显示一条主时间线，每个长条代表一个任务，颜色代表任务类型：
- 黄色：执行JavaScript脚本
- 紫色：样式计算和布局
- 绿色：绘制
如果发现有一段很长的黄色任务,说明是JS脚本执行阻塞了首屏，点开任务，能看到具体是哪个函数耗时最大，最常见的情况是首屏JS里做了太多无关紧要的初始化操作，比如解析大JSON、操作DOM、初始化第三方插件，解决办法是：把非关键的JS延时加载，或者用async/defer属性。
如果紫色任务很长,说明样式计算或布局太复杂，比如使用了大型CSS框架、复杂的选择器、频繁触发重排的动画，这时候可以从CSS入手，减少无用的样式规则。
用长任务监控抓出卡顿点
在主时间线上,如果某个任务超过50ms，就被浏览器标记为Long Task，长任务越多，页面响应越慢，尤其是首屏期间的长任务，直接影响用户看到内容的时间，你可以在Performance面板中勾选“Track Long Tasks”，然后筛选出超过100ms的任务，逐个分析。
Chrome的Performance Insights面板能直接告诉你LCP（Largest Contentful Paint）是哪个元素、什么时候绘制的，如果LCP元素是一张图片，那问题大概率在图片加载；如果是一个文本块，那问题可能在渲染阻塞。
实际操作路径：三步定位渲染瓶颈
第一,打开DevTools的Performance面板，点击左上角的录制按钮，第二，勾选“Screenshots”和“Track Long Tasks”，然后按Ctrl+Shift+R强制刷新页面，第三，等页面加载完成后停止录制，直接看Main区域的红条或长条，通常最长的那个任务就是首屏耗时的元凶。
逐段优化的优先级：先砍体积，再谈缓存
排查完毕后,优化顺序同样重要，很多人一上来就上CDN，但连本地大图都没压缩，结果白花钱，我建议按照下面的优先级干活：
- 第一优先：压缩并合理设置图片格式，首屏图片体积往往占页面总重量的一半以上，用WebP或AVIF格式，把尺寸大的图片换成响应式图片（
srcset），可以立竿见影。 - 第二优先：减少渲染阻塞资源，首屏只加载页面结构所需的CSS，其余样式异步加载；JS脚本加
defer或async，也可以把关键路径内联。 - 第三优先：开启CDN并配置缓存，CDN能缩短物理距离，但前提是源站资源请求要命中缓存，设置合理的Cache-Control，对静态资源强制缓存，对HTML文档做协商缓存。
- 第四优先：优化后端TTFB，比如开启HTTP/2、减少数据库查询次数、使用Redis缓存。
- 第五优先：使用预加载和预连接，对首屏需要的字体、大图，用
<link rel="preload">提前下载；对第三方域名用dns-prefetch或preconnect缩短连接时间。
这套顺序的核心逻辑是：优先干掉体积，再减少请求数量，最后才考虑传输路径，一个100KB的页面，就算网络再差也不会慢到哪里去；一个2MB的页面，CDN再快也救不回来。
CDN加速对首屏的影响怎么判断
如果你已经用了CDN,但首屏还是慢，别急着把锅甩给CDN，你可以做一次对比测试：直接访问源站IP（绕过CDN），看TTFB和下载时间，如果源站更快，说明CDN节点缓存或回源链路有问题；如果源站更慢，那问题根本不在CDN。
实际操作中,可以用curl命令模拟：
curl -o /dev/null -s -w "DNS解析：%{time_namelookup}snTCP连接：%{time_connect}snTTFB：%{time_starttransfer}sn总耗时：%{time_total}sn" https://你的域名
多测几个地域,或者用在线监测工具模拟不同城市访问，对比数据后再决定要不要调整CDN策略。
首屏耗时排查常见问题
问：首屏耗时和页面完全加载完成时间有什么区别？
首屏耗时只算用户看到首屏内容的那个时间点，通常是首帧绘制或LCP出现，完全加载时间是所有资源都加载完的时间，包括首屏下方的图片、懒加载的模块等，两者差距大很正常，重点要看首屏那个点卡在哪。
问：用移动端模拟测首屏耗时可不可靠？
Chrome DevTools的设备模拟能大致反映手机性能，但它用的是桌面浏览器内核，网络环境也是模拟的，真实场景中，移动端网络波动大、CPU性能弱，首屏耗时往往比模拟结果高出不少，更准确的办法是用真实手机通过远程调试或性能监控平台采集数据。
问：TTFB低但首屏还是慢，说明什么？
说明后端响应很快，瓶颈在浏览器端资源下载或渲染，检查Network面板里是否有体积过大的JS或CSS，再看Performance面板里是否有长任务，TTFB只是起点，不是终点。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/715673.html
