There are a few caveats:
- The LocalCDN archive is about 20 MB, but there's no interface to track the download or any warnings about it failing; for users on slower or unreliable connections, this can definitely be an issue. I'm still deciding how to approach this problem. This will probably be addressed in a future version, not the initial release.
- I had to make a cached interception of resources for the Developer Tools, because it loads resources oddly. If the data doesn't match exactly, the whole browser will lock up or crash. It is also possible that requests will leak out and then be aborted in the Developer Tools because of the way it works, meaning some request data may be sent to a CDN.
- I had to intercept and modify "content-security-policy" headers to include "data:" and remove "require-sri-for" on relevant pages. This can result in potential security issues.
- I had to force-disable Internet Download Manager through the Windows Registry during the repository ZIP file download because IDM's extension intercepts EVERY request instead of just content-originating requests, completely ignoring red flags such as "mozBackgroundRequest" or "nsIRequest.LOAD_BACKGROUND".
- If you find a site is not working as expected with this extension, it's important to check how LocalCDN on Firefox behaves on the same site - if LocalCDN doesn't work, deCDN's obviously not going to either, since it's using the exact same resources.
- Ad blockers and script stoppers like nMatrix can still block the resources deCDN provides, because the URLs are unchanged (except for files [such as fonts] referenced in CSS, which are replaced with data: URIs). LocalCDN provides a "whitelist" you can import into such blockers to allow them through, but that seems counterproductive to me - if you don't want a script to run, where it came from is irrelevant.