"How many graphics can I put on my map?" or "How many points can I put on a map?" are frequently asked questions. This help topic will try to provide some guidelines and best practices for determing how many graphics are appropiate for display on a map.

There are two sample apps that will aid in answering how many graphics are appropiate for a map. The first displays an arbritary number of points on a map (the second is linked to below). The objective of that app is to see how many graphics you can add to a map before performance starts to suffer. Since this is dependent on many factors (your browser, your hardware, your definition of "suffer"), it is probably best to let you see for yourself how a map performs with 100, 1,000 and even 10,000 graphics.

There is also an option to select symbol type. Not all point symbols are equal in terms of performance so it is important to realize that 500 picture marker symbols might result in a more sluggish app than one with 1,000 simple marker symbols.

After determining what a browser can handle in terms of raw numbers, it is time to consider user experience. Does putting a map with thousands of point graphics on a 15" screen provide a meaningful user experience? In most cases, probably not. Outside of looking for a general spatial distribution pattern, you are probably not helping a user discover much or answer any particular question by showing thousands of point graphics at one time. If you find yourself in this situation, it is a good time to consider using a raster surface (like a heatmap), filtering your data through queries, or maybe clustering.

Using polygon graphics is a bit more complex. Not only do you need to worry about the number of polygons, but the number of polygon vertices is also an important consideration. More detailed geometries take longer to transfer to the client, and once they make it to the client, they require more resources to display.

To see how more complex geometries slow down an application, but do not necessarily add anything of value, take a look at a sample app that incrementally adds U.S. County polygons to a map. The app allows you to toggle the usage of maxAllowableOffset when querying for features. Using maxAllowableOffet can dramatically reduce feature sizes for detailed features. See the Feature Layer Best Practices topic for more information on maxAllowableOffset.

Draw time and user experience once graphics are on a map are the big two to consider when trying to determine limits for map graphics. Two other pieces of the equation are query time and download time. Query time refers to the amount of time it takes a server to generate a response and download time refers to the amount of time it takes for a client to download a response from a server. If too much time is spent for either, user experience suffers. If query and/or download takes too long, users may lose interest before the data arrives. Application developers should aim for minimizing download and query time. The best general strategy for both is for an app to only request the data it needs.