阅读:7096回复:22
关于ff页面打开问题的终极解决兼提速
第一次发帖,有点啰嗦,请见谅。
用ff已经有2,3年了。刚开始属于尝鲜,渐渐有了兴趣,后来装了几样扩展,迅速成为忠实使用者。平时经常要来论坛里逛逛,不过一般都不冒泡。前几天看到坛子里有一个关于第一次打不开页面的帖子,深有感触,因为我曾为这个问题困扰很长时间,特别是在ff2.x版本中,表现的更为严重,3.x版稍微好一点,但仍存在。我这里有时第一次打不开页面,有时虽然能打开,却是吭吭哧哧,拖泥带水,进度指示旋转半天仍在那里旋转,就是载入不全。同时,又和网络问题交织在一起,很难找到原因。经过不懈摸索,最近终于找出问题所在,特将我的心得写出来,供大家,特别是深受页面打开之苦的人参考。 首先要说的是,在浏览器的速度问题上,解析和渲染是两个不同的侧面。渲染是表面现象,解析才是根本问题。浏览器拼速度,主要是看解析的速度。现在网络上ff提速的文章到处都是,许多常常是将两者混淆起来,有的甚至是本末倒置,在开始的时候,我就受过这种误导,在优化的过程中走了弯路,下面要说的是一些常见的问题。 第一个问题,关于pipeline.这不是主要问题,但有必要说一下。许多文章首先就要你打开pipelpne,有的还很夸张,甚至离谱到了把数值开到80,这绝对有害无益。在我的印象中,pipeline从来没有解决我实际遇到的问题。况且我现在不开pipeline,也可以在载入时把带宽撑破(2M),即使是米国的网站也每每如此,那我为什么还要开pipeline?纵观现在的浏览器,包括chrome,都是默认不开pipeline的,默认开pipeline的,似乎只有opera一家。而 opera——不是我看不起opera,虽然它的手持版做的很棒。我确实有点看不起opera,一股小家子气。 第二个问题,关于nglayout.initialpaint.delay.许多文章要求把这个值降为0。这看似完美,实际上,大大的有问题。这个参数表示,在ff开始渲染页面之前,需要等待多长时间。我们知道,打开一个页面,首先是要载入,然后解析,最后才是渲染。如果让ff在刚刚开始载入的时候就开始渲染,无疑会对前两个过程带来不利,进而拖累表现。这个值,ff的默认值是250,在我这里是2000,实际使用中,许多页面常常是一瞬间就打开了,并不会等到2秒。ff也表示,调高数值会加快页面的整体打开速度。 第三个问题,Content.interrupt.parsing。这个值表示在ff解析的过程中,是否调低速度以响应界面事件,比如键盘动作。许多文章设为true,并设计了一系列不同的数值,让人眼花缭乱。我认为不管数值怎样设计,都会降低解析的速度,所以,应该false。放心,对使用不会有任何影响。 第四个问题,content.notify.ontimer。ff在页面渲染的过程中,仍会有新的内容不断的载入。因此,要不断的回流,来解析新的内容,这会极大的减缓打开的速度。当这个值为true时,表示按一定的时间段回流,为false时,表示一有新的内容就回流。默认为false,我这里是true。 然后,定义回流间隔的时间,content.notify.interval,为2000000,即2秒。 最后一个数值,也就是最最关键的数值,正是因为它的出现,一举解决了所有问题。当上述参数设好以后,你会发现,出现了一个新的参数,content.sink.event_probe_rate,这个参数,google上面搜不到相关内容,所有的提速教材里面也都未提及。从字面上看,表示对内容提取的速率,应该是指,在一定的时间段内,来提取载入的内容以供解析的速率。这个数值很关键,如果速率过小,会降低网络响应的速度,这正是问题的主要原因。而如果速率过快,会加重解析的负担。那么,这个时间段是多少呢,我想,应该是定义回流间隔的时间,因为正是在那个值出现以后,这个值才出现的。默认值是3,显然太保守。如果按每0.1秒来提取一次的话,我这里就是20。 好了,经过上述调整以后,你的firefox已经彻底脱胎换骨,重新做人了。每一次打开页面都干脆利落,不再半途而废。忘掉chrome吧,firefox从此也有傲人的速度,还有那么好的扩展。你会发现,firefox从未如此完美过,你从未如此喜爱过firefox. |
|
1楼#
发布于:2009-10-09 23:06
飞一般的感觉。
|
|
2楼#
发布于:2009-10-09 23:06
我感觉,在兼顾稳定性的前提下,firefox默认的速度已经是尽了全力了。与chrome相比,更深层次的原因是引擎问题。所谓鱼与熊掌不可兼得,如果用起来顺手,不必在乎那一两秒的差别。 |
|
3楼#
发布于:2009-10-09 23:06
daocaoren722:content.notify.ontimer 我在过滤器中输入,内容没有查找出来,不知是怎么回事,望高手解答一下。回到原帖 没有说明是默认值(我觉得.). 点击新建即可 |
|
|
4楼#
发布于:2009-10-09 23:06
content.notify.ontimer 我在过滤器中输入,内容没有查找出来,不知是怎么回事,望高手解答一下。
|
|
5楼#
发布于:2009-10-09 23:06
|
|
|
6楼#
发布于:2009-10-09 23:06
|
|
7楼#
发布于:2009-10-09 23:06
精简扩展比较有用
|
|
8楼#
发布于:2009-10-09 23:06
用lz的设置,感觉慢了。刚狗狗了下,搜了篇文章,结合lz的一些设置,感觉速度还不错。
------------------------------------------------------------------------------------- 1.network.http.pipelining 在 Filter 中输入 network.http.pipelining,双击赋值为 true,默认为 false。如果没有找到这个键值,可以右键新建一个 Boolean,把她赋值为 true 就 OK 了。 还是像我在从前解释过的那样,激活这个键值之后,Pipelining同时发出成倍数的连接请求,从而达到提升连接速度的效果。 网络上的大多数网站都是基于 HTTP 协议,而 HTTP 1.1可以支持多线程的连接请求,通过这个操作可以减少Firefox载入网页 的时间。不过并不是所有网页所在的服务器都支持这种操作,所以当你修改键值之后却看不到一点实际效果的时候,请不要对 我破口大骂。 2.network.http.pipelining.maxrequests 在 Filter 中输入 network.http.pipelining.maxrequests,双击并赋值为 8,默认键值为 4。 3.network.http.proxy.pipelining 在 Filter 中输入 network.http.proxy.pipelining,双击并赋值为 true。 这两条优化的道理同上,这里就不再多解释了。 4.network.dns.disableIPv6 在 Filter 中输入 network.dns.disableIPv6,双击并赋值为 true。 IPv6 把 IP 地址由 32 位增加到 128 位,从而能够支持更大的地址空间,当用户在终端向一个 IPv6-capableDNS服务器发送连接请 求时,也许服务器端会错误的返回给用户一个 IPv4 地址。而 Firefox 可以对这一切明察秋毫,不过在Firefox纠错的同时也必然会导 致信号的延迟,所以这里我们把她赋值为 true,禁用掉她。 5.content.interrupt.parsing 右键新建 Boolean 值,键名为 content.interrupt.parsing,赋值 true。 默认这个键值并不存在。我们激活这个键值之后,当目标网页载入时,Firefox会根据一定频率打断解析的过程,不断的向用户反馈她 所收集到的网页信息,有点像流媒体的意思。这时的 Firefox很聪明,不会一根筋的一直钻牛角。在下面的内容中我还会具体讲一下这 个键值的魅力所在。 6.content.max.tokenizing.time 右键新建 Integer 值,键名为 content.max.tokenizing.time,赋值 2250000。 这个键值的作用其实就是指定一个循环事件的处理周期,这里的单位是微秒,要是我没有算错的话。理论上当我们将这个值取的越小, 网页就会从视觉上载入的越流畅,因为Firefox会在很短的单位时间里反馈回解析到的网页信息。可是这样无疑延迟了网页整体载入的 时间,所以在这里我们不妨将这个周期取的大一些,理论上可以加速网页的载入。 7.content.notify.interval 右键新建 Integer 值,键名为 content.notify.interval,赋值 750000。 载入一个网页其实也是一门很大的学问。让我们来放一个慢动作,我们姑且先把在终端第一次收到的网页信息很不专业的叫做预载入页 面吧,这个页面有可能是不完整的图片或者文字,或者别的媒体文件。从我们第一次向远端主机发出连接请求到我们在终端收到这个预 载入页面花费的时间,就是这里我们要定义的键值。理论上当我们将这个时间设置的很低时,肯定会更快的拿到所谓的预载入页面,可这 是一种杀鸡取卵的做法,这样无形中反而增加了我们整体页面的载入时间。按照官方的说法,低于 100,000 将会降低 Firefox 的性能, 那好吧,那我们把她彪到 750000 吧。 8.content.notify.ontimer 右键新建 Boolean 值,键名为 content.notify.ontimer,赋值 true。 为了使我们上面设置的 750000 微秒生效,还需要把这个键值激活。只有这两个键值配合,才会起作用。 9.content.notify.backoffcount 右键新建 Integer 值,键名为 content.notify.backoffcount,赋值 5。 这个键值控制Firefox的内置计数器在归零之前载入页面返回的次数。我们将目标网页分成好多个部分进行下载,每下载完一个部分, 计数器归零一次。-1就是没有限制,值为 0时这项功能被禁用。这里我们将她设置成5,当返回的次数达到五次而这部分网页还没有完 全下载完时,那么剩下的没有下载完的网页内容将不会再按照我们预告设置的周期,像之前的五次那样一点一点的搬运回来,而是会一 次性的下载完。也就是说在这个部分的网页下载过程中,Firefox 一共向我们反馈了 6 次信息,前5次的时间间隔是我们在上面的键值 中设置的周期 2250000 微秒,而第6次也就是最后一次则没有时间限制,什么时候把剩下的下完了,什么时候反馈回来。 只有当我们在上面提到的 content.notify.ontimer 键值为 true 的时候,这里的设置才会生效。 10.content.switch.threshold 右键新建 Integer 值,键名为 content.switch.threshold ,赋值 750000,也就是四分之三秒。 在 前面我们提到了一个键值 content.interrupt.parsing,通过激活她实际上我们可以在载入页面的过程中跟Firefox产生互动,毕竟 我们每一个人的心里都充满了爱。把 content.interrupt.parsing 激活后当页面载入时Firefox会有两种操作模式:高频和低频中断模 式。使用高频模式时,网页回馈的频率也很高,我们坐在显示器前看到的网页载入过程也会更加的平滑。低频时网页回馈的频率相对比 较低,可是这时反而加快了网页载入的时间。当我们移动鼠标或者触击键盘时,高频模式被激活。在经过某一段时间我们没有碰鼠标 和键盘,程序没有接到鼠标和键盘发出的任何指令时,Firefox 就会自动进入低频模式工作,而这所谓的某一段时间,就是我们这里要 指定的值。 11.nglayout.initialpaint.delay 右键新建 Integer 值,键名为 nglayout.initialpaint.delay,赋值 0。 这里实际上延迟了整个网页的显示速度,但是因为用户更喜欢在整个网页完全截入之前就开始阅读网页 (就像流媒体那样),所以在这 里可以把值调为零,加速用户阅读网页的速度,有时候阅读速度和载入速度并不是成正比的。 在网络状况稳定的情况下这些优化的确是会起到一些效果的,并不光是心理作用,大家在为自己的浏览器提速时,也可以稍微参考一下。 ------------------------------------------------------------------------------------- |
|
|
9楼#
发布于:2009-10-09 23:06
试了一下,有些网页打开的速度反而变慢了,现在开始继续默认参数。
|
|
10楼#
发布于:2009-10-09 23:06
楼主这两个参数是怎么设的?
content.max.tokenizing.time content.switch.threshold |
|
|
11楼#
发布于:2009-10-09 23:06
|
|
12楼#
发布于:2009-10-09 23:06
有一些明显的感觉
只是家里512K网路,不知道再怎么优化还能整出什么宝贝来 |
|
|
13楼#
发布于:2009-10-09 23:06
content.sink.event_probe_rate
=== 这个参数firefox默认是没有的? 至少我用的3.6beta没有. |
|
|
14楼#
发布于:2009-10-09 23:06
标记一下,晚上回去再做测试。
|
|
上一页
下一页