Andy Davies dug into the shared caching situation on Safari, in Safari, Caching and Third-Party Resources. The shared cache in Safari may be more stingy that most people would have guessed:
What this means is Safari caches content from third-party origins separately for each document origin, so for example if two sites, say a.com and b.com both use a common library, third-party.com/script.js, then script.js will be cached separately for both sites.
And if someone has an ‘empty’ cache and visits the first site and then the other, script.js will be downloaded twice.
This is another situation of having to measure to make sure that the rule of thumb is actually helping in your specific case. The numbers from the HTTP Archive research were not exciting:
The March 2018 HTTP Archive (desktop) run has data for approximately 466,000 pages and the most popular public library, jQuery 1.11.3 from ajax.googleapis.com (served over HTTPS), is used by just over 1% of them.
I’m not sure what level adoption needs to reach for shared caching to achieve critical mass but 1% certainly seems unlikely to be high enough and even Google’s most popular font – OpenSans – is only requested by around 9% of pages in the HTTP Archive.
If 9% ends up being the upper bound for shared cache hits, we need to start re-thinking our approach.