If your client-side code uses vendor SDKs directly and you want full control of the SDK, or if your hosting infrastructure could significantly outperform the CMS vendor’s, then host the SDK on your own infrastructure. For example, according to documentation for the Contentstack SaaS headless CMS at Home – Documentation (contentstack.com):
In development environments, you may not want to work with the minified version of the library.
For the following reasons, consider using the vendor’s infrastructure rather than hosting the libraries on yours:
- The first response from your website to the browser includes a <script> element that triggers an HTTPS request that begins resolution for CMS vendor DNS entries, which may provide a slight performance advantage for subsequent requests to the CMS that retrieve content and media assets.
- If the visitor has previously accessed a site that uses the same technique with the same CMS, then some or all of the relevant DNS entries may already be resolved, and the SDK is likely already cached.
For example, in the Contentstack documentation, the text above the <script> tag above states:
The text “here” is a link to the following URL, which contains an optimized version of the SDK hosted on the Contenstack global content delivery network for assets:
So, you have at least three options:
- Do not use the vendor’s SDK directly.
- Copy the SDK to your own hosting infrastructure and reference that.
- Reference the SDK hosted by the vendor.
In the last case, work with the vendor to determine a permanent library URLs for current and future versions of the SDK.