O'Reilly Velocity
Web Performance and Operations
› http://velocityconf.com/
YSlow
› Best Practices for Speeding Up Your Web Site
这是一个创建于 2860 天前的主题，其中的信息可能已经有所发展或是发生改变。
我的网站中很多的资源引用都是用的绝对路径，这会加重页面请求，网站成型后，现在改相对路径还来得及么= =感觉是个大工程啊……
 |
1
hupeng 2017-02-27 08:24:30 +08:00
TTFB 和资源文件的绝对，相对路径没有关系
|
 |
2
vertas 2017-02-27 09:01:16 +08:00
TTFB 主要花费在网络传输和服务器处理，其他关系非常小，所以你要从这两方便着手和路劲完全没关系！
|
 |
3
RihcardLu 2017-02-27 09:25:53 +08:00 via iPhone
做过相关优化，正如 2#所说，当时发现的问题是服务端某个查询执行次数过多，优化后正常，所以还是多从程序效率，数据库查询方面寻找瓶颈。
|
 |
4
Famio OP |
 |
7
wuxqing 2017-02-27 09:51:55 +08:00
chrome ， ctrl+shift+j ，然后在 Network 中点访问的 url ， Timing 里面可以看到 TTFB
其他浏览器我不熟悉，应该也有类似的 |
|
8
RihcardLu 2017-02-27 10:04:21 +08:00  2
@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 是不是嵌套太多等等 |
 |
10
ningcool 2017-02-27 11:48:33 +08:00
CSS ， js 等脚本资源的合并，以及页面是否压缩，很重要！因为 http 每一次请求都有很大的网络开销。当然，网页的那些动态处理和业务逻辑是你们自己的事情。
|
 |
11
otakustay 2017-02-27 11:58:48 +08:00
除非有 Server Timing 的支持，不然 TTFB 是没办法告诉你分阶段（ req - server - res ）的各阶段数据的，当然 req 和 res 这 2 个阶段可以考虑通过一些网络监听程度比如 wireshark 之类的去看
对于静态文件，由于 server 基本不会耗时，所以减少 ttfb 最简单的（对于很多人也几乎是唯一的）手段就是上 CDN |
 |
12
easing 2017-02-27 12:23:04 +08:00
影响 TTFB 最大的是 DNS ，然后是传输时间，尽量从这两个方面做改进
|
Select Language