OK, so I’m breaking a promise; guess I’m a certified fanboi.
Over at Google LatLong, they just announced increased limits for KML in Google Maps. The real news, though, is that they are now following network links based on zoom extent. This means that there are more applications where you can just publish a KML service rather than messing with the Maps API.
For example (careful, it can be pretty sluggish in certain browsers) here’s my city’s main KML file displayed in Google Maps:

As cool as this is, in many cases you still have to design your KML files differently than you would for Google Earth. The browser is very limited in the amount of data that it can display–so you have to send back less data–and certain visual elements are handled differently in Maps. To deal with these limitations, there are several things that immediately come to mind as potential performance gains:
- In your network links, check the bounding box extents before returning data that is too dense for the current zoom level. Basically you just take the max (or average) of width and height, and don’t return data unless it’s lower than a predetermined value. This was the original method for controlling content in Google Earth before Regions were introduced, and is quite effective in two dimensions.
- Stay away from fancy elements like multi-geometry for mouse-overs. They don’t work in Maps. If your information can be communicated using points, then stick with points.
- If you must use lines/polygons, simplify your data so that unimportant vertices are removed
- Keep the information in your descriptions to a reasonable level.
It may also be worth experimenting with Regions to see if they are supported and make a performance difference.
Check out the original post for more examples of KML in Maps.
-J