快速响应 – Firefox 13 的性能优化

早在 2011 年秋季,我们针对性地研究了 Firefox 的响应能力问题。我们确定了一些短期项目,这些项目可以共同实现日常 Firefox 使用中的显著响应能力改进。Snappy 项目在年底启动,其目标是提高 Firefox 的响应能力。

虽然 Snappy 最初为 Firefox 11 提供了修复程序,但 Snappy 目前为止最明显的贡献将与 Firefox 13 一起发布。目前处于测试版阶段,此版本包含了许多与响应能力相关的修复,最值得注意的是按需加载标签页、循环收集器改进和启动优化。

按需加载标签页

按需加载标签页是一项功能,可减少具有多个标签页的 Firefox 窗口的启动时间。在 Firefox 12 中,所有标签页都在启动时加载。对于具有多个标签页的窗口,这可能会导致延迟,因为每个标签页都必须加载其内容,然后才能与 Firefox 交互。在 Firefox 13 中,只有活动标签页会加载。后台标签页的加载会推迟到选中标签页时。这样,Firefox 就能更快启动,因为按需加载标签页可以减少处理要求、网络使用量和内存消耗。

循环收集器

在您与浏览器和 Web 内容交互时,会根据需要分配内存。Firefox 循环收集器会自动释放不再需要的部分内存。此操作可以减少 Firefox 的内存使用量。在 Firefox 13 中,循环收集器效率更高,在检查仍在使用的内存时花费的时间更少,从而减少您使用 Firefox 时的暂停次数。

启动

所有用户都能感受到 Firefox 的启动时间。我们对启动的调查发现,代码中有一些未优化的例程会在我们所谓的“首次绘制”之前执行。“首次绘制”表示 Firefox 用户界面首次出现在屏幕上的时间。在 Firefox 13 中,我们优化了文件调用、音频会话、拖放以及整体 IO,仅举几例。我们正在继续分析 Firefox 启动序列,以识别未来版本中可以进行的进一步优化。

Firefox 13 中还有许多其他 Snappy 修复,包括对 IO 争用、字体枚举和 Livemark 开销的重大改进。所有这些修复都有助于提供更具响应性的体验。我们已经在为未来的 Firefox 版本开发更多响应能力修复程序。您将在即将发布的版本中看到 Snappy 在内存使用量、关闭时间、网络缓存和连接、菜单以及图形等方面的改进。

关于 Lawrence Mandel

Firefox 工程项目经理

Lawrence Mandel 的更多文章...


