views:

559

answers:

3

Just curious, whether the Google Maps API v3 javascript be cached on the local server?

Because, sometimes my intranet pages are loading slow because of slower internet connection. Otherwise, it would load the file from local server and slow down only when the map request is made.

I am even ready to run a cron job to update the javascript file once in a while.

Thanks for any input.

+1  A: 

IMHO you can't cache it. The API script calls objects on the Google server. At most, you can capture the results and cache them as images (but then you lose interactivity).

If it would be possible to cache GMap results, people would just cache Google's entire DB locally and I don't think this is part of the user agreement ;).

If you want offline maps, you'll have to do with non-interactive images, or buy a map server.

Traveling Tech Guy
Map server! I would love one, but not our finance department :( I am not looking to cache the results. The Gmap javascript functions that get loaded in the `<head>` section is what taking the entire time. If I could cache the fetched .js file, I can instead call it from the local server. But the geocoding or map requests can be made directly from Google.All I am looking at is whether there would be any impact on doing so.
Nirmal
+4  A: 

It's impossible "as is".

When you request he script from Google, they send headers along the script and those headers contains the "no-cache" directive.

So if you want them to be cachable, you must create a proxy. Instead of pointing the script src at Google, you point it to your server. Your server then make the call to Google and send the response back to the client.

This way you'll have control over the HTTP header and the caching. You could do caching on the script content as well to make less connections to Google.

I wouldn't advise someone to do it on a production or a mission critical website. All Google APIs are updated frequently and are bound more or less together. If something goes out of synch with something else, you have a hard to track bug on your hands.

Hope that helps.

EDIT: I heard you were putting your scripts in the HEAD section of your document. Maybe thats hurting your "perceived" page loading time. Try to move the download of the script just before the </body> tag and the map initialization in the onload event of the page.

Mike

Mike Gleason jr Couturier
Thank you for the explanation. You are right that Google updates the API almost every week. I didn't think in that perspective.
Nirmal
You're welcome.. the v3 API is more compact and faster than the v2 so I wouldn't worry. Instead, you should look on how you initialize your stuff like I said. See http://developer.yahoo.com/performance/rules.html particularly the "Put Scripts at the Bottom" section.
Mike Gleason jr Couturier
+1 for the added help. That link of Yahoo is really useful. I didn't think much of performance issues because the pages are strictly in the intranet. But now I feel I should give a serious consideration to the best practices, for our organisation is in the edge of being spread to multiple geographical locations. Without fine tuning, I would really be in a trouble. Thanks again.
Nirmal
A pleasure, I ran into the same questioning while programming my own site (http://pokerplanner.org) That's why I learned all that stuff.
Mike Gleason jr Couturier
A: 

An option that would not have you violating Google's Terms of Service would be to keep a local cache of OpenStreetMap tiles with the OpenLayers script for viewing them. Basically, using free data to create your own map server.

If there are particular points of interest that are important for your intranet, you can make sure that they are in OpenStreetMap and setup a rendering server yourself with just the features you require. After all, overlaying each school in a district over some png's is going to take more work then just showing the png's made with the schools in them.

It also would take a lot less lag on a slow outside connection if your map server gets/generates the tiles during the weekend instead of hitting the Google Map API all the time.

sargas