KML Optimization: Tip # 2 - Find out who your target audience

You need to think about who will be the consumers of your KML, to determine whether you need the most optimized content, or prefer it to be as compatible as possible between the three forms currently available for viewing a KML: Google Earth, Google Earth Plugin and Google Maps.

If you know in advance that her KML always will be consumed by Google Earth Plugin, you can give up certain elements will not be used by this tool, such as the element that controls whether an object will appear or not in the listview Google Earth. The presence of this tag in KML to be consumed by the GE Plugin will be innocuous, because it will not use this element for anything.
Now imagine a KML containing 500, 1000 or 10000 Placemarks and each containing an element . Consider:

1 placemark = 1 = 24 bytes 
500 placemarks = 24 x 500 = 12.000 bytes = ~11 Kbytes

We will have 11 Kbytes of waste with an element that is ignored during parsing and anything that will add to our content, and we're talking just a preview of this KML. If it is a KML NetworkLink that updates itself the waste is even greater. Assuming an hourly refresh, would be wasted 281 Kbytes per day or 8 megs for a 30-day month!

This waste is for only one user consuming a KML supplied by our server. If the infrastructure and clients that will consume this KML are internal (corporate), the situation is also bad, because link bandwidth of the company is being wasted and will affect the quality / availability of other services also depend on these links.

Let's hypothetically simulate some users consuming this KML:

1 user = 8 Mb waste / month
5 users = 5 x 8 = 40 Mb waste / month
10 users = 10 x 8 = 80 Mb waste / month
100 users = 100 x 8 = 800 Mb waste / month

And all these numbers here are based on the analysis of only one element of the KML is being generated unnecessarily. Imagine how much server processing and bandwidth of the link may be being wasted? How many other elements in your KML is being generated but will not be used?

Now when you do not know the target audience that will consume the KML or to generate content that is compatible with the GE, GE Plugin and Maps, the strategy is to use the normal tags to be processed by each tool. Will give up the optimization, but you can view the contents correctly on any platform that you desire.

My feeling is that most developers KML know in advance which platform for generating content and are therefore able to learn what elements make sense or not be present in your KML.

Below I build a table containing the elements and which platform makes sense for it to be exported in KML:

 KML version 2.2:

Element	Google Earth	Google Earth Plugin	Google Maps
<gx:altitudeMode>	●	●
<gx:AnimatedUpdate>	●	●
<BalloonStyle>	●	●
<gx:balloonVisibility>	●	●
<Camera>	●	●
<ColorStyle>	●	●	●
<Document>	●	●	●
<gx:duration>	●	●
<ExtendedData>	●	●
<gx:FlyTo>	●	●
<Folder>	●	●	●
<Icon>	●	●	●
<IconStyle>	●	●	●
<kml>	●	●	●
<LabelStyle>	●	●
<gx:LatLonQuad>	●	●
<LinearRing>	●	●
<LineString>	●	●
<LineStyle>	●	●
<Link>	●	●
<ListStyle>	●
<LookAt>	●
<Model>	●
<MultiGeometry>	●
<gx:MultiTrack>	●
<NetworkLink>	●
<NetworkLinkControl>	●
<PhotoOverlay>	●
<Placemark>	●	●	●
<Point>	●	●	●
<Polygon>	●	●
<PolyStyle>	●	●
<Region>	●	●
<Schema>	●	●
<ScreenOverlay>	●	●
<Style>	●	●	●
<StyleMap>	●	●
<TimeSpan>	●	●
<TimeStamp>	●	●
<gx:TimeSpan>	●	●
<gx:TimeStamp>	●	●
<gx:Tour>	●	●
<gx:Track>	●	●
<Update>	●	●

Of the three platforms presented, Google Maps is the least that supports KML, due to its 2D nature, and Google Earth is the most support.

Think about who will be the consumer of your KML and make the right choice.
Waste is a sign of inefficiency.

Good coding!