Self-hosting

We recommend that you do not self-host lux.js. There are two main reasons for this:

1. The contents of the lux.js script are generated dynamically based on your SpeedCurve account settings. If the script falls out of sync with your settings, your RUM data may not include custom metrics or may report inaccurate data.

2. The lux.js script itself is updated regularly. If the script falls out of sync with the RUM data pipeline, your data could become corrupt or lost entirely.

Alternatives to self-hosting

Many of the benefits of self-hosting can be had without actually hosting lux.js yourself. These are some of the alternatives that we recommend:

• Set up a reverse proxy from your own CDN. This gives you more control over caching and enables computing at the edge. Make sure that your CDN revalidates the script with SpeedCurve's origin on at least an hourly basis.
• Use a feature flag service so that lux.js can be quickly removed from your pages. This is normally enough to satisfy internal security requirements for third party scripts.
• Use a CNAME DNS record to transparently load lux.js from your own domains. This enables you to implement a more strict content security policy.

Reasons you might want to self-host

Security

Internal security policies sometimes require that you have complete control over all scripts on your pages by hosting the script contents on your own servers. Regular updates to lux.js make this infeasible in most cases. This can be somewhat mitigated by periodically updating your self-hosted lux.js, however this still requires some level of trust that the upstream source of lux.js is not compromised.

For more information on self-hosting lux.js, see the documentation on RUM and subresource integrity (SRI).

If security is your main concern, we recommend implementing a feature flag for lux.js.

Performance

Most SpeedCurve users know that third party scripts are a major culprit in making websites slower. We understand that putting our script on your page is a big ask, so we go to great lengths to ensure that lux.js does not affect the performance of your pages.

• The lux.js script is loaded with the async and defer attributes, which means it is downloaded with a low priority and does not block HTML parsing.

• The lux.js response has a relatively long cache time (7 days), and we estimate a 35% cache rate across all LUX users.

• The lux.js script is served from Fastly's CDN, which has POPs placed all around the world to minimise latency.

• We constantly monitor the evaluation time and overall performance of lux.js in our integration environment as well as in the real world.