I've found HPKP and HSTS easy to trivial, but gave up on deploying CSP. It's major refactoring when so much stuff directly includes 3rd party CSS and script, or just injects static CSS and JS in to pages inline.
You might find the Content-Security-Policy-Report-Only header useful for identifying CSP issues and deploying policies without actually blocking anything.
> It's major refactoring when so much stuff directly includes 3rd party CSS and script, or just injects static CSS and JS in to pages inline.
You can still use CSP, and whitelist specific third-party domains. (There's no way to whitelist inline code, though, and if there were it'd be more work than eliminating it and moving it to files.)
But the refactoring is well worth doing. By eliminating inline JavaScript and off-domain JavaScript, you eliminate the possibility of script injection. And directly including third-party JavaScript (or CSS, which can include JavaScript) opens you up to various kinds of attacks.
That's not completely true - the nonce attribute (specify a nonce in the CSP header, have nonce=that on every script tag) or by sending the hashes of the inline scripts upfront in the CSP header.
It doesn't give you inline code in attributes (e.g. onclick) but it's a big help for migrating.
I'm going to be doing some blogs in the coming weeks on how to use hashes and nonces to whitelist inline script. Hopefully, this will make introducing CSP a little easier. I also have some tools in the making that will help in this regard too.