feat: make optimizely script asynchronous #1007
Conversation
…al-enterprise into feat/react-query-route-loaders
* feat: refactors away customer-agreement endpoint * feat: refactors away customer-agreement endpoint * chore: PR feedback * fix: abstracts response transform and defines distinct subscriptions object * chore: refactor to match new license manager refactor * chore: tests * chore: PR feedback * chore: PR feedback
* feat: migrate existing API calls to React Query and Route Loaders * feat: Catch errors around root loader (#962) * fix: remove hardcoded hex colors where applicable, DRY using css vars in JS (#964) * feat: resolve all data during route transitions (#965) * fix: handle when active enterprise is changed external to current page view (#966) * fix: use * for not found page (#967) * feat: adds global queryKey object for useQuery * chore: Merge cleanup * chore: PR feedback and refactor additional endpoints * chore: PR fixes 2 * feat: query-key-factory * chore: PR feedback * chore: refactor to new queries * chore: merge fix * chore: PR feedback * chore: pr cleanup * chore: Rename functions * chore: jsdoc added * chore: jsdoc added * chore: Merge fixes * chore: PR feedback * chore: merge fixes * chore: PR feedback * chore: disable _ctx lint error --------- Co-authored-by: Adam Stankiewicz <agstanki@gmail.com>
* feat: refactor notices provider to useQuery * chore: merge fix * chore: cleanup * fix: redirects without momentary render * fix: debugging * chore: Testing and cleanup * chore: PR feedback
…us general cleanup (#990)
* feat: integrate search page with useQuery * chore: refactor * feat: SearchCatalog abstrated from UserSubsidyContext * feat: render search page * chore: cleanup * chore: cleanup 2 * fix: dependency error * feat: migrate content highlights * feat: migrate academies to loader and queryKeyFactory * chore: lint * fix: update quey key hierarchy for academies * chore: linting * fix: useAcademies return * chore: PR feedback
* feat: Follow up to search page integration * fix: more memoization to prevent rerenders * fix: update card memoization * chore: Search component test updates * chore: content highlights tests under search directory updated * chore: Search cards and results tests updated * chore: hooks for search tests updated * feat: pathway modal route * chore: pathway card tests * chore: PR feedback and test optimization * chore: Search academy updated * chore: PR feedback
| <% if (htmlWebpackPlugin.options.NODE_ENV==='production' && htmlWebpackPlugin.options.OPTIMIZELY_PROJECT_ID && | ||
| htmlWebpackPlugin.options.DEPLOYMENT_ENV==='production' ) { %> | ||
| <script src="https://www.edx.org/optimizelyjs/<%= htmlWebpackPlugin.options.OPTIMIZELY_PROJECT_ID %>.js" | ||
| async="async"></script> |
There was a problem hiding this comment.
[sanity check] Would we want async or defer?
If the async attribute is set, the script is downloaded in parallel to parsing the page, and executed as soon as it is available. The parsing of the page is interrupted once the script is downloaded completely, and then the script is executed, before the parsing of the rest of the page continues.
[sanity check x2] Is there any risk that we'd be trying to execute Optimizely related code paths before it's fully loaded after these changes? E.g., right now, I believe the earliest call to Optimizely is within EnterprisePage where pushUserCustomerAttributes is called. However, what if this call was actually done within a route loader? With the Optimizely script downloaded async/deferred, can we still guarantee window.optimizely will exist when we need it to?
There was a problem hiding this comment.
Sanity check 1: I considered both but the safer option of the two was async imo. By allowing the execution of the script as soon as its available should reduce the chances of the resources being unavailable on page load. defer is an option as well and might be the more performant option but we run the risk of the resources that not being available...
Sanity check 2: ...that being said, I ran a couple of instances on localhost stage with the request blocked and the page did not error out. By parsing the code they all seem to be gated by a check for optimizely before they execute within this utility file. Given the appropriate checks we COULD use defer as opposed to async.
There was a problem hiding this comment.
[update, follow-up from Slack] We decided to defer on this approach for now given the uncertainty around timing when making Optimizely a non-render-blocking resource (i.e., how do we delay execution of Optimizely helper functions until we know for sure window.optimizely has finished loading?). This uncertainty could lead to unintended loss of data pushed up to Optimizely (user identify calls, events, etc.).
Helpful resource: https://support.optimizely.com/hc/en-us/articles/4410289790221-Install-the-snippet-as-a-non-blocking-resource
|
Closing pull request mainly due to the way optimizely is designed. It is intentionally meant to be a non deferred request. |
Adds
asyncattribute to each optimizely script to allow asynchronous loading with the loadersFor all changes
Only if submitting a visual change