There are some places in Blink code that explicitly or implicitly construct an AtomicString from a literal, in some hot path. This is slow because we have to re-hash the string and check the atomic string table for it.

One notable place I found was in ResourceRequest::{set,add}HttpHeaderField. These inputs get converted to AtomicStrings, so we should ensure literals are already global and atomic (most users are OK but there are a few that need updating).

One problem here is for the public API. If an embedder wants to add header "Foo" for every request, should it be converted to an AtomicString (and hashed, etc) per request internally? That seems wrong, but I think a good solution would involve expanding WebString.

I would also like to brainstorm about a solution that would not degrade over time (i.e. make this impossible to do in the future with better APIs).

Adding Blink>Loader because I've noticed this in loading code.