Since we are sending large amounts of data to Virtual Earth maps IIS compression can reduce the bandwidth required speeding up the transfer.

From Microsoft:

IIS provides the following compression options:

• Static files only.
• Dynamic application responses only.
• Both static files and dynamic application responses.

How HTTP Compression Works

When IIS receives a request, it checks whether the browser that sent the request is compression-enabled. (Recent versions of Microsoft® Internet Explorer and most other browsers typically send the following header if they are compression-enabled: Accept-Encoding: gzip, deflate.) IIS then determines whether the request is for a static file or for dynamic content.

If the content of the file is static, IIS checks whether the file has previously been requested and is already stored in a compressed format in the temporary compression directory. If a compressed version of the requested file is not found, IIS sends an uncompressed version of the requested file to the client browser while a background thread compresses the requested file. The newly compressed file is then stored in the compression directory, and subsequent requests for that file are serviced directly from the compression directory. In other words, an uncompressed version of the file is returned to the client unless a compressed version of the file already exists in the compression directory.

If the file contains dynamic content, IIS compresses the response as it is generated and sends the compressed response to the browser. No copy of the file is cached by the Web server.

Determining Whether HTTP Compression Will Improve Performance

If your server generates a large volume of dynamic content, consider whether the additional processing cost of HTTP compression is one that you can reasonably afford. If the % Processor Time counter is already 80 percent or higher, enabling HTTP compression is not recommended. To evaluate how much of your processor is typically being used, follow these steps:

1. Establish a baseline for your processor usage by using System Monitor to log the following counters over several days. If you use Performance Logs and Alerts, you can log the data to a database and then query the data, examining the results in detail.

• Processor\% Processor Time. This counter has a total instance and a separate instance for each processor in the system. If your server has more than one processor, you need to watch the individual processors as well as the total to discover any imbalance in the workload.
• Network Interface\Bytes Sent/sec. Counters for the Network Interface performance object display the rate at which bytes are transmitted over a TCP/IP connection by monitoring the counters on the network adapter. For information about additional counters to monitor for this object, see Table 6.8.

2. Enable compression, and continue to log the values for these counters for an extended period — preferably for several days — so you have a good basis for comparison. Collect a broad sample to determine how compression affects various aspects of performance. Conduct the following tests:

• Enable static compression only, dynamic compressions only, and both.
• Change the list of files that you use for compression testing for both static and dynamic content.
• Vary the compression level. Try this on all content types.

3. Compare the data from monitoring with and without compression, and with different types of compression, different compression levels, and different files.

Further reading:

Enabling HTTP Compression

Customizing the File Types IIS Compresses

Using HTTP Compression for Faster Downloads

Something wrong with the code? Correct it at the Virtual Earth WIKI

IIS compression