Blog
Google API Response Time vs. TravelTime API: Why we’re 500x Faster
chris hutchinson
Contents
At TravelTime, we are obsessed with API performance.
Why? Because we know that fast response times, accurate results and vast data handling capabilities are critical for our customers.
Whether you are integrating the TravelTime API for live search on your customer-facing sites or need to process huge volumes of data, we are committed to ensuring that TravelTime is the best distance matrix API on the market.
It was to meet these requirements that we built our highest performance TravelTime Matrix endpoint, which uses Protocol Buffers rather than JSON to save time on serialisation / deserialisation and network transfer.
API Performance Benchmarking: Google Distance Matrix API vs. TravelTime Matrix Endpoint
We ran a series of performance benchmarks to compare the Google Distance Matrix API to the TravelTime Matrix endpoint.
Methodology
We sent a range of one-to-many matrix API requests varying from 5,000 to 100,000 locations. The results highlight the notable speed difference between the TravelTime API and the Google Distance Matrix API.
The Google endpoint has a limit of 1,000 elements per second, and therefore the response times effectively scale linearly with the number of elements.
Average Response Time Comparison
There are two clear conclusions that we can draw from the performance benchmark results.
- The results for the TravelTime API are always significantly faster than the Google API, regardless of the number of locations or transport mode. Google’s closest performance is 32x slower than TravelTime for a driving request with 5,000 locations. A huge 5 seconds vs 158 milliseconds.
- Furthermore, the API performance gap between the TravelTime API and Google API increases dramatically as the number of locations increases, indicating TravelTime’s superior scalability. For matrices of 50,000 locations or larger, TravelTime is more than 500x faster than Google.
How we reduced API response time
We offer a number of different distance matrix endpoints (a full comparison of these can be found here aimed at different use cases. In this comparison we used our Protocol Buffers endpoint which is built for the highest performance requirements.
The extremely low response times offered by this endpoint are achieved through a reduced set of available parameters (e.g no specific arrival or departure time). This enables more data to be precomputed, leaving only the bare minimum of calculations that are made at runtime depending on the locations in the request.
How we reduced API latency
The Protocol Buffers endpoint provides a further performance improvement versus the other JSON distance matrix endpoints that we support:
- Binary is faster to serialize and deserialize than JSON
- The binary messages are smaller in data size and therefore there is less network latency
These combine to allow requests with 100,000 locations to be calculated and results returned within 140ms.
How to optimise API response time
It’s clear that the TravelTime API performance scales incredibly well as the number of locations increases. For example, for driving requests, our response time for 100,000 locations is only 19% slower than the response time for 5,000 locations. In contrast, Google’s fixed limit of 1,000 locations per second makes its effective response time 20x slower for 100,000 locations.
Example TravelTime Matrix Fast Protobuf API request for 100,000 locations
Why is TravelTime API performance so important?
TravelTime’s customers broadly fall into two buckets:
- Customers who use the API in alive front-end application, where a travel time element is being added into a traditional search such as property sites, recruitment sites, or hotel booking sites.
- Customers who leverage the API in a back-end application where travel times are required as part of a wider analysis, including route scheduling, site selection, and demand forecasting.
For front-end applications, our API’s response time forms part of the overall search run time. Because a traditional distance-based search has a very low performance overhead, for customers to want to switch to a time-based search, there needs to be minimal impact on performance. Failing this, the benefit of more relevant results associated with a time-based search could be offset by slower page loading times and higher bounce rates.
On the other hand, back-end applications don’t rely on response times for the user experience, as the API requests are typically made asynchronously to when the results of the analysis are displayed. But in these scenarios, there is often a requirement to ingest huge amounts of data, such as the travel time between every postcode and every other postcode across an entire country. This could involve billions of results and slow response times could limit the practical amount of data that can be used in a reasonable time frame.
Disappointed with Google Maps API performance?
If you are looking to implement a Distance Matrix service into your business, whether in a live front-end search application or in a back-end data analytics application, performance is incredibly important.
Our Travel Time Matrix (Protocol Buffers) service was built for exactly this need.
Performance benchmarks show that it is orders of magnitude faster than alternative offerings like the Google Distance Matrix API, and this performance scales impressively as request sizes grow.
Experience this performance for yourself in our API playground here.
Start building the API into your own applications by signing up for a free trial API key below.
chris hutchinson