ArcGIS allows you to make a range of resources available to users: apps, maps, layers, services, and data. To deliver the best performance for users who are accessing a resource, it is important to understand there are different methods of optimization, depending on the resource type. The options that are available may depend on the backend data source, the type of geospatial service , or other factors. Understanding different types of optimization is an important part of ensuring a positive and effective user experience.
This section covers general strategies for evaluating user needs, network design, and caching options. See Optimize web maps and apps and Optimize data sources and storage for additional information about specific optimization strategies.
Optimization means more than just minimizing the response time for HTTP requests. A service that sends rapid, low-latency but unhelpful responses is not necessarily optimized. Determine who will use the resource or service and why. Understand the questions the user will want answered by interacting with the resource. Use structured testing to ensure the resource performs well on the different client devices that users will access the resources from. Incorporate user feedback about the usefulness of the resource both during development and after the resource has been available for general use.
User needs will also help inform what kinds of performance optimizations are worth implementing. If a resource will only be used a few times a day by a small internal group, it is not as important to optimize to the point that it scales to thousands of requests per second. That same optimization, however, could be vital for a resource that is used by a global public audience.
The design of the network where ArcGIS components are deployed is a key contributor to performance (both good performance and poor performance). Enterprise systems are often global in nature, serving users across a wide array of network conditions and connectivity, and there are important differences between ArcGIS components and workflows in terms of their reliance on network connectivity. The breadth of network considerations for ArcGIS workflows is broader than this topic, but some initial recommendations and considerations include:
Repeated requests for resources can require significant computational overhead in generating those resources. Providing a cached response can avoid that overhead, reducing both system resource usage and response times. Maximizing the use of caching can significantly improve the performance of ArcGIS resources.
There is no one-size-fits-all approach to using caching with the variety of web applications and services that can be used in ArcGIS, but instead a variety of patterns that should be used with consideration and planning. Common methods for caching include:
Raster and vector tile caching take input data that which might otherwise be accessed dynamically through a map, feature, or image service, and cache it into tiles. These tiles are predefined standardized images that show rendered data. Cached tiles allow clients to request multiple pre-rendered tiles at the same time for a given scale, so there is wait while the server accesses and draws any backend data. Both raster and vector tile caching are enabled by creating tile layers, while feature tile caching requires additional configuration of the properties of a service.
Each of these caching strategies have a wide variety of configurations, options, and choices that need to be made during the optimization of a service. Consult Esri documentation, resources, and conference proceedings for additional guidance in these areas.
Related resources:
Map image layer tiles are raster images that display a pre-rendered view of data, which is then drawn on the client as a set of multiple, stitched-together tiles for each display extent. Raster tiles can be created from map services, hosted feature services, or image services, with slightly different considerations for each.
Raster tile caching is an effective method to use when delivering relatively static data that should be viewed in one primary cartographic representation. Map cache creation can be intensive in both time and compute resources required, so it works best for data that are infrequently updated. While raster tiles can provide excellent performance and scalability, they do not provide the user with the ability to query for attributes, identify features, or change symbols, turn off labeling layers, and so on.
While raster tiles were used for many years to delivery cartographic basemaps, these services most often use vector basemaps today for a variety of performance, map quality, and flexibility reasons. Raster tiles are still used to serve many imagery basemaps or services based on satellite or ortho-photography, as these services aim to present a single, carefully balanced layer of imagery as a background for applications or tools.
To learn more about map image layer caching, see these resources:
Vector tile caching is similar in concept to raster tile caching, but the tiles are compressed binary files (based on protocol buffers) which store vector features as geometry and attributes, cut into individual tiles which are then re-assembled and rendered on the client according to a separate style definition.
Vector tile caching is appropriate where a raster tile might be limiting or unsuitable for other reasons. Vector tiles can be faster to generate and smaller in size than raster tiles, which has benefits for storage of the tile set as well as in the speed at which they are transferred to a client over a network connection.
Vector tiles also allow for dynamic rendering through the use of a vector tile style, which can be configured or updated entirely on the client, such as a browser or native application, and can dynamically show or hide different layers, filter based on attributes, and display multiple different cartographic versions of the same data, all using the same single vector tile layer.
Unlike vector tiles and raster tiles, feature tiles are not pre-generated by a planned process. Instead, they are generated by functionality-aware clients requesting standardized extents of data for standard zoom levels. Since these requests are identical between different clients, the features can be cached and reused or re-sent to different clients. This functionality is exclusively available for use by clients that are designed to use this feature, primarily through the ArcGIS Maps SDK for JavaScript, as well as through ArcGIS Pro and native applications built with the ArcGIS Maps SDKs.
The use of feature tiles relies on two key assumptions:
Hosted feature services in ArcGIS Online also include an option to enable optimized layer drawing, which can generate reduced-resolution data in the database that are used to display smaller (more zoomed-out) scales. This reduced-resolution data is automatically queried by the feature tile generation process when using those scales, which in turn improves response performance.
To learn more about feature tile caching, see these resources:
In ArcGIS Enterprise, you can configure both map and feature services to return a Cache-Control header that allows a user’s browser to take advantage of caching response content based on an Etag value.
When clients send requests to ArcGIS Server to request a map export or query a feature service with this setting applied, the response from the server can then typically cached by the browser and reused for a certain period of time. However, depending on how your map or feature service and its associated data are used in applications, you may consider adjusting the length of time the browser will use a response in its cache. This can be achieved by adding a property named cacheControlMaxAge to the JavaScript Object Notation (JSON) definition of the service.
A Content delivery network (CDN) caches content on edge servers that are located in closer geographic proximity to the user. CDNs reduce response times for requests by eliminating the need for a database query and reducing latency from longer network travel.
Both publicly-shared hosted feature layers and the web application static assets hosted in ArcGIS Online automatically make use of a global CDN for caching of feature tiles and static app responses. Learn about controlling the CDN cache for hosted feature layers in ArcGIS Online. The ArcGIS Online CDN is also used to accelerate the response for public cached map image layers (raster tiles) and vector tile layers, as well as the various ArcGIS Online basemap services.
CDNs can also be used with web applications hosted in ArcGIS Enterprise but be careful to make a distinction between static assets that are suitable to caching in a CDN, such as HTML, CSS, and JavaScript files, and more dynamic REST API responses that should not be cached to avoid unexpected user behavior. Also take particular care in considering the use of a CDN as it relates to upgrades. The CDN cache should be forcefully invalidated when ArcGIS Enterprise is upgraded or an application changes to ensure users do not receive outdated information.
The blog post A Content Delivery Network (CDN) approach to ArcGIS Enterprise using AWS CloudFront provides one example of using a CDN with ArcGIS Enterprise.