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
.)
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.
Estimate your costs for any GMP API product, based on your total request volume
.