A couple of weeks ago, I shared a quick tip on working with multiple InfoWindows with the Google Maps API specifically within the context of WordPress.

Google Maps InfoWindow

When working with this API, there are a number of considerations to take into account each of which is going to depend on how much of the API you’re going to be using; however, one constant that’s going to remain regardless of how much you’re using is the rate limit.

That is, unless you’ve paid Google a decent chunk of change, then you’re going to have to take rate limiting into account whenever you’re working with this API. And if you’re charting quite a few locations for, say, several different pages or several searches, then you can hit that limit quickly.

If you’re not at the point where you can pay Google to up the rate limit, but you’d like to still make sure your project doesn’t totally bomb out if the rate limit is hit, then I recommend using transients to store Google Maps data for an interval of time so that you aren’t making frequent calls to the API.

Storing Google Maps Data

At a high-level, here’s how it works:

  • A user will execute a search or load a page that’s responsible for mapping a location (or locations)
  • The page will shoot a request over to Google who will then respond with the information while also keeping track of how many requests your project has made within a 24-hour period

Easy enough to understand, isn’t it? But then let’s say that you have thousands or hundreds of thousands of users hitting pages or making requests, then Google will quickly tally those requests and you’ll hit the rate limit.

When that happens, Google will fail to respond with the information necessary to plot the markets on your map and you’ll be left with a blank canvas.

No good.

Sure, there are a number of solutions to this particular issue, but if you’re working with WordPress then one of the easiest things that you can do is setup a transient to store the request for a specified interval of time.

That is, let’s say you have all of the latitude and longitude coordinates located in an array. You can then store those coordinates into an array for, say, 12 hours:

And when the page is hit, you can first check to see if the value exists in the transient data. If not, then make a request to Google:

Ultimately, what will happen is that most people will grab the information from the transient, no request to Google will be made, and the page will load quickly.

Once the transient expires, however, at least one person will fail to find the information in the transient so a new request to Google will be made. When the data comes back, throw it back into the transient and the subsequent visits will result in the same behavior.

Sure, there are other strategic ways that you can go about improving this process, but if you’re looking for the first-level of improvements to make and looking for something that’s offered by the WordPress API, I recommend this process.

Note that in order to improve the readability of the code above, I’d likely break the code that exists in the first gist (or in the body of the conditional) into a function or two, but it demonstrates the use case for this example.


Join the conversation! 4 Comments

  1. This is especially important if you’re hitting the geocode API to transform a human-readable address into lat/lon coordinates. Google does not like it if you hit that API over and over:

    Geocoding is a time and resource intensive task. Whenever possible, pre-geocode known addresses (using the Geocoding API described here or another geocoding service), and store your results in a temporary cache of your own design.

    I’d go farther and say you should actually store the result somewhere permanent, unless you have reason to believe that it will change regularly and in ways that you can’t easily predict and reset. If you’re working from an “address” option in the database, like post meta or wp_options, you should probably be storing the lat/lon alongside it.

    •  I’d go farther and say you should actually store the result somewhere permanent, unless you have reason to believe that it will change regularly and in ways that you can’t easily predict and reset.

      I agree with this. If you have a fixed set of data that’s not going to be changing, this works great; however, if someone is going to be putting information in about a place, location, or event or something like that, then you’re going to need to update the data.

      Of course, you could hook into the save_post action or another similar action to trigger the refresh of the cache when that happens so it’s still possible to make this happen whenever new information is added.

  2. Tom,

    Great piece. You’re missing the data on your set_transient line, though!



Leave a Reply