Optimization Guide

This guide describes several strategies to optimize your Google Maps APIs usage in terms of security, performance, and consumption.

Security

Reviewing security best practices

API keys are project-centric credentials that deserve the same precautions as user IDs and passwords. Review the API Security 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

API keys are the preferred authentication method for accessing Google Maps APIs APIs. While using the client IDs is currently still supported, API keys support finer-grained security controls and can be tuned to work with specific web addresses, IP addresses, and mobile SDKs (Android and iOS). For information on creating and securing an API key, go to the "Using an API Key" page for each API or SDK. (For example, for the Maps JavaScript API, visit its page on Using an API Key.)

Performance

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.

Exponential backoff is most useful for errors in the 500s. For more information, see Handling HTTP return status codes.

Specifically, 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 on-click) 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

Avoid using 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 Draw methods

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.

Optimizing markers

Optimization enhances performance by rendering many markers as a single static element. This is useful in cases where a large number of markers is required. By default, the Maps JavaScript API will decide whether a marker will be optimized. When there is a large number of markers, the Maps JavaScript API will attempt to render markers with optimization. Not all Markers can be optimized; in some situations, the Maps JavaScript API may need to render Markers without optimization. Disable optimized rendering for animated GIFs or PNGs, or when each marker must be rendered as a separate DOM element.

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.

Consumption

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 specified amount.
• 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

For mobile applications, use Maps SDK for Android or Maps SDK for iOS when displaying a map. Use the Maps Static API or Maps JavaScript API when requirements rule out using the mobile SDKs.

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 now.

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

Optimizing Place Autocomplete implementations

To optimize the cost of using the Place Autocomplete:

• use field masks in the JavaScript, Android, and iOS Autocomplete widgets to return only the Place Data Fields you need.

• select billing options depends on your use case. Depending on whether your implementation uses Autcomplete sessions or not, you will be charged either Autocomplete - Per Request or Autocomplete - Per Session SKUs.

For more information and guidance on selecting the right option for your use case, see Place Autocomplete cost optimization best practices.

Returning data for specific fields in Place Details and Place Search requests

You can customize Place Details 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 Details 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.

How Google Maps Platform quotas work

All of our APIs have limits on how many calls each customer can make. These quotas are configured on a per-minute basis. Once you have reached the quota of calls on a given API in a minute, future calls will not be accepted until the next minute.

Only successful requests and requests that cause server errors count against quota. Requests that fail authentication do not count against quota.

Several Maps APIs have per-second enforcement in addition to the per-minute quota enforcement. This per-second enforcement does not guarantee uniform usage over the entire minute, nor will it prevent you from reaching your usage quota for that minute. It does keep you from using up all of your quota in the first second or two of any given minute, and protects you from service disruptions in the event of sudden usage spike. To deal with these enforcement differences, plan your quota usage and requirements by averaging your QPM usage across QPS.

The GMP APIs that have this per-second enforcement are Directions API, Distance Matrix API, Elevation API, Geocoding API, Places API and Roads API.

Note for Distance Matrix API developers: The maximum size of the allowed distance matrix decreases with the elements-per-minute (EPM) limit you choose. If your EPM limit is set too low, you will not be able to issue successful Distance Matrix API requests.

For example, to be able to issue a 10 × 10 matrix at any point during a given minute, set a quota that allows you to do so at any second during that minute. Thus, your minimum per-minute quota would be set to (10 × 10) × 60 seconds, or 6000.

Estimate your costs for any GMP API product, based on your total request volume.