dgod：这个bug，几年前就有人报过了，是渲染机制的问题，没什么改进进度。
其他浏览器是只解码页面可见部分的图片的，gecko是全页面解码，所以速度内存都差很多。回到原帖

没有几年吧，主要是4之后才是这样的，正式版到现在还不到一年。3.6也卡，但不会占这么多内存然后崩溃

BT网站，看看你的FireFox能不能坚持住 • Mozilla Firefox中文社区
6年的发展 依然任重道远

fang5566：既然是排版引擎，那就不好办咯，gecko引擎比较臃肿，虽然很强大，但是要改动的话，量比较大。回到原帖

是呀，对于这样的非盈利开源项目来说，工作量也是一个很重要的障碍……

既然是排版引擎，那就不好办咯，gecko引擎比较臃肿，虽然很强大，但是要改动的话，量比较大。

这个要像chrome学习，解决多图网页内存占用、内存释放和网页流畅性的问题。

我关注这两个
https://bugzilla.mozilla.org/show_bug.cgi?id=689623
https://bugzilla.mozilla.org/show_bug.cgi?id=661304
动静虽有
但是进度不足
早呢

我觉得这个更接近解决

https://bugzilla.mozilla.org/show_bug.cgi?id=683286

谢谢楼上的提醒~
仔细搜索了一下bugzilla，相比2010年那时起，又多了不少的bug提交，共同点是都没有解决~
Jeff Muizelaar在Bug 661304中说，

For what it's worth, it seems like Chrome just does a synchronous decode on draw to avoid this problem. I haven't yet looked at how they do discarding.

= =b 那么现在只好默默地祈祷fx团队们早日开发出牛逼的方案了~~

这个bug，几年前就有人报过了，是渲染机制的问题，没什么改进进度。
其他浏览器是只解码页面可见部分的图片的，gecko是全页面解码，所以速度内存都差很多。

这个应该也会很卡，但不耗内存

没比较过。和渲染机制有关？

报告给bugzilla？

不错的压力测试。
基本上验证了我们对于FF和Chrome打开大量图片时候的观感。

从载入速度来看，我认为和Gecko和Webkit引擎有关系，Webkit明显比Gecko轻量快速，客观造就在图片生成渲染载入速度上Webkit有优势。
从浏览速度来看，因为Gecko是占用较多内存载入所有图片，因此在流畅性上没话说。
从卡顿来看，应该是FF在载入大量图片时候启动了GC和CC回收内存造成的卡顿。而听说Chrome实现了IGC，而FF还没实现，因此FF卡顿更为明显。而这个也造成了FF浏览大量图片时候内存占用高且不易释放的问题。

先大概看一下，回头详细的再慢慢看。 <!-- s8) --><img src="{SMILIES_PATH}/icon_cool.gif" alt="8)" title="Cool" /><!-- s8) -->