Stay organized with collections Save and categorize content based on your preferences.
The traffic preferences you select balance the accuracy of the route details with request performance in one of two ways:
Traffic aware -- Return the most accurate results possible (higher latency).
Traffic unaware -- Return the results as quickly as possible (lowest latency).
When you make a request, weigh whether it is better to return the most accurate results possible, or to return results as quickly as possible. The Routes API provides options that let you control the quality of the response data versus the latency of the response.
How to set the traffic levelThe Routes API provides RoutingPreference (REST) and RoutingPreference (gRPC) that let you specify routing preferences for calculating routes.
The default is traffic unaware results. You select traffic options with the TRAFFIC_UNAWARE, TRAFFIC_AWARE and TRAFFIC_AWARE_OPTIMAL routing preferences. Each routing preference produces results that differ in route quality, estimated ETA, and response latency.
TRAFFIC_AWARE and TRAFFIC_AWARE_OPTIMAL are billed at a higher rate. Learn more about billing. Traffic conditions
Traffic conditions characterize the rate of traffic flow:
Normal traffic: No congestion with traffic flowing at a normal speed.
Light to moderate traffic: Increasing congestion, with traffic flowing at a reduced speed.
Heavy traffic: Severe congestion, with heavily reduced traffic speed.
TRAFFIC_UNAWARE is the default setting. Use this routing preference when you want responses returned the quickest, and approximate routing details are good enough.
TRAFFIC_UNAWARE routes are calculated without accounting for current traffic conditions. This routing preference results in the fastest request response (lowest latency).
If you choose TRAFFIC_UNAWARE, the route and duration chosen are based on road network and average time-independent traffic conditions, not current road conditions. Consequently, routes may include roads that are temporarily closed. Results for a given request may vary over time due to changes in the road network, updated average traffic conditions, and the distributed nature of the service. Results may also vary between nearly-equivalent routes at any time or frequency.
Here are the responses you'll see:
duration - Contains the ETA for the route.
staticDuration: The ETA for the route considering only historical traffic information. For TRAFFIC_UNAWARE, this contains the same value as duration.
Use this routing preference when you want more accurate routing details than TRAFFIC_UNAWARE, and yet you don't mind if responses are returned with a moderate increase in latency.
When you set the TRAFFIC_AWARE routing preference, the service calculates the route considering current traffic conditions. As a result, the route and route details more accurately reflect real-world conditions. Because this increase in data quality comes at the expense of response latency, performance optimizations are applied to reduce much of the latency.
Here are the responses you'll see:
duration: The ETA considering real-time traffic information.
staticDuration The ETA for the route considering only historical traffic information.
Use this routing preference when you want results of the highest quality without regard to how long responses take. This routing preference has the longest delay in returning responses (highest latency).
When you set the TRAFFIC_AWARE_OPTIMAL routing preference, the service calculates the route considering current traffic conditions, but doesn't apply performance optimizations. In this mode, the server performs a more exhaustive search of the road network to find the optimal route.
The TRAFFIC_AWARE_OPTIMAL routing preference is equivalent to the mode used by maps.google.com and by the Google Maps mobile app.
When you use this option with Compute Route Matrix, the number of elements in a request (number of origins × number of destinations) cannot exceed
Here are the responses you'll see:
duration: The ETA for the route considering real-time traffic information.
staticDuration: The ETA for the route considering only historical traffic information.
Use this property only for traffic aware requests where the departure time needs to be in the future. If you don't set the departureTime property, it defaults to the time that you make the request.
Use the departureTime property along with the TRAFFIC_AWARE and TRAFFIC_AWARE_OPTIMAL options when you want to adjust the way the service predicts traffic when choosing a route.
TRAFFIC_UNAWARE: Not recommended because the choice of route and duration are based on the road network and average time-independent traffic conditions.
TRAFFIC_AWARE and TRAFFIC_AWARE_OPTIMAL: Recommended for departures happening in the near future because these preferences take live traffic conditions into consideration. Live traffic becomes more important and relevant the closer the departureTime is to now. The farther ahead you set the departure time into the future, the more consideration is given to historical traffic conditions in selecting routes.
The following JSON code demonstrates how to set the TRAFFIC_AWARE_OPTIMAL routing preference in a request message entity body.
{
"origin":{
"location":{
"latLng":{
"latitude":37.419734,
"longitude":-122.0827784
}
}
},
"destination":{
"location":{
"latLng":{
"latitude":37.417670,
"longitude":-122.079595
}
}
},
"travelMode":"DRIVE",
"routingPreference":"TRAFFIC_AWARE_OPTIMAL"
} Configure traffic on polylines
The Routes API lets you request information about traffic conditions along a traffic-aware polyline. See Request polylines for more information.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-08-14 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-14 UTC."],[[["The Routes API offers three traffic preferences: `TRAFFIC_UNAWARE` for fastest response, `TRAFFIC_AWARE` for balanced accuracy and speed, and `TRAFFIC_AWARE_OPTIMAL` for the most accurate results with higher latency."],["`TRAFFIC_UNAWARE` uses average traffic conditions and is suitable for scenarios where speed is prioritized over accuracy."],["`TRAFFIC_AWARE` considers real-time traffic but applies optimizations for faster responses."],["`TRAFFIC_AWARE_OPTIMAL` performs an exhaustive search for the best route based on live traffic, similar to Google Maps, but results in higher latency."],["Departure time can be set for `TRAFFIC_AWARE` and `TRAFFIC_AWARE_OPTIMAL` to influence how live and historical traffic conditions are weighed."]]],[]]
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4