[hawski]

I am with you, but I don't believe that this solution will be ever used by the majority of developers.

Browser caches should be bigger. They also should be more intelligent. It does not make sense to evict a library from cache if it is the most popular library used. Maybe having two buckets, one for popular libraries and another for the rest.

I think that it would help if script tag had a hash attribute. Then cache could become more efficient. But without the first part it would be useless. Example:

  <script src="https://cdn.example.com/jquery.js"
  sha256=18741e66ea59c430e9a8474dbaf52aa7372ef7ea2cf77580b37b2cfe0dcb3fd7>
  </script>

Or different syntax (whatever I'm not W3C):

  <script src="https://cdn.example.com/jquery.js">
  <hash>
    <sha256>
      18741e66ea59c430e9a8474dbaf52aa7372ef7ea2cf77580b37b2cfe0dcb3fd7
    </sha256>
  </hash>
  </script>

I would like to make an experiment, but as I am not experienced with webdev as much, it could take too much time for me. Test all major browsers with fresh install and default settings. Go to reddit or other links aggregator and load in sequence several links in same order on every browser. Check how efficiently cache was used. I would expect that after 10th site is loaded nothing would remain from the 1st one. Even though the same version of some library and maybe even link to CDN was used.

I am amazed how quickly fully static pages work even after I am on capped speed mobile connection (after I use 1.5 GB packet).

EDIT: The most helpful thing would be to have good dead-code removing compilers for JavaScript.

[dchest]

Check out the list of security problems you'll need to solve to implement hash-addressable caching:

Subresource Integrity Addressable Caching https://hillbrad.github.io/sri-addressable-caching/sri-addre...