Before You Begin
Designing Your Map for Performance
Reduce the Number of Features Displayed
- Establish the minimum and maximum scale.
- Preprocess data when appropriate.
- Limit the map to the layers needed by the application.
- Use definition expressions to filter data displayed by layers.
- Only load the attributes you need.
Establish the Minimum and Maximum Scale
The number of features displayed impacts performance, especially on memory-constrained devices. When you set a minimum and maximum scale (also referred to as the visible scale range), a layer’s features are displayed when the zoom level is within the set range. What layers should you show at each scale? When configuring the visible scale range of each layer, think about what features make sense to view at small and large scales. Can users distinguish between features at small scales? As you zoom out, it may become difficult to see more detailed information, or as you zoom in, information may become too coarse. Often the best way of determining the visible scale is by playing around with it and looking at the data through your end user’s eyes.
Preprocess Data When Appropriate
Use the ArcGIS system to preprocess your data for display at small scales. At the country, state, or county level, it may be more useful to display the data as aggregated polygons as opposed to individual points. There are multiple ways to summarize data within polygons. Polygons can either be a standard geography such as a state boundary or they can be regularly divided into a grid or hexagons. If it is meaningful to summarize your data at a standard geography, calculate the summary statistic for each geography and thematically map each polygon according to its value.
If it doesn’t make sense to summarize at a standard geography, an alternative is binning. Binning aggregates large amounts of point features into polygons called bins. A single bin represents all features within its boundaries and appears wherever at least one feature lies within it. For layers that contain thousands or millions of point features, binning vastly improves layer drawing performance. You can use ArcGIS Pro or ArcGIS Online to aggregate data and create summary layers. Use a scale dependency to display the summarized data at small scales and display individual features as the user zooms in. This approach only makes sense if your data is not constantly changing because each time your data changes, you will need to process the data again.
Limit the Map to the Key Layers Needed
Avoid authoring web maps with a dozen or more layers. A web map with many layers is usually a web map trying to address too many user needs in a single application. Breaking the content into different maps to build focused applications will better meet specific user needs. A good approach for doing this is to categorize your users into groups based on their role and data and application requirements. Then design maps for users with similar needs and create clean and easy-to-use mapping applications that target their use case. These applications can often streamline users’ workflows while providing better performance because they work with less data.
If you must create a map with many layers, you may be able to squeeze a bit more performance out of it by loading the layers in your application as needed. Listing 1 shows how you could accomplish that. It loads the map, finds the layers needed when the application loads, and then loads the other layers as required.
Use Definition Expressions to Filter the Data Displayed
If your application requirements are met using only a subset of the layer’s features, set a definition expression on the layer. Definition expressions set on the layer are different from defining a client-side filter. When a definition expression is set on the layer, the server will only return the needed features.
Load Only the Attributes Needed
Improve the performance of your application and the services it uses by employing the following techniques:
Enable Control Cache
Precook Features into Vector Tile Layers
However, if end users are on more limited devices, you may not have the luxury of loading all features. To preserve a crisp display at any scale and minimize memory consumption, you can precook features into a vector tile layer. Interactivity will depend on a feature service used behind the scenes. Queries will go to the server rather than a client-side feature layer, but the display will be handled by the vector tile layer. When end users are using very resource-constrained devices or in low network bandwidth situations, consider precooking raster tiles as opposed to vector tiles. However, this will come at a cost. The raster tiles will not display as crisply as vector tiles and are not dynamic. For example, as the user rotates the map, the labels won’t rotate.
Optimize Application Design
There are several methods you can use to optimize your web mapping applications with a custom build geared toward your application. The PRPL pattern is a common method for making applications performant, especially on low-end devices and in regions with poor Internet connectivity.
- Push critical resources
- Render as soon as possible
- Pre-cache assets
- Lazy load as needed
Push Critical Resources
Render as Soon as Possible
A side effect of pushing critical resources when an application starts is loading and rendering the initial route as soon as possible. This is also an area where you can leverage an app shell. An app shell is the minimum amount of HTML and CSS needed to display your page right away. It might not have the detailed layout but would display the bare minimum of the application. If the map takes up a significant region of your initial page, you could have an image of a map or globe displayed until the map loads. It does not have to be an exact image of the map you want the application to display; the placeholder can just indicate where a map will appear.
Once you have preloaded and cached critical resources in your application, you may want to lazy load the remaining resources. This doesn’t necessarily need to be an initial route, but there are portions of your application—such as charts, or even the map—that are loaded at runtime.
For example, an application might display a list of locations by name. When a location is selected, a map is loaded displaying that location. In this case, you want to render that list as soon as possible, but you can lazy load the resources for the map later. This can be accomplished in a few ways including using dynamic imports of modules for when they are needed. You don’t want to overuse dynamic imports because this could result in code being repeated in the bundles generated by dynamic imports.