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