G’day mw360,
Each map that uses coordinates or loads a KML file makes one Maps JavaScript API call each time the map is viewed. That happens client-side in the browser, so it’s the same whether the page is cached or not.
Each map that uses an address for its marker requires an address lookup, which uses the Geocoding API. To reduce the number of API hits, the plugin makes that request server-side and caches the answer for up to a week*. It then makes one Maps JavaScript API call each time the map is viewed. If the server-side address lookup was unsuccessful**, the lookup happens client-side in JavaScript, which means an additional API hit each time the map is viewed.
When you use the Directions feature, each time a visitor requests directions, that makes a Geocoding API request in JavaScript.
* “up to a week” means it uses a transient which should hold the information for a week, in theory, but might not if something deletes unexpired transients — e.g. an under-provisioned memcached or redis object store, or just turning on the “object cache” functionality of W3 Total Cache (which borks object caching).
** when initially implemented, server-side address lookups were very successful. Now, it’s hitting request quota limits very quickly without an API key. I’m about to release a new version that lets you set an API key for server-side lookups, if you’d like to try it out:
https://www.dropbox.com/s/3ieytpjrks6gd00/wp-flexible-map-1.14.0-dev.zip?dl=1
If your API key has no restrictions, you will be able to use the same key for both JavaScript and Server API key.
NB: you should have restrictions on your key, otherwise people can copy your key (from the browser) and use it on their website — which means more hits to the API. This means you will need a second key, either unrestricted or restricted by IP address, for the server side queries. More doco coming 🙂
cheers,
Ross