61 条评论

  1. Andy

    Chrome 在启动时似乎作弊,您会看到一个几乎立即绘制的界面,但实际上您无法进行太多操作,如果您在其中输入一个 URL,则没有历史记录,并且实际上转到该 URL 可能需要几秒钟的时间。

    尽管我知道这一点,并且理性地思考了这一点,但我发现,从启动到“进入 google.com”的时间与 Firefox 并没有太大的不同,但我更喜欢这种方式。

    FF 有计划这样做吗?

    2012 年 5 月 11 日 凌晨 3:49

    1. Abhay Rana

      是的,我认为这是一个非常好的 UX 设计选择。尽管在那些 5-6 秒内它没有按预期响应,但它总是让人感觉很好,因为我知道 Chrome 已经启动了。

      2012 年 5 月 11 日 上午 7:06

  2. Alec

    我不想这么说,但你们真是太晚了。你们现在才认真看待性能问题,而这些问题已经让你们的用户成群结队地转向速度更快的替代方案,这种情况已经持续了多年?

    总比没有强吧。至少你们支持“text-size-adjust”!

    2012 年 5 月 11 日 凌晨 4:51

    1. Hans

      @alec,我认为你的评论太晚了。Chrome 仍在努力解决这个问题。有趣的是,他们正在将 Firefox 的解决方案作为参照范例。
      http://code.google.com/p/chromium/issues/detail?id=105666

      顺便说一下:FF 中已经有了这个功能 - 您需要在“常规”选项卡中选择启用。

      2012 年 5 月 28 日 上午 10:38

  3. smaug

    最重要的循环收集优化(在 forget-skippable 阶段执行黑位传播)已在 FF12 中实现。FF13 及更高版本有一些额外的修复程序,可以保持循环收集时间较短。

    2012 年 5 月 11 日 上午 6:35

  4. pd

    不幸的是,“按需加载标签页”这个词用得不太恰当。它实际上应该称为延迟加载标签页。我希望 Mozilla 不要扭曲他们的选择。我更希望 Mozilla 像 Dogbert 一样,而不是像尖头经理一样。

    “启动”方面的变化听起来像是合法的变化,这将建立在之前的工作基础上,例如通过将大量文件放入 omni.ja 来简化文件 IO,而延迟加载标签页听起来像是对用户的性能损害,而不是性能提升。它只是用更快的首次绘制换取了更慢的二级标签页和后续标签页的加载速度。

    如果延迟加载标签页将成为长期策略,那么它是否实际上会完全颠覆标签页浏览的最大优势?我个人通过快速拖动将标签页拖动到新的后台标签页中来打开标签页,以便在阅读完文章后,我可以继续访问已经加载的页面,而无需等待它们加载。

    我可以理解为了与其他浏览器竞争而需要做出立即的短期性能改进的选择,但我们不要假装延迟加载标签页比短期提升性能的尝试更重要,而长期的真正解决方案是修复 IO 争用等细枝末节,以及您列出的其他更改。

    2012 年 5 月 11 日 上午 7:54

    1. Lawrence Mandel

      按需加载标签页只在启动时对后台标签页有效。您提到的场景,即快速拖动标签页到后台标签页以便稍后阅读,将继续按当前方式工作。将创建新标签页,并加载内容。

      2012 年 5 月 11 日 上午 8:43

    2. 神秘的 Andy

      @pd:您是否知道您评论的语气往往是“假设有恶意目的;指责和谴责”?

      2012 年 5 月 15 日 上午 9:29

  5. Steve Price

    应用程序标签页呢?我在 Vista 和 Ubuntu 上使用 Aurora。虽然 Ubuntu 响应速度更快(这并不奇怪),但我所有的应用程序标签页在启动时似乎都在竞争加载。在 Vista 上,尤其是在启动后的驱动器运转期间,启动时间非常令人痛苦。应用程序标签页按需加载是否在计划中?喜欢这个博客,我每天都阅读!

    2012 年 5 月 11 日 上午 8:15

    1. kwierso

      应用程序标签页被认为是您始终想要加载的,因此它们始终在启动时恢复。

      在 about:config 中确实有一个隐藏的首选项可以停止此操作。我没有这个首选项的名称,但您应该可以通过筛选“tab”来找到它。

      2012 年 5 月 11 日 下午 6:38

  6. Mike B

    我一直在使用测试版,发现启动时的延迟加载是一件好事,但在正常浏览会话中,它会非常令人讨厌,因为它消除了打开后台标签页的大多数好处。IMO,这应该只在浏览器启动时使用这种行为,但在正常浏览会话中应该像往常一样加载后台标签页。

    我理解您的意图,但它破坏了当前的使用效率。请考虑只在浏览器启动时实现它。

    2012 年 5 月 11 日 上午 8:32

    1. Mike B

      我还应该注意到,即使在浏览器启动时,一旦当前标签页完成加载,后台标签页也应该加载,或者应该提供一个选项。

      2012 年 5 月 11 日 上午 8:38

    2. Lawrence Mandel

      在我的日常浏览中,后台标签页确实像您所描述的那样,用于“正常浏览会话”。您能否描述一下导致您看到这种行为的步骤?如果您是 Bugzilla 用户,请打开一个错误报告!

      2012 年 5 月 11 日 上午 8:51

      1. Mike B

        我回家后会再检查一下,我在工作时运行的是稳定版本。我可能看到的是一个在启动时打开但尚未访问的标签页的加载,而不是在该会话期间打开的标签页的加载。

        在这种情况下,我认为在浏览器加载时,后台标签页应该在后台加载,但只有在前景标签页完成加载之后。

        不要误会,我非常赞赏浏览器变得越来越好,最近几个版本中内存管理得到了极大改善。我是 Firefox 的忠实粉丝,虽然标签页问题一直是个小烦恼,但我认为这是因为我使用了测试版。如果我能重现这个问题,我会提交一个错误报告。

        2012 年 5 月 11 日 下午 2:35

        1. Mike B

          快速更新一下,是我没有访问过的启动时标签页;在后台打开的标签页在我切换到它们之前就已经完全加载了。

          2012 年 5 月 11 日 晚上 7:57

  7. Rami

    以前我可是 Firefox 的铁杆粉丝,走到哪都会跟人说 Firefox 最棒,我是个网页开发者,整天都在浏览器里工作,从浏览网页到 Facebook,当然还有最重要的工作,Firefox 就像个吃内存的怪兽,疯狂吞噬内存,而且用 FireBug 的时候简直慢得要死,后来我换成了 Chrome,快多了,Chrome 的开发者工具虽然一开始有点痛苦,但我现在更喜欢它而不是 FireBug。关键是,你们用优秀浏览器引领了这一潮流,从 Netscape 时代到 Firefox 时代,你们干掉了丑陋的 IE,向世界展示了一个好浏览器应该多么重要,多么出色,但后来,我想 Firefox 规模越来越大,参与的人也越来越多,遗憾的是,这反倒让它成了一个糟糕的浏览器,R.I.P. Firefox,我会怀念你的,我的朋友。

    2012 年 5 月 11 日 上午 8:46

  8. Wayne

    > 在正常的浏览过程中,这种延迟加载会变得非常烦人,因为它消除了打开后台标签页的大部分好处。在我看来,这种行为应该只在浏览器启动时使用,但在正常的浏览过程中应该像往常一样加载后台标签页。

    我完全同意。

    2012 年 5 月 11 日 下午 12:37

    1. cuz84d

      实际上,Wayne,它根本不会从会话恢复开始加载标签页。但正常的浏览方式仍然一样。这种改进是为了让启动速度更快,但如果你根本不看其他标签页,为什么要加载它们?但当你想看的时候,你点击那个标签页,它就开始加载了。现在更好的方法可能是包括某种延迟加载,它是并发的,这样就可以从当前标签页开始,一次加载一个页面,并在你使用浏览器时继续加载后台标签页,而不会像现在这样一次性加载所有标签页,导致过载。

      2012 年 5 月 11 日 下午 1:07

      1. cuz84d

        呃,抱歉,我的意思是它可以允许在启动后按顺序加载一些标签页,如果你真的希望标签页继续加载而不必点击每一个标签页,但不要像现在没有按需加载标签页时那样,同时加载所有标签页。

        2012 年 5 月 11 日 下午 1:15

  9. 建议

    Firefox 应该专注于以下方面:

    – 最佳隐私选项。Google Chrome 甚至不愿意给用户更多隐私。确保用户免受追踪 Cookie 和类似东西的影响。我知道你从 Google 获得了很多钱,但如果可以,你应该专注于此。几年后,当用户厌倦了被跟踪和监控时,他们会想要的。我们中的一些人已经厌烦了。

    – 最佳插件支持。你已经做到了。只需在需要的地方进行改进。

    – 最佳跨平台体验。你已经在路上了,但 Linux 上的默认 Firefox 比 Chrome 更丑。外观很重要。你应该解决这个问题,因为它很容易做到。

    – 强力的 HTML 5 支持

    – 快速启动时间,尤其是在移动版本上。这对成功至关重要!

    – 停止做那些没人关心毫无意义的事情。你的资源有限,所以专注于你的优势。

    2012 年 5 月 11 日 下午 1:08

    1. Alex

      “停止做那些没人关心毫无意义的事情。你的资源有限,所以专注于你的优势。” [原文如此]

      与此同时,这是一个开源项目,所以大多数贡献者并没有得到任何报酬。如果他们选择一些你认为“没人关心”的事情来做,绝对不会有任何损失。

      2012 年 6 月 5 日 下午 3:12

  10. Hogart

    不要让像 Alec 这样的人打扰你。他们显然没有关注,我们很多人感谢你还在继续给 Chrome 和 Opera 带来压力。我们都知道他这样的人,只要另一个闪亮的浏览器出现,就会马上跳船,所以不要理会他的捣乱。

    2012 年 5 月 11 日 下午 1:43

    1. taylerz

      我想继续 Hogart 的评论。也忽略 Rami 吧。他们没有关注。Firefox 在过去一年里变得快多了,不仅仅是现在。我给了 Chrome 两次机会,最近的一次持续了一周,但我还是发现自己回到了... Firefox!

      2012 年 5 月 12 日 上午 6:01

    2. Erunno

      但 Alex 是对的。Mozilla 拖延了很久,直到他们开始认真而有条理地解决像内存使用 (MemShrink) 和界面响应速度 (Snappy) 这样的问题。前一个项目始于 2011 年年中,后一个项目始于 2011 年末,他们可能要到 2013 年才会完成这些项目(再加上他们进入稳定通道的时间)。考虑到 Chrome 于 2008 年 9 月首次出现,并在许多用例中设定了感知和实际性能的标准(尤其是那些与普通用户相关的问题),这已经是相当长的时间了。想象一下,如果 Snappy 和 MemShrink 都在 2009 年开始,那么 Mozilla 可能就不会损失那么多的市场份额和认知份额。

      2012 年 5 月 12 日 下午 11:25

  11. Todd

    最近我发现自己比 Firefox 更常使用 Safari。我想使用 Firefox,但我发现 Mac 版本并没有像 Windows 版本那样得到那么多关注。

    我希望有一个更新的界面,或者一些 Lion 的调整,比如前后手势、真正的全屏模式和 iCloud 书签同步! :)

    2012 年 5 月 12 日 上午 7:14

    1. Ahmad

      哈哈!我们 Windows 用户抱怨说 Mac 从 Firefox 获得了更多关注。

      2012 年 5 月 12 日 下午 11:16

    2. Jean-Yves Perrier

      真正的全屏模式将在 Firefox 14 中推出(如果一切顺利)。目前它正在 Aurora 通道上进行测试。

      2012 年 5 月 13 日 上午 0:28

  12. Sandro

    按需加载标签页是一个很棒的消息。我已经等了它好几年了……

    2012 年 5 月 12 日 上午 7:25

  13. eddie

    这周我的笔记本电脑无法使用,我启动了任务管理器,发现 Firefox 占用了 4 GB 的内存。我受够了。我已经对 Firefox 把我的 i7 变成 80486 很生气了。我现在已经从所有电脑上删除了 Firefox。

    在相同的工作负载下,Chrome 占用的内存与 Firefox 一样多,但 Chrome 将负载分散到各个进程中,因此电脑仍然响应,不像 80486 那样,也不会启动我的交换分区的大量磁盘活动。

    只有一个进程或只有几个进程,这种做法无法扩展,即使你懒加载标签页,让你的垃圾回收器变得更智能(类似 JVM),切换到 jemalloc 或完全重新思考 spidermonkey/tracemonkey。我不会再回到 Firefox,因为我不想再进行交换了。

    现在,Mozilla,该你行动了。

    2012 年 5 月 12 日 下午 2:23

    1. Ferdinand

      “现在,Mozilla,该你行动了。”
      你错了,该你行动了。要么换一个新的浏览器,要么修复你的 Firefox。你一定看到了来自独立网站的测试结果,证明 Firefox 使用的内存最少。所以你的结论应该是:要么我在 Firefox 中发现了一个极其罕见的错误,要么我应该尝试一个新的配置文件。

      2012 年 5 月 14 日 晚上 10:14

    2. alexleduc

      我比你更像铁杆粉丝,所以要让我换浏览器需要更多的东西(即使在 NS4 比 IE4 更强大的情况下,我当年也出于固执使用 NS4,尽管我认为 IE4 更强大)。也就是说,我也开始感受到各种性能问题的困扰。

      具体来说:
      – 磁盘(交换?)访问过多。与其他浏览器不同,FF 似乎经常会变慢,你听到硬盘像疯了一样狂转。

      – 标签页/UI 经常会因为加载某个页面而暂时卡死。

      – 从 FF4 开始,YouTube 视频经常无法加载(在不同电脑上测试过)。

      我发现自己越来越倾向于使用 Chrome(Iron)来访问某些网站(尤其是 YouTube),虽然还不至于让我完全换浏览器,但现在我越来越经常地思考这个问题了。

      2012 年 5 月 28 日 上午 7:58

  14. Enrique

    好消息!Firefox 在 Intel 硬件上运行时已经非常快了(我认为人们在抱怨 Intel Core Duo 上的性能问题时有点偏执,因为大多数时候我们说的是几十秒)。不过,我正在使用 ARM 设备开发一个项目,该设备的缓存很小(128/256 KB 缓存与 Intel 的 2-6 MB 缓存相比),时钟频率也很低(0.8 GHz),任何优化都物超所值。尤其是与缓存优化相关的一切。任何可以节省 1 KB 可执行代码的重构工作都可以显著提高性能和响应速度。

    祝贺你们,继续你们的伟大工作!

    2012 年 5 月 13 日 上午 2:28

  15. Christopher Thomas

    我认为他说的是用 10 个标签页打开 Firefox,根据我理解上面的文章,1 个标签页会立即加载,而 9 个标签页会按需加载。

    所以,如果我在 5 分钟后读完第一个标签页,然后切换到第二个标签页,那么它必须在切换到它的那一刻加载并运行内容。

    它不会加载好并准备好了,我认为这就是他的意思。

    2012 年 5 月 13 日 上午 8:33

  16. Ken Vermette

    为什么这些评论里充满了无端的仇恨?我读下来,要么是“你应该几年前就做这个”,要么是“你应该关注其他事情!”,“我现在用 XYZ 因为 Firefox 太大了”,“当我使用 X 插件时 Firefox 很慢”,“我不喜欢它做 X 的方式,所以我不用它”。

    对很多人来说重要的功能,对现实世界中的用户来说却并不重要。我是一名网页开发者,我喜欢可以定制 Firefox 来做瑞士军刀一样的事,但我不会说花 4 万美元一年雇人开发工具是明智之举。线程、Mac 支持、Windows 支持、Linux 支持、尚未发布的 HTML 标准、性能等等也一样。

    你可以为每项工作雇五个人,但并不能保证每年数十万美元的成本会“解决”所有人们抱怨的问题。

    事实是,运行那些已知需要更多 RAM 的插件,然后抱怨“Mozilla 没有修复我的 RAM”是不会解决任何问题的。也许可以开始使用配置文件功能,一个用于开发,另一个用于休闲浏览。你不需要 24/7 开启 Firebug。不要在 netbook 上打开 47 个标签页。明白,完美的 KDE/Gnome/XFCE/Ratpoison 集成并非他们的首要任务。明白,“速度快”可能不如“功能齐全”重要。

    彻底改造 X、Y 或 Z 可能是好主意,但与其他更大的目标相比,它可能不值得。最后,如果你因为某些随机原因或某些插件在你使用时行为异常而停止使用 FF,可以到适当的地方报告这些问题:人们来这里是为了阅读关于真正有趣增强功能的讨论,提出问题,并提供关于 Snappy 的想法/反馈。我们不想读到你关于无关主题的一般性抱怨。

    所以,在我被抱怨声淹没之前,我想问的是……

    Firefox 启动并完全运行后,它会开始加载未加载的标签页吗?先启动 UI,加载第一个页面,然后在准备好后后台加载其他标签页?如果 Firefox 在崩溃后启动,标签页按需功能会有所不同吗?

    Snappy 开发者们干得好!

    2012 年 5 月 13 日 下午 10:59

  17. sulfide

    FF 安息吧。它存在的时候很不错。现在你太慢了,而且占用了大量的内存。你们的开发者走进了太多无意义的方向,忘记了做重要的事情。他们也毁了你的 UI :(

    2012 年 5 月 13 日 下午 11:47

    1. Wes

      哦,你。

      2012 年 5 月 13 日 下午 15:24

    2. edm

      Firefox 现在拥有与 Chrome 和 IE 相似的 UI。我不知道这是否意味着它被毁了,但在 Chrome 和 IE 中,你完全被 UI 束缚住了。在 Firefox 中,你可以自定义它,并按照你想要的方式进行。所以,在我看来,如果你不喜欢新的 Firefox UI,那么你唯一的选择是… Firefox… 真是讽刺!

      2012 年 5 月 24 日 下午 14:59

  18. John Meher

    我仍然是 Firefox 的铁杆粉丝!!!我希望我能看到更多稳定性,我在浏览器上度过了我的白天,我已经看到了最新版本的一些问题,我总是害怕更新,因为我忠实使用的插件一个接一个地被淘汰。尽管如此,我仍然期待 Firefox 的未来!开源万岁!!!

    2012 年 5 月 13 日 下午 23:21

  19. benjamir

    我使用 FF 11:“标签页按需”通过首选项启用(在打开上次会话时不加载)。

    所以 FF12 或 FF13 最显著的“新”功能不可能是标签页按需。

    2012 年 5 月 14 日 上午 00:55

    1. Lawrence Mandel

      正如你所说,标签页按需在以前版本的 Firefox 中被预设为关闭。在 Firefox 13 中,此功能现在预设为开启。这使得 Firefox 13 成为第一个让大多数用户体验标签页按需功能的版本。

      2012 年 5 月 14 日 上午 09:14

    2. Joseph

      感谢你提出来;我以为是我疯了。我同意你的观点,将一个首选项从关闭切换到开启可能是一个改变,但不是一个新功能。

      2012 年 5 月 14 日 上午 10:52

  20. Walid Damouny

    当标签页按需还不是 Firefox 的内置功能时,我一直使用一个扩展(搜索 BarTab)。它很棒,因为我很容易有上百个标签页,我将它们保留为临时书签,这样我以后就可以访问它们。

    如果书签更容易使用,我认为我们不会将标签页保留到下一次会话。

    2012 年 5 月 14 日 上午 09:31

  21. Dinesh

    干得好,伙计们。我期待使用 Firefox 13。我最喜欢 Firefox 的地方是,它不是由一些试图获取我所有私人数据的公司构建的。继续努力!我将永远使用 Firefox,尽管我发现自己为了速度而切换到 Chrome,但我永远不会放弃 Firefox!:)

    2012 年 5 月 14 日 下午 23:10

  22. brightsmith

    首先也是最重要的是,要警惕 Firefox 开发者中的渗透者/间谍,他们可能是竞争对手派来减缓 Firefox 性能的。请记住,Firefox 是唯一一个反对所有商业网络浏览器的非盈利性网络浏览器。

    请专注于:页面加载时间(未缓存和已缓存)、缓存管理(最好超过 1024 MB)、稳定性和可靠性(考虑多进程分离)以及优先考虑 Windows 7 平台。

    请不要过分关注:内存消耗(内存越来越便宜)、启动时间、硬件加速以及不那么重要的事情。

    2012 年 5 月 15 日 下午 13:37

    1. alexleduc

      不用担心秘密间谍。我听说 Mozilla 团队 24/7 戴着锡箔帽来防止心灵控制。

      2012 年 5 月 28 日 上午 10:04

  23. Narcélio Filho

    每次我打开一些臃肿的页面时,Firefox 只使用我的四个核心中的一个,而且每次只使用几秒钟。实现多线程(以正确的方式)将立即让它获得 100% 到 200% 的性能提升。

    2012 年 5 月 16 日 上午 11:48

    1. Ferdinand

      英特尔和 AMD 发现,它并不像想象的那么简单。使用多个核心真的很难。所有浏览器都在慢慢地尝试使用更多核心和 GPU,但要实现 100% 的速度提升还需要几年时间。更不用说 200% 的速度提升了。

      2012 年 6 月 5 日 下午 15:16

  24. Brightsmith

    我已经尝试了 Firefox 13 Beta 3(最新版本),在通过 HTTPS(登录)而不是 HTTP(匿名)访问 Google 时,它似乎有点慢。但总的来说,比 Firefox 10 明显更快。

    2012 年 5 月 16 日 下午 17:29

    1. Walid Damouny

      虽然有点跑题,但 HTTPS 在没有登录的情况下也能正常工作。唯一的区别是连接是加密的,没有人能看到它,不像传统的 HTTP。

      至于速度,是的,它比较慢,因为 HTTPS 不能像普通网站上使用的未加密的 HTTP 那样被缓存。原因是,你与 Google 之间的加密通信是乱码的,在你查看的页面中,没有可以被服务器缓存的部分(为了速度),以便在你要它们时将其提供给你。

      2012 年 5 月 17 日 上午 00:01

  25. leeoniya

    @Alec,谁是晚到的?http://code.google.com/p/chromium/issues/detail?id=105666

    2012 年 5 月 17 日 上午 09:22

  26. JK

    这个标签页不加载的事情听起来很奇怪…我通常的习惯是在 Firefox 崩溃后立即重启它,去泡一杯新鲜的咖啡,然后回到已恢复的 Firefox。我打开标签页的原因是我不想等待内容加载,现在要复制这种行为,我必须在重启后点击它们?在我点击之前,UI 会停止响应吗?:) 如果答案是“全部”,我想在启动时疯狂地点击一下是可以的。

    2012 年 6 月 6 日 下午 13:04

    1. Lawrence Mandel

      你作为用户拥有控制权。如果你希望所有标签页在重启时在后台加载,可以在首选项>标签页>不加载标签页,直到选中中关闭标签页按需功能。

      2012 年 6 月 6 日 下午 14:01

  27. Ferdinand

    你可以在选项>标签页>不加载标签页,直到选中中禁用此功能。

    2012 年 6 月 6 日 下午 22:55

  28. Jasjot

    感谢标签页按需功能。FF 在以前的版本中非常慢,希望这次能快一点。

    2012 年 6 月 7 日 上午 00:13

  29. Shankar

    一个请求——多年来,我发现 Firefox 在加载标签页时反复暂停(有时长达 20 秒)非常令人烦恼。这是因为我从闪存盘启动系统(即我看到的是磁盘延迟)吗?还是循环收集器造成的?这个问题变得如此糟糕,我甚至切换到一个简单的浏览器,比如 Luakit,一段时间内摆脱了这个问题。安装 Firefox 13,希望问题确实是循环收集器造成的,因此新版本会更流畅。

    2012 年 6 月 14 日 下午 23:32

    1. Shankar

      对于任何可能感兴趣的人来说,在我的情况下,问题部分解决了,使用的是 Arch Linux 的 profile-sync-daemon(debian/ubuntu 也提供了一个软件包,它只是一个 shell 脚本)。当需要大量 JavaScript 时,仍然会发生冻结,但总体来说速度加快了,所以这确实看起来问题主要在于磁盘延迟。Firefox 13 也可能有所帮助。最后,我将 sessionstore 配置变量切换到 10 分钟,而不是 15 秒。

      2012 年 7 月 3 日 上午 01:04

  30. samarendra

    FF 很慢,而且没有响应…

    2012 年 6 月 29 日 上午 03:57

  31. Bill

    的确。我的例子:在 Win XP 上打开 3 个 Firefox 13 窗口,没有标签页,显示相当静态的页面(例如 LinkedIn 页面),没有媒体,除了 NoScript 之外没有花哨的插件…为什么 Firefox 为了这个需要超过 300 MB 的 RAM?

    2012 年 7 月 18 日 上午 10:45

    1. Wes

      奇怪的是,当我分别在 Firefox 的不同窗口中打开三个 LinkedIn 页面时,它大约使用了 150 MB。
      当我分别在 Chrome 中打开这三个页面时,所有进程的总使用量加起来大约为 110 MB。

      当我将 Firefox 中的所有页面都移到一个带三个标签页的窗口中时,内存使用量下降了大约 30 MB。

      2012 年 7 月 18 日 下午 12:49

  32. Enrique

    恭喜!!!看来你的工作开始见效了

    http://lifehacker.com/5917714/browser-speed-tests-chrome-19-firefox-13-internet-explorer-9-and-opera-1164

    2012 年 8 月 5 日 上午 07:16

  33. Mark

    我是一个“标签页狂魔”,我非常喜欢延迟加载标签页!

    如果你打开了 24 个标签页,重启 FF 时,它会有很大的不同,而且当你想要使用某个特定的标签页时,单独的重新加载速度很快。

    我也在任务管理器中看到了这些更改对内存消耗的影响…

    点赞!

    2012年9月16日 19:25

本文评论已关闭。