Performance Degradation with CatalogSearchView and Cesium Map Loading

[robyngit]

There is a substantial load time issue with the soon-to-be-released CatalogSearchView that uses the Cesium map. Compared to the current DataCatalogView which uses Google Maps, the loading performance on a simulated "Fast 3G" connection has nearly doubled.

Specifically, the older DataCatalogView with Google Maps takes approximately 40s to load, which is already an issue (see related issues on performance). The new CatalogSearchView with Cesium takes around 75s, further exacerbating the problem.

Here are the results from a casual test looking at the time it takes from a hard refresh until the map is visible (on the "Fast 3G" connection):

Cesium Tests:

Test 1: ~75s, 11.0 MB resources, 309 requests
Test 2: ~74 s, 11.0 MB resources, 308 requests

Google Maps Tests:

Test 1: ~40s, 5.4 MB resources, 191 requests
Test 2: ~38s, 5.5 MB resources, 197 requests

We are currently loading a combined build of Cesium.js which, even minified, is 3.5 MB and takes about 25s total to load. You can see here that at some point in loading the library, other requests are blocked:

At the very least, rendering of other parts of the UI should not be blocked while the Cesium map is loading. Using an inline require for Cesium and starting with a skeleton loading view would help.

Longer term solutions:

• The newer versions of Cesium are much smaller, so we should update (see issue Upgrade Cesium (from v1.91) to leverage improvements and bug fixes #2129)
• Since we intentionally developed our map using only the Cesium "widget" and not the larger "viewer" interface, we don't need to load in the entire Cesium library. If we eventually switch to using ES6 imports (issue Replace RequireJS with ES6 modules #2029) along with a modern build system, then we could load in just the modules that are required.
• If we implement the right tooling, then we can also take advantage of tree-shaking since it's now supported by Cesium
• See also: "CesiumJS Migrates to ES6 Modules"

Suggestions about how to avoid further slowing down the load time are highly welcome!

[robyngit]

After exploring different methods for dynamically/asynchronously loading Cesium, I haven't found a strategy that prevents the library from blocking other resources during its load phase. I even experimented with loading Cesium near the start of the page load process on a page that does not use Cesium at all (by simply using require to load it and then leaving it unused). Still, the issue persisted with the other resources being blocked during the phase that chrome calls "Content Download". It's not clear to me why this is happening.

Here is a link to the "profile" file from the Chrome dev tools performance tab (this file can be imported into the dev tools by right-clicking on the performance tab and opting for "Load profile..."). The performance profile looks like this:

I see two paths forward:

1. Investigate further to understand why downloading an unused library impedes the loading of other resources, or

2. Decrease the size of the Cesium library to improve load time.

For the second strategy, it might be possible to import only the required Cesium modules using require as outlined in the CesiumJS webpack guide. Without a modern build system, this could involve manually importing each module's dependencies. An alternative approach could involve creating our custom Cesium bundle using webpack, and subsequently loading it into the app.

[robyngit]

Progress update:

• Building v 1.77 of Cesium using webpack was not straight-forward and resulted in a much larger bundle than the one that is distributed from Cesium.
• I'm currently trying to modify how Cesium builds its distribution with gulp, such that it only includes the module we want to use, but this will take some time
• We decided today that it's not worth holding back the release to fix this, though we will try to load Cesium from a CDN to see if that helps: https://cdnjs.cloudflare.com/ajax/libs/cesium/1.77.0/Cesium.min.js

[robyngit]

Loading Cesium from a CDN for now, and will come back to this issue after releasing the Data Catalog with Cesium

[robyngit]

Here are some lighthouse results from the ADC catalog with Cesium that demonstrate the ways in which Cesium slows down the page performance. Cesium is one of the worst offenders in several categories: enormous network payloads, JS execution time, main thread blocking, and unused code.