Probably since we switched from using CachedScript to ThreadableLoader in WorkerScriptLoader (http://trac.webkit.org/changeset/44726), the caching behavior changed in somewhat unfortunate way: when the page that creates more then 1 worker from the same script is "reloaded", it re-validates all the resources via server roundtrip and if multiple workers are created from the same url, they get revalidated every time. Here is the test created by Drew Wilson: http://www.corp.google.com/~atwilson/worker-latency.html Click the link, it'll create several workers. Note the printed time. Hit refresh. It'll create several workers again, this time taking longer for each one, for roundtrip to the server.
See http://code.google.com/p/chromium/issues/detail?id=34092#c10. I don't think this bug is unique to workers, and the fix probably can be made to SubresourceLoader in a manner that would work for all resource loads made after the page has loaded.
See also: bug 32423, bug 30862. We seem to be having two opposite bugs at once.
Created attachment 51470 [details] HTML file that shows this bug
Created attachment 51471 [details] Associated JS file (worker script) that shows the bug. Added worker-latency.html and worker.js files as attachments for this bug. Download both files into a single directory, load worker-latency.html in a browser, then hit reload to reproduce the issue.
This no longer reproduces using atwilson's test case. Worker loaded scripts come from the cache even after a reload. Please reopen with explanation if I'm missing something.
Likely it works now due to Nate's changes here http://trac.webkit.org/changeset/98380 and subsequent related changes later.