Backend Proxy is another method of implementing Performance Edge.
It is not recommended as it usually leads to much poorer performance than implementing via Edge Subdomain or CDN proxy.
This is because the backend system serving as the proxy usually does not have the geographical proximity to your site visitors that a CDN or our Edge Worker does and can lead to requests taking much longer.
However, prior to the release of Edge Subdomain, this was an alternative for customers who couldn’t set up their CDN to proxy Performance Edge requests.
Here's how it works:
- Visitor requests your webpage, which includes a script request. The script tag can either be:
- first party — e.g. reference a relative path such as
- third party — e.g. referencing a different origin
Note that if the using a third part origin, you’ll need to add the following as an attribute on your script tag:
referrerpolicyattribute is required to enable Optimizely to receive the referrer for page targeting purposes.
Starting in Chrome 85, Chrome will default to using the
strict-origin-when-cross-originreferrer policy which would prevent Optimizely from getting the full URL of the page the visitor is viewing. Other browsers have indicated they plan to follow Chrome’s lead in this as well. Setting the referrer policy to the current default
no-referrer-when-downgraderesolves this. Learn more about these referrer policies.
Your backend should be configured to automatically fetch requests matching with
/optimizely-edge/<project_id>.jsfrom the Optimizely Edge Decider API (see the Settings tab in your Performance Edge project for the literal value for a given project).
Optimizely's Edge Worker returns the microsnippet to your backend, which returns it as the response body of the script request.
Updated 8 months ago