【求助】有没有“延迟读取”的扩展、脚本

我的习惯是，一股脑地把目录页面（论坛、新闻、博客、等等等等）中感兴趣的链接全部点击打开到背景标签然后慢慢看。
当然，显而易见的是，打开这些标签产生的持续 CPU 占用和内存占用都是相当大的资源消耗（40+标签是常事），更不用说 Firefox 没实现多进程之前开关标签必有的一“卡”了。
但我又不想开一个看一个开两个看两个，老是要回去筛选要看的链接会用多很多时间。
我试过用 Read it Later ，基本上实现了我想要的效果：它有一个“单击添加”的模式，启用该模式后单击就可以记录下要 RIL 的链接；但其不能满足我的是之后我还是要一个一个点开这些链接。

我觉得最理想的状态是，从同一个网站的链接点开的新标签中，只读取最早打开的两个标签的页面，其他全部在于等待状态；等待状态的标签只有被选中时才开始读取，或者按顺序在已经读取页面的标签都选中过后才开始读取。

这样在我阅读已经读取的页面时，其他等待标签不用占用资源；或者自动读取能够利用我正在阅读的时候的资源空闲。

>后台标签的加载时机（连续加载即一个后台标签加载完成后加载下一个，或者激活一个后台标签时加载下一个），第2个选项基本与顶楼的要求是一致的了。


这个如果能实现真的是相当人性化的一个功能。激活标签页加载可能对网速快的人更有用（当然，不能否认hzhbest说的，需要看实时刷新内容），但是网速一般的我来说，更希望他们在后台慢慢地载入进来。

非常感谢我行我速！

Load Tabs Progressively 0.1已发布。

基本上TU里的每一项功能都可以很容易地剥离出来用作单独的uc脚本，所以这个不用担心。
现在考虑增加2个选项：
1。同时加载的后台标签数量（0不限制）；
2。后台标签的加载时机（连续加载即一个后台标签加载完成后加载下一个，或者激活一个后台标签时加载下一个），第2个选项基本与顶楼的要求是一致的了。

简单调试了一下，新窗口链接和恢复窗口时的网络访问还没法拦截。
预计将会发布一个独立的扩展Load Tabs Progressively（欢迎提供更好的名称），有如下两个参数：
maxLoadingTabs: 最大同时加载标签数，0：不限制。
maxLoadedBackgroundTabs: 最大预读后台标签数，-1：不限制，0：类似BarTab，1+：类似顶楼的要求。

现在考虑增加2个选项：
1。同时加载的后台标签数量（0不限制）；
2。后台标签的加载时机（连续加载即一个后台标签加载完成后加载下一个，或者激活一个后台标签时加载下一个），第2个选项基本与顶楼的要求是一致的了。

很期待第二个选项的uc脚本。这样就解决同时打开多个链接时卡的问题了。

对 23楼 arch7819：这些选项会在我下载文件，特别是用 DTA 下载时影响到网页浏览吗？
对 24楼 ithinc：这样的话太好了！先谢一个！

hzhbest：
如果你做出来的话，能单独将该功能做成 uc 脚本吗？
延迟到激活再加载也不是没用，例如需要同时打开一大堆 Url 时而且这些 Url 载入会大量占用带宽，或者需要预先打开标签但要去看时能看到页面最新内容（例如网友评论）。如果是静态内容的话，限制同时加载就足够了。回到原帖

基本上TU里的每一项功能都可以很容易地剥离出来用作单独的uc脚本，所以这个不用担心。
现在考虑增加2个选项：
1。同时加载的后台标签数量（0不限制）；
2。后台标签的加载时机（连续加载即一个后台标签加载完成后加载下一个，或者激活一个后台标签时加载下一个），第2个选项基本与顶楼的要求是一致的了。

可以试试 将 about:config 中的
network.http.max-connections-per-server 降低, 可以降低到4,
network.http.max-persistent-connections-per-server;0 重要,否则后开标签页可能抢占前面的资源.
一定要同时开启
network.http.pipelining;true 重要!否则就是乌龟,需要HTTP1.1 放心, 现在都是.
以及network.http.pipelining.maxrequests;8 重要! 4*8 一样可以同时请求32个文件.
network.http.pipelining.firstrequest;false 重要!否则后开页面可以通过pipelining 抢占前面的资源.

只要你的网络负载满了, connections 的数量是不会影响你的下载速度的, 限制住max-connection 也就限制了最大同时加载的标签页.

ithinc：准备在Tab Utilities中加入一项类似的功能，我的设想就是可以设定同时加载的Tab数量，把所有Tab的加载请求排成一个队列，与Reload Tabs Progressively的想法比较接近。
如果延迟到激活标签再加载那感觉也不好用，本来后台打开的目的就是不想等待。回到原帖

如果你做出来的话，能单独将该功能做成 uc 脚本吗？
延迟到激活再加载也不是没用，例如需要同时打开一大堆 Url 时而且这些 Url 载入会大量占用带宽，或者需要预先打开标签但要去看时能看到页面最新内容（例如网友评论）。如果是静态内容的话，限制同时加载就足够了。

ithinc：准备在Tab Utilities中加入一项类似的功能，我的设想就是可以设定同时加载的Tab数量，把所有Tab的加载请求排成一个队列，与Reload Tabs Progressively的想法比较接近。
如果延迟到激活标签再加载那感觉也不好用，本来后台打开的目的就是不想等待。回到原帖

好想法，实现了我就去安装Tab Utilities了。

准备在Tab Utilities中加入一项类似的功能，我的设想就是可以设定同时加载的Tab数量，把所有Tab的加载请求排成一个队列，与Reload Tabs Progressively的想法比较接近。
如果延迟到激活标签再加载那感觉也不好用，本来后台打开的目的就是不想等待。

ithinc：看了电脑玩物介绍的TooManyTabs扩展，与你的要求似乎很相似。回到原帖

已经用过了，可是功能跟 BarTab（原：BarTap）是一个样的，也就是将“标签”（或应该说类似标签的按钮）的页面挂起，“激活”“标签”（或者按下按钮）再载入页面内容，只不过 TMT 更接近于 RIL ，也就是选择性地临时挂起一些页面，其后再读（也跟 RIL 一样强调网上同步甚至分享的功能）。
基于我需要的是自动挂起＋自动有条件载入的功能，此扩展也不适合。
我现在把 Initial Paint Delay 调到 1秒 了，免得像 Google 搜索页面那样的页面也得延迟渲染。

看了电脑玩物介绍的TooManyTabs扩展，与你的要求似乎很相似。

hzhbest：有一个扩展，才诞生于我提出这个问题的几天前：
BarTap :: Add-ons for Firefox
https://addons.mozilla.org/en-US/firefox/addon/67651

它的功能是将所有在背景打开的标签和／或恢复的标签都挂起不载入，直到激活此标签。
离我所需要的功能只差一步了：在一定条件下自动载入挂起的标签页面。回到原帖

不错，正在试用中