根据方凳的分析，如果一个网站的页面加载时间在5秒钟或者更少，用户离开（以关闭页面为准）的比例应该不会超过20%，而超过了五秒钟，用户流失的比例会按照每秒1-2%增加。一般的电脑都能在3-10秒内完成页面的加载，对应表中的0-7秒，之后的，应该不算用户的流失，而是页面加载完后用户自然的离开。
方凳在进行访问的浏览器和分辨率测试的同时，也对中文网站的网站页面尤其是网站首页代码的大小和打开时间进行了一些分析。下面来看看分析结果：
首先是网页代码大小造成的用户数的流失，由于js代码执行机制的原因，数据不可能很准确，但是大致还是能提炼出一些东西来：
|
代码量大小
|
2008年6月15日 | 2008年6月14日 | 2008年6月13日 | 总pv | 用户流失总数 | 用户流失百分比 |
| 2k | 548868 | 672596 | 212949 | 1434413 | 0 | 0% |
| 36k | 523245 | 644369 | 208077 | 1375691 | 58722 | 4.09% |
| 115k | 516572 | 637191 | 205875 | 1359638 | 74775 | 5.21% |
| 158k | 502798 | 621595 | 201210 | 1325603 | 108810 | 7.59% |
| 197k | 463071 | 550193 | 120464 | 1133728 | 300685 | 20.96% |
柱形图：
折线图：
从以上图表可以看出，就中文网站而言，当代码量小于150k的时候，大概每20k的代码会造成1%的用户离开（包
括页面加载到一半发现自己需要的链接就点击走掉的用户），但是当页面代码超过150k的部分进行加载的时候，用户数出现大的波动，加载150-200k这
部分代码导致了13%的用户流失，如果代码量继续加大，相信用户流失的速度还会加快，所以一张页面应该不要超过这个额度太多。也就是说如果代码能控制在
150K之内用户流失会比较小。当然这个也和用户对这个页面的关注程度有关，如果是用户比较关心的页面，用户应该能够忍受相对较长的等待时间，如果是次要
页面，用户可能稍微等待下就会放弃。而offer_search_list页面的大小现在已经有250多k了，所以只能说大小要尽量控制，不能增加太多的
内容。当然，考虑到这个页面显示的都是用户自己搜索的内容，是用户比较关心的东西，所以，代码量和加载时间可以适当增加，具体能增加多少，最好还是能在
list页面埋点测试。
括页面加载到一半发现自己需要的链接就点击走掉的用户），但是当页面代码超过150k的部分进行加载的时候，用户数出现大的波动，加载150-200k这
部分代码导致了13%的用户流失，如果代码量继续加大，相信用户流失的速度还会加快，所以一张页面应该不要超过这个额度太多。也就是说如果代码能控制在
150K之内用户流失会比较小。当然这个也和用户对这个页面的关注程度有关，如果是用户比较关心的页面，用户应该能够忍受相对较长的等待时间，如果是次要
页面，用户可能稍微等待下就会放弃。而offer_search_list页面的大小现在已经有250多k了，所以只能说大小要尽量控制，不能增加太多的
内容。当然，考虑到这个页面显示的都是用户自己搜索的内容，是用户比较关心的东西，所以，代码量和加载时间可以适当增加，具体能增加多少，最好还是能在
list页面埋点测试。
接下来看第二份图表，是关于用户等待多少时间后离开中文站首页的测试：
| 用户等待时间 | 2008年6月15日 | 2008年6月14日 | 2008年6月13日 | 总pv | 用户离开数 | 用户流失总数 | 用户流失百分比 |
| 0s | 548868 | 672596 | 212949 | 1434413 | 0 | 0 | |
| 1s | 517284 | 634114 | 204363 | 1355761 | 78652 | 78652 | 5.48% |
| 1.2s | 470373 | 564647 | 176041 | 1211061 | 223352 | 223352 | 15.57% |
| 1.4s | 465150 | 557120 | 171312 | 1193582 | 240831 | 240831 | 16.79% |
| 1.6s | 464974 | 554446 | 168115 | 1187535 | 246878 | 246878 | 17.21% |
| 1.8s | 459157 | 549880 | 167074 | 1176111 | 258302 | 258302 | 18.01% |
| 2s | 458155 | 546901 | 164039 | 1169095 | 265318 | 265318 | 18.50% |
| 3s | 440902 | 528310 | 152456 | 1121668 | 312745 | 312745 | 21.80% |
| 4s | 422975 | 502413 | 139425 | 1064813 | 369600 | 369600 | 25.77% |
| 5s | 408054 | 484549 | 130301 | 1022904 | 411509 | 411509 | 28.69% |
| 6s | 397372 | 473274 | 123359 | 994005 | 440408 | 440408 | 30.70% |
| 7s | 387332 | 457790 | 115984 | 961106 | 473307 | 473307 | 32.99% |
| 8s | 373689 | 443707 | 110158 | 927554 | 506859 | 506859 | |
| 9s | 364758 | 431609 | 105686 | 902053 | 532360 | 532360 | |
| 10s | 356380 | 420338 | 101622 | 878340 | 556073 | 556073 | |
| 11s | 346172 | 408187 | 97686 | 852045 | 582368 | ||
| 12s | 340265 | 398810 | 94817 | 833892 | 600521 | ||
| 13s | 331595 | 389307 | 92104 | 813006 | 621407 | ||
| 14s | 323551 | 379556 | 89202 | 792309 | 642104 | ||
| 15s | 317446 | 370826 | 86539 | 774811 | 659602 | ||
| 16s | 310626 | 362525 | 84739 | 757890 | 676523 | ||
| 17s | 303212 | 355132 | 82602 | 740946 | 693467 | ||
| 18s | 298637 | 347826 | 80756 | 727219 | 707194 | ||
| 19s | 294931 | 341795 | 79104 | 715830 | 718583 | ||
| 20s | 293486 | 340078 | 78787 | 712351 | 722062 |
再看下用户离开数和等待时间的折线图：
由此可见刚开始的几秒钟，会有不少用户离开，个人觉得主要包括一些没有耐心的用户和那些页面加载了部分就找到了自己需要的内容的用户。接下
来从2s到10s用户流失率相对稳定，大概每一秒会损失1-2%的用户，而且这个比率会越来越小，因为有些用户是把网页打开就扔那不管，等一段时间再去看
的，而且这种人应该不少。还有一点要说的就是，由于js的机制问题，这张图的时间有些问题，这个时间是js开始执行的时间，而不是网页开始加载的时间，而
个人用自己电脑测了一下，js开始执行时间大概会比网页加载时间慢上2-3s，所以，也就是说，从上面的图表分析，如果网页加载时间在5秒钟左右，用户离
开的比例应该低于20%，超过这个时间，用户离开比例会按照每秒1-2%增加。一般的电脑都能在3-10秒内完成页面的加载，对应表中的0-7秒，之后
的，应该不算用户的流失，而是页面加载完后用户自然的离开。
来从2s到10s用户流失率相对稳定，大概每一秒会损失1-2%的用户，而且这个比率会越来越小，因为有些用户是把网页打开就扔那不管，等一段时间再去看
的，而且这种人应该不少。还有一点要说的就是，由于js的机制问题，这张图的时间有些问题，这个时间是js开始执行的时间，而不是网页开始加载的时间，而
个人用自己电脑测了一下，js开始执行时间大概会比网页加载时间慢上2-3s，所以，也就是说，从上面的图表分析，如果网页加载时间在5秒钟左右，用户离
开的比例应该低于20%，超过这个时间，用户离开比例会按照每秒1-2%增加。一般的电脑都能在3-10秒内完成页面的加载，对应表中的0-7秒，之后
的，应该不算用户的流失，而是页面加载完后用户自然的离开。