Mozilla Firefox new HTTP cache is live!

mozilla firefox new http cache performance speed crash kill freeze

 

The new Firefox HTTP cache back-end that keeps the cache content after a crash or a kill and doesn’t cause any UI hangs – has landed!

 

It’s currently disabled by default but you can test it by installing Firefox Nightly (version 27) and enabling it. This applies to Firefox Mobile builds as well.  There is a preference that enables or disables the new cache, find it in about:config. You can switch it on and off any time you want, even during active browsing, there is no need to restart the browser to take the changes in effect:

browser.cache.use_new_backend

  • 0 – disable, use the old crappy cache (files are stored under Cache directory in your profile) – now the default
  • 1 – enable, use the brand new HTTP cache (files are stored under cache2 directory in your profile)

Other new preferences that control the cache behavior:

No longer used any new specific preferences.  We are now backward compatible with the old cache preferences.

browser.cache.memory_limit

  • number of kBs that are preserved in RAM tops to keep the most used content in memory, so page loads speed up
  • on desktop this is now set to 50MB (i.e. 51’200kB)

 

There are still open bugs before we can turn this fully on.  The one significant is that we don’t automatically delete cache files when browser.cache.disk.capacity is overreached, so your disk can get flooded by heavy browsing.  But you still can delete the cache manually using Clear Recent History.

Enabling the new HTTP cache by default is planned for Q4/2013.  For Firefox Mobile it can even be sooner, since we are using the Android’s context cache directory that is automatically deleted when the storage gets out of space.  Hence, we don’t need to monitor the cache capacity our self on mobile.

Please report any bug you find during tests under Core :: Networking: Cache.

 

35 thoughts on “Mozilla Firefox new HTTP cache is live!

  1. Hmm.. I always shudder when I see a boolean indicator of “new”, since it’s almost inevitable that at some stage it will be old while still retaining the name new. In itself it’s still not terrible, but then a new backend comes along, and then it becomes interesting ;)

    How about browser.cache.use_backend_version, with 0 as the default backend, and 1 as your new one?

    1. This preference won’t last that long to make the name important :) I don’t want to change it now when it has been made public.

  2. Congratulations! Are there any measurements of how much it reduces UI hangs in common workloads?

  3. Will the new cache still use the files in the old Cache directory? Will “Clear Recent History” also clean up the old Cache files?

    1. No, the new cache goes from scratch, no use of the old cache files at all.
      No, it depends on how the preference is set when you press the “Clear Now” button in that dialog.

      The goal is to completely remove the old cache and the way it stores files to disk.

      1. When the new cache is unpreffed for users, will the new cache clean up users’ old Cache directory? Or does enabling the new cache effectively leak all the old cache files on disk?

        1. The new and the old cache are completely independent in how they store files. This is an experimental stage when both cache systems live together in the platform. Enabling one back-end does not touch the other back-end files, at all.

          It’s not intended to keep both cache systems forever, though. When we enable the new cache by default, we are going to delete the old cache files.

  4. I know this will ride the trains, and only then after it’s been extensively tested, (mostly) feature complete, and reasonably bug free. But I’ll join the chorus of being super excited for this, based on the potential number of known and unknown bugs fixed by it. I’m hoping “on by default” comes in the Fx 28 or 29 cycle.

    I have quick (dumb) questions about people with Intel Atom boxes and older smartphones. Has the new code been tested on slower single core devices too? Are there similar improvements? Or are most OS’es good enough that threaded code on a single core isn’t a worry, anymore?

    Thanks!

    1. Thanks for the enthusiasm. I personally share it.

      The linux machine I had a chance to test with is an old single core 2.4Ghz Athlon ‘something’. Very old and very slow. I haven’t seen a difference in loading times for old and new cache (see the tables). I think I can get to a machine with Atom processor and 5’400rpm HDD and do some testing on it. Thanks for suggestion.

  5. Congrats, can’t wait until this becomes a default setting! Hope this helps to solve our problems (for our customers) with the cache on Android devices. We’ve spend a lot of time to investigate this, but this is not fully reproducible. So we couldn’t fill a bug report in bugzilla.
    Sometimes it starts if we get the cache when the connection is bad, our application is cached 100%, but then there are icons and javascripts with the wrong content inside.
    Other scenario is after let the mobile device rest overnight or some days, sometimes I’m not sure but I think the cache get’s stolen, so that our application couldn’t start anymore.

    Could it be possible that this new backend helps us also with this problems? Has this new backend also a better error handling, for example when there is bad connection, to get the files from the server?

    1. I’m sorry, but it’s not clear at all what the problem is. You can test your self, install a nightly or aurora build and switch the pref. If you believe there is a bug in the browser, then please file a bug in Mozilla’s bugzilla.

  6. Zkusil jsem novou cache zapnout ve Firefoxu 27 beta. Smazal jsem starou složku Cache a nechal Firefox vytvořit složku Cache2. Vše funguje, ale čas od času Firefox vytvoří znovu složku Cache a začne ukládat do ní. Toto asi není běžné chováni?

    1. Toto chování se očekává. Stará (/Cache) a nová cache (/cache2) žijí společně, zapnutí nové cache ovlivňuje především http://. Do nedávna Wyciwyg – výsledek document.write() – ukládal do původní cache, a ftp:// ji používá rovněž.

      Nová cache se vyvýjí postupně, až několik cyklů po jejím oficiálním zapnutí dojde k úplnému odstraněné staré cache. Co se týče dat v adresáři /Cache, dojde k jejich automatickému smazání.

      1. Díky za odpověď. Ještě jeden dotaz: dá se nějak (stejně jako u staré cache pomocí browser.cache.disk.parent_directory) určit jiná složka pro umístění?

        1. Zatím ne, ale existuje bug, který má ale nízkou prioritu. Stále více uživatelů ale tuto funkcionalitu chce, takže se na to brzy vrhnu.

  7. For those who use Pale Moon and older versions of Firefox, the option to use the new HTTP cache backend must be available as a separate extension.

    1. The new cache can’t be in anyway separated to an extension. It is a hard-coded part of the Gecko/Necko platform spreading well beyond its sub-module. I was trying to find out which Gecko version Pale Moon is based on – that information is not on their web. When Pale Moon updates to a Gecko version where the new cache is in production-quality state, it will get it for free automatically. Currently the plan is for Gecko 32 if everything goes well. Some two last tests are failing right now (actually, are slower when compared to the old cache.) When fixed, we are done and turn on!

    1. …Some two last tests are failing right now (actually, are slower when compared to the old cache.) When fixed, we are done and turn on!

  8. how do i move the cache to a new location, so it’s not in my profile folder?? i keep all my caches on a separate drive.

    1. There is a browser.cache.disk.parent_directory preference. The new cache respects that for some time (since Firefox 30), see bug 922081.

      1. i tried that if you mean the “browser.cache.disk.parent_directory” setting. i turned on the new backend, and instead of using the path specified by “browser.cache.disk.parent_directory” it created a cache2 folder in my profile folder instead of spawning it with the given path. O_O

        1. On what Firefox version are you? As I mention it has been (re)introduced in v30. If you believe there is something wrong please file a bug at bugzilla.mozilla.org and provide as many information as possible. Thanks.

  9. When I turn on the new backend, does this affect only disk cache or also memory cache? Because when I visit about:cache, it shows maximum storage size as specified by the “legacy” browser.cache.memory.capacity settings instead of the new browser.cache.memory_limit.

    BTW I just noticed that I had disk cache disabled (can’t remember that I have done that but apparently I have). I was using only the memory cache. In this scenario, will the new backend give me any benefits?

    1. The new cache also re-implements the memory cache. browser.cache.memory_limit is dead – no longer used. We now use browser.cache.memory.capacity preference, so that we are compatible. That pref is not legacy at all.

      The new cache has many benefits like improved prioritization and data access as well as smarter eviction mechanisms. So it will work better even when only the memory cache is enabled.

      1. Cool, thanks for the explanation. Will the browser.cache.memory_limit preference be removed in some future build if it is not used any more? I am on FF 30 beta and was confused by this – googled what it means and came to find this blog post which states that the memory_limit is used. I realize it is a bit old now but that’s where my confusion came from.

        1. That pref (browser.cache.disk.memory_limit) has already been removed, post updated.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.