我想减少网页打开的 TTFB，那么请教些问题

[Famio]

我的网站中很多的资源引用都是用的绝对路径，这会加重页面请求，网站成型后，现在改相对路径还来得及么= =感觉是个大工程啊……

[hupeng]

TTFB 和资源文件的绝对，相对路径没有关系

[vertas]

TTFB 主要花费在网络传输和服务器处理，其他关系非常小，所以你要从这两方便着手和路劲完全没关系！

[RihcardLu]

做过相关优化，正如 2#所说，当时发现的问题是服务端某个查询执行次数过多，优化后正常，所以还是多从程序效率，数据库查询方面寻找瓶颈。

[Famio]

@hupeng @vertas @RihcardLu

谢谢三位的回复。
那么再请教下，是否有办法查看 TTFB 整个过程中，每个阶段的耗时？

[BOYPT]

@Famio 按 F12 啊

[Famio]

@BOYPT F12 能看到 TTFB 内的全部阶段？我说的是 TTFB 啊！不是页面请求的全部阶段……

[wuxqing]

chrome ， ctrl+shift+j ，然后在 Network 中点访问的 url ， Timing 里面可以看到 TTFB
其他浏览器我不熟悉，应该也有类似的

[RihcardLu]

@Famio
请看 Time To First Byte (TTFB) 的定义（ https://en.wikipedia.org/wiki/Time_To_First_Byte ）， TTFB 说的是从 client 发送 HTTP 请求到接受 server 响应首个字段的时间段。对于 client 来说， server 相当于黑盒，这个时间段发生了什么， client 无从知晓。
排查步骤：
1. 每个页面的 TTFB 都很长？是，从 CDN 方向优化
2. 个别页面 TTFB 很长？是，看数据库日记，有没有密集查询？某个查询耗时过久？看该页面请求执行了哪些函数， for 是不是嵌套太多等等

[Famio]

@RihcardLu 谢谢科普，这才是我要的！

[ningcool]

CSS ， js 等脚本资源的合并，以及页面是否压缩，很重要！因为 http 每一次请求都有很大的网络开销。当然，网页的那些动态处理和业务逻辑是你们自己的事情。

[otakustay]

除非有 Server Timing 的支持，不然 TTFB 是没办法告诉你分阶段（ req - server - res ）的各阶段数据的，当然 req 和 res 这 2 个阶段可以考虑通过一些网络监听程度比如 wireshark 之类的去看

对于静态文件，由于 server 基本不会耗时，所以减少 ttfb 最简单的（对于很多人也几乎是唯一的）手段就是上 CDN

[easing]

影响 TTFB 最大的是 DNS ，然后是传输时间，尽量从这两个方面做改进