上图可以看出：ajax请求加载页面时，尽管会获取的内容很小（几百B）但是网络相应时间却非常长，主要集中在waiting（TTFB）

waiting（TTFB）解释:
从客户端开始和服务端交互到服务端开始向客户端浏览器传输数据的时间（包括DNS、socket连接和请求响应时间），是能够反映服务端响应速度的重要指标，获取在接收到响应的首字节前花费的毫秒数。

本次主要从程序方面来分析：即服务器接受请求开始到返回数据给客户端为止
1、看页面ajax请求的页面是否本身加载速度很慢
2、在页面请求过程中，除了本身请求的商品数据之外，是否还有其他的内容需要加载
3、解决上述两点问题，观察页面的响应时间

解决办法：
1、通过xhprof来进行性能分析，发现商品信息加载只耗费了43ms左右的时间，钩子中的商城数据消耗约417ms的时间，对钩子数据接口进行缓存，将钩子的请求时间降到45ms左右
重新观察页面，部分ajax请求的时间仍然在1-2s左右。

2、试着减少页面的ajax强求，发现响应时间会有变化，怀疑页面ajax请求过多导致，google：AJAX请求使PHP反应时间过长的问题。

PHP自带Session隐患(session文件独占锁引起阻塞)：当服务器发送一个Ajax请求时，PHP脚本开启了session_start()，它的调用会锁定PHP的session文件。PHP默认会把session数据存储在服务器上的文件中。因为仅仅只有一个PHP请求能改变同一个session文件，两个同时的PHP请求可能会造成典型的文件锁条件。

大部分PHP框架会首先在主文件中使用session_start()。因此，如果使用会调用session_start()的框架或者函数库，将会造成session文件锁，对于使用同一个浏览器的相同用户，这将延迟同时发送的Ajax请求。

结合了PHP的Session机制，找到了阻塞的原因。由于PHP的Session信息是写入文件的，1个客户端占有1个session文件。因此，当session_start被调用的时候，该文件是被锁住的，而且是以读写模式锁住的（因为程序中可能要修改session的值），这样，第2次调用 session_start的时候就被阻塞了。

最简解决方法：
PHP的手册session_write_close函数，作用是Write session data and end session。因此，我们可以在用完session之后，调用这个函数关闭session 文件即可解除锁定。

调用session_write_close()之后，当前脚本会继续正常运行，但在调用session_write_close()之后不允许改变任何session变量；在同一个脚本中，其它同时发送给PHP的请求可以锁定session文件并改变session变量。

备注：
session数据通常会在脚本执行结束后被保存，而并不需要调用session_write_close(),但是为保护session在任何时候都只能被一个脚本执行写操作，session的数据会被锁住。当同时使用框架网页和session时你会发现，框架里的网页会因为这个个锁定而逐个载入。可以通过在所有的session数据修改保存结束后马上结束session来加快载入时间。