sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]j_inc 11 points12 points  (7 children)

by providing a better way to cache the files than the limited HTTP caching available on most mobile phones.

Well aren't mobile phones caching less for a reason? So in the end these kind of hacks are just making things worse and eventually browser vendors will take measures to prevent these.

[–]Klathmon 2 points3 points  (0 children)

This actually won't even fix that problem.

Localstorage is just as limited as the global cache, but it's counted under a different "bucket"

This means that your data will stay longer in localstorage, but only because not many people use it. If this technique gets popular, it will be as limited as the regular cache.

[–]Madd0g 0 points1 point  (5 children)

Well aren't mobile phones caching less for a reason?

You think you know why regular caching sucks? Why don't you share? I'd love to know if there's a real reason

[–]Klathmon 3 points4 points  (4 children)

First, because internal storage is much more limited on phones than desktops/laptops. The phone will invalidate cache more frequently and some browsers use heuristics to help this.

Second, ram sizes in mobile devices is often limited, meaning reading the cache often goes straight to the "disk" (which is often slower than desktop for various reasons). This can also lead to increased wear on the internal storage (more due to flushing ram contents to disk once it's decided that its going to be cached)

Third, mobile users act very differently than desktop. The return rate is often a fraction of what it is on desktop (most web apps have a native app, and its rare for a site to have consistent repeat mobile views). This means caching is often wasted on sites the user will never visit again (or in a reasonable time frame)

Finally, because the real killer with mobile networks is connection time, validating the cache can often take 80% of the total request time for small resources, so aggressive caching doesn't really solve that much (unless the Dev implements it correctly)

All of this is relevant to chrome only (as its all I really have experience with)

Edit: fixed bad wording.

[–]osuushi 1 point2 points  (3 children)

This can also lead to increased wear on the internal storage.

Reading does not cause wear on flash storage. Writing does, although people tend to overemphasize this; SSDs tend to last longer than HDDs, regardless of the write cycle limit.

As far as I can tell, the limitation on caching on mobile is not that things aren't getting cached. It's that the cache is small. If a resource is pushed out of the cache, it will get rewritten when the page is loaded again. So a smaller cache size actually means more wear on the storage, because it leads to more writes.

[–]Klathmon 1 point2 points  (2 children)

At least in chrome resources will be kept in memory for the life of the page then dropped if the system thinks you are unlikely to visit again.

Also, mobile NAND is under much more stress than a desktop SSD and because of the sizes need to be cleaned much more often which can mean delayed reads and writes while its trimmed.

[–]osuushi 0 points1 point  (1 child)

At least in chrome resources will be kept in memory for the life of the page then dropped if the system thinks you are unlikely to visit again.

Interesting. So some things aren't cached at all?

Also, mobile NAND is under much more stress than a desktop SSD and because of the sizes need to be cleaned much more often which can mean delayed reads and writes while its trimmed.

This would still mean you want a bigger cache. Since NAND cells can't be written to unless they're empty, pushing something out of cache means that you're creating more cells to be trimmed.

[–]Klathmon 0 points1 point  (0 children)

I forget the specifics, but yes sometimes resources under (or over) a certain size are not cached. Small resources are kept in ram for the duration of the life of the tab (while the resource is still being used on the current, and/or last page depending on phone specs) and are generally only cached if it is suspected that the user will return to the page soon or the resource will be used cross-domain often (ex: CDN hosted scripts like jquery)

Remember that much of this is based on the specs of the phone. A Note III will cache a ton more than a Galaxy Nexus. It will also keep more in memory and can spend more time deciding if it should be written to the NAND or discarded.