Provide User Interface to Disable Web Page Caching

RESOLVED WONTFIX

Status

()

Core
Networking: Cache
--
enhancement
RESOLVED WONTFIX
2 years ago
2 years ago

People

(Reporter: David E. Ross, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
The HTML files for many Web pages are now generated "on the fly".  Other HTML files are stored as compressed on servers.  In both situations, the date-time stamp for the Web page reflects either the immediate generation of the page or the immediate decompression of the page, always different from the date-time stamp of the page in the browser cache.  Along with broad-band Internet connections, caching now has little utility.  

Caching requires additional processing time and disc space.  During system backups, caching requires even more time and space unless users remember to purge caches.  While faster CPUs and larger disc capacities mean the time and space are of small consequence, there is zero benefit from this waste.  

Rather than setting the cache size to 0, the user should be able to disable caching entirely.  This should include purging of any existing cache, the removal of existing cache folders, and the elimination of creating new cache folders.  

Since some users still do not have broad-band Internet connections and some Web pages are neither generated "on the fly" nor compressed.  This should be a user option, keeping the capability to continue caching.
I don't buy the premise that caching has little to no utility - there's a reason browsers are moving in the direction of prefetching resources to reduce user-perceived page load time, even on broadband connections. The same argument applies to cached resources. Backups can easily be configured to ignore caches.

I'm fairly certain we had this option at one point in the distant past and removed it (though I could be wrong on that).

If you want to disable the cache on your own browser.cache.disk.enable and browser.cache.memory.enable in about:config are there for you.

I don't think this is anything we need to expose via UI, it's added complexity that will benefit a vanishingly small number of users.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 2

2 years ago
Having read <https://en.wikipedia.org/wiki/Link_prefetching#Issues_and_criticisms>, I disabled prefetching quite some time ago.  

I really do not understand opposition to making this a user option.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
That's fine, you're welcome to disable prefetch. However, we don't need to clutter our prefs UI with options that the vast majority of users will never make use of. Like I said, if you (or any other power user) wishes to disable caching, that option is available in about:config.
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → WONTFIX
Hey david - I agree with wontfix, but I wanted to give a little background.

First, I sympathize with your notion that sometimes the network is faster than the cache. Indeed, I ran a little experiment probably 2 years ago now with the cache disabled to see what the impact would be. Some things sped up, and some things slowed down - on balance the cache helped (so it stays!) but it didn't help in every case.

It doesn't make sense to promote high level UI for a user to figure out which camp they are in. If you think you know to that degree of detail, you're going to be able to use the existing about:config knobs.

On the other hand, this is exactly the kind of situation where the browser could be made smarter about these things - learning your disk access times, learning the latency and download times of things in your cache, etc.. so it can make a better judgment about what to do on a case by case basis transparently. That's the kind of patch I would take.

hope that helps.

(prefetch and whatnot is related but not exactly the same. "in ram" is always going to be faster than network - so at that point its a resource balancing game.)
You need to log in before you can comment on or make changes to this bug.