This guide describes several strategies to optimize your Google Maps APIs usage in terms of security, performance, and consumption.
Reviewing security best practices
API keys are project-centric credentials that deserve the same precautions as user IDs and passwords. Review the API Key Best Practices to secure your keys from unintended use which could lead to undue quota usage and unexpected charges to your account.
Using API keys to access Maps APIs
Using exponential backoff to handle errors
If your apps experience errors from excessive attempts to call an API within a short period of time, such as QPS errors, consider using exponential backoff to let the requests process.
Specifically, you would adjust the pace of your queries. In your code, add
a waiting period of
S seconds between queries. If the query still results
in a QPS error, double the waiting period and then send another query. Continue
adjusting the waiting period until the query returns without an error.
Sending user-interaction requests on demand
Requests to APIs that include user interaction should be sent only on demand.
This means waiting for the end user to perform an action (such as
to initiate the API request, then using the results to load a map, set a
destination, or display appropriate information. Using an on-demand approach
avoids unnecessary requests to the APIs, reducing API consumption.
Avoiding displaying overlay content when a map is moving
Draw() to display custom overlay content on a map at the same
time that a user might be moving the map. Since the map is redrawn every time
a user moves the map, placing overlay content on the map at the same time can
introduce lag or visual stuttering. Only add or remove overlay content from a
map once the user stops panning or zooming.
Avoiding intensive operations in
As a general rule, it is good practice to avoid performance-intensive
non-drawing operations in a
Draw() method. For example, avoid
the following in your
Draw() method code:
- Queries that return a large amount of content.
- Many changes to the data being displayed.
- Manipulating many Document Object Model (DOM) elements.
These operations can slow performance and introduce lag or visual stuttering when the map renders.
Using raster images for markers
Use raster images, such as images in .PNG or .JPG format, when adding markers to identify a location on a map. Avoid using Scalable Vector Graphics (SVG) images, since rendering SVG images can introduce lag when the map is redrawn.
Creating clusters to manage marker display
To help manage the display of markers to identify locations on a map, create a marker cluster using the Marker Clusterer library. The Marker Clusterer library includes options for:
- Grid size, to specify the number of markers to group together in a cluster.
- Maximum zoom, to specify the maximum zoom level in which to display the cluster.
- Image paths, for the graphics images to use as marker icons.
To plan your budget and control your costs, do the following:
- Set a budget alert
to track how your costs are growing toward a particular amount. Setting a budget
does not cap API usage - it only alerts you when your costs get close to your
- Cap your daily API usage to manage your costs for billable APIs. By setting caps on requests per day, you can limit your costs. Use a simple equation to determine your daily cap, depending on how much you want to spend: (monthly cost/price per each )/30 = requests per day cap (for one API). Your specific implementation may use multiple billable APIs, so adjust the equation as needed. A $200 USD Google Maps APIs credit is available each month, so factor that into your calculations.
- Use multiple projects to isolate, prioritize, and track your usage. For example, suppose you regularly use the Google Maps Platform APIs in your tests. By creating a separate project for your testing - with its own quotas and API keys - you can thoroughly test while guarding against surprise over-spending.
Managing consumption in Maps
Using a single map per page is a good way to optimize maps display, since users generally interact with only one map at a time. Your app can manipulate the map to display different data sets, depending on customer interaction and needs.
Using static images
Requests that use dynamic imagery (Dynamic Maps and Dynamic Street View) cost more than Static Maps and Static Street View. If you don’t foresee user interaction with Map or Street View (zooming or panning), use the static versions of these APIs.
Thumbnails - very small maps and photos - are another good use for Static Maps and Static Street View. These items are billed at a lower rate and upon user interaction (on-click), and can take users to a dynamic version for a full Google Maps experience.
Using the Maps Embed API
You can use the Maps Embed API to add a map with a single marker, or a dynamic map, free of charge. Use the Maps Embed API for applications where a single marker and no map customization is required. Maps Embed API requests utilizing Directions mode, View mode, or Search mode will be billed (see the pricing table for details).
Using mobile maps SDKs for mobile applications
Managing consumption in Routes
Limiting Directions API waypoints
When possible, limit user entries in a query to a maximum of 10 waypoints. Requests containing more than 10 waypoints are billed at a higher rate.
Using Directions API optimization for optimal routing
Requests using the waypoint optimization argument are billed at a higher rate. For more information, see Optimize Waypoints.
The optimization argument sorts waypoints to ensure optimal routing, meaning that travel from A to E is a better experience when optimized (A-B-C-D-E) versus the random sequence of a non-optimized route (such as A-D-B-C-E).
Using real-time traffic models in Directions API and Distance Matrix API
Directions API and Distance Matrix API
requests that include real-time traffic models are billed at a higher rate.
Real-time traffic models are enabled by setting the departure time to
If traffic models are omitted from a request, the results are based solely on physical factors: roads, distance, and speed limits.
Using Route Traveled & Nearest Road when GPS data is imprecise
The Maps Roads API features, Route Traveled and Nearest Road, are included in the advanced tier and are billed at a higher rate. Use these features where GPS data is imprecise and the Roads API can help determine the correct road. Speed Limits, another feature of the Roads API, is available only to Asset Tracking customers.
Sampling speed limit locations at 5- to 15-minute intervals
To minimize the volume of calls to the Maps Roads API Speed Limit service, sample the locations of your assets at 5 to 15 minute intervals. The exact value depends on the speed at which an asset is traveling. If an asset is stationary, a single location sample is sufficient. There is no need to make multiple calls.
To minimize overall latency, call the Speed Limit service once you have accumulated some data rather than calling the API every time the location of a mobile asset is received.
Managing consumption in Places
Using the Autocomplete option that fits your use case
Identify the Autocomplete option that best fits your use case, as both options have the same cost. The difference between the two options is how your application's end users can leverage the APIs.
- Autocomplete - Per Request: ideal for use cases where a single entry is enough, such as a mailing address form that a user fills out.
- Autocomplete - Per Session: Best used when multiple entries are required, such as searches for a hotel or restaurant.
Autocomplete - Per Session allows unlimited results, but requires the implementation of tokens to ensure sessions are valid. If an invalid session occurs, Autocomplete - Per Request charges are applied per keystroke, which could lead to higher billings. For more information about this feature, see Place Autocomplete.
Returning data for specific fields in Place Details and Place Search requests
You can customize Place Detail and Place Search requests to return data for specific fields used in your application. These fields are broken into categories: Basic, Contact, and Atmosphere. Requests that do not specify any fields will receive data for all fields.
Billing for Place Detail requests is based on the types and amounts of data requested. Requests that do not specify any fields will be billed at the full rate. For more information, see Place Details and Place Search.
Reducing costs by using the Geocoding API
If your application handles user-typed addresses, the addresses are sometimes ambiguous (incomplete, misspelled, or poorly formatted). Disambiguate addresses using Autocomplete, then use the place IDs to get the place locations.
If you have an exact address (or close to it), however, you can reduce costs by using Geocoding instead of Autocomplete. For more details, see Geocoding Addresses Best Practices.