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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

O'Reilly Velocity

Web Performance and Operations

› http://velocityconf.com/

YSlow

› Best Practices for Speeding Up Your Web Site

这是一个创建于 2831 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

路径

TTFB

请教

来得及

12 条回复 • 2017-02-27 12:23:04 +08:00

hupeng

2017-02-27 08:24:30 +08:00

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

vertas

2017-02-27 09:01:16 +08:00

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

RihcardLu

2017-02-27 09:25:53 +08:00 via iPhone

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

Famio

2017-02-27 09:27:30 +08:00

@hupeng @vertas @RihcardLu

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

BOYPT

2017-02-27 09:29:28 +08:00

@Famio 按 F12 啊

Famio

2017-02-27 09:44:27 +08:00

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

wuxqing

2017-02-27 09:51:55 +08:00

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

RihcardLu

2017-02-27 10:04:21 +08:00

@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

2017-02-27 10:08:25 +08:00

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

ningcool

2017-02-27 11:48:33 +08:00

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

otakustay

2017-02-27 11:58:48 +08:00

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

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

easing

2017-02-27 12:23:04 +08:00

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