4 ms·

> Every megabyte counts in a mobile first world. I manage a normal looking regional news site. First load is 691KB. Megabytes don't come into it. (I cheat by

> Every megabyte counts in a mobile first world. I manage a normal looking regional news site. First load is 691KB. Megabytes don't come into it. (I cheat by not having Google Ads on the page, but lol, Google is the one who sucks. Our house ads are fine.)

eternityforest 5y ago
If saves 2 hits like that a day, it's over 30MB a month. Not extreme, it's still 1% monthly data saved, for something that likely would have been easy to make into a setting.
- MrJohz 5y ago
  That estimation seems pretty suspect though. Firstly, once you've visited the site personally, the assets will be cached for you anyway. Assuming the site updates its CDN'd assets once a month, the shared cache might possibly save you the first hit each month if you've visited another site that uses the same exact assets beforehand. (But given that the asset has just been updated, this seems unlikely.) So we're not talking about two hits a day. Secondly, the vast majority of the site will not be on shared CDNs, because it's specific to that site. Images are usually the biggest offender in terms of page load, and those are very unlikely to end up in a shared cache. In a busy marketplace like that of news media, brand identity is very important, so I would guess that most of the CSS is either custom or customised, and therefore not in a shared cache. I don't know how much JS the site uses, but I'll be generous to your argument and assume they use jQuery, which is hosted on a shared CDN. Custom JS is obviously not used on other sites, so won't be in the shared cache. And thirdly, there's a reasonably high chance, even if the jQuery stuff is hosted on a shared CDN and you've visited another page that uses jQuery before, that either the CDN host is different, or the version of jQuery being downloaded is different. It's unlikely that everyone updates immediately when a new version is released, which leaves you with a long tail of different versions being spread out over different hosts. A better estimate probably like like this: * Assume only one hit per month - the rest would have been cached anyway after the first visit to the site. * Assume only a minified version of jQuery is hosted via a shared CDN. * Assume that half the time, the version of jQuery used on this particular site is so unique that it wouldn't have been found in the shared cache. According to Bundlephobia, the gzipped, minified size of the latest jQuery package is about 30kB. Assuming we would have had to download it anyway on about 50% of requests, and given that every request after the first would is cached anyway, you're saving around 15kB a month on average. Assuming 3GB data a month (based on your 1% figure), that's about 0.0005% of your data each morning getting a successful cache hit that it would not otherwise have got if the shared cache was not there.
  - eternityforest 5y ago
    https://developers.google.com/web/updates/2020/10/http-cache-partitioning https://developers.google.com/web/updates/2020/10/http-cache... Google claims a 4% increase in bytes over the network.

eternityforest 5y ago

If saves 2 hits like that a day, it's over 30MB a month. Not extreme, it's still 1% monthly data saved, for something that likely would have been easy to make into a setting.

MrJohz 5y ago
That estimation seems pretty suspect though. Firstly, once you've visited the site personally, the assets will be cached for you anyway. Assuming the site updates its CDN'd assets once a month, the shared cache might possibly save you the first hit each month if you've visited another site that uses the same exact assets beforehand. (But given that the asset has just been updated, this seems unlikely.) So we're not talking about two hits a day. Secondly, the vast majority of the site will not be on shared CDNs, because it's specific to that site. Images are usually the biggest offender in terms of page load, and those are very unlikely to end up in a shared cache. In a busy marketplace like that of news media, brand identity is very important, so I would guess that most of the CSS is either custom or customised, and therefore not in a shared cache. I don't know how much JS the site uses, but I'll be generous to your argument and assume they use jQuery, which is hosted on a shared CDN. Custom JS is obviously not used on other sites, so won't be in the shared cache. And thirdly, there's a reasonably high chance, even if the jQuery stuff is hosted on a shared CDN and you've visited another page that uses jQuery before, that either the CDN host is different, or the version of jQuery being downloaded is different. It's unlikely that everyone updates immediately when a new version is released, which leaves you with a long tail of different versions being spread out over different hosts. A better estimate probably like like this: * Assume only one hit per month - the rest would have been cached anyway after the first visit to the site. * Assume only a minified version of jQuery is hosted via a shared CDN. * Assume that half the time, the version of jQuery used on this particular site is so unique that it wouldn't have been found in the shared cache. According to Bundlephobia, the gzipped, minified size of the latest jQuery package is about 30kB. Assuming we would have had to download it anyway on about 50% of requests, and given that every request after the first would is cached anyway, you're saving around 15kB a month on average. Assuming 3GB data a month (based on your 1% figure), that's about 0.0005% of your data each morning getting a successful cache hit that it would not otherwise have got if the shared cache was not there.
- eternityforest 5y ago
  https://developers.google.com/web/updates/2020/10/http-cache-partitioning https://developers.google.com/web/updates/2020/10/http-cache... Google claims a 4% increase in bytes over the network.