HTML and CSS Reference
In-Depth Information
Server Compression
The transfer time of a file is longer the larger the file, given a fixed bandwidth, so anything that can be done to reduce
the file size that doesn't modify the data within the asset can be a benefit. The previous section discussed compression
techniques specific to the type of data, but there is also the option of generalized compression algorithms. The
majority of browsers support receiving content gzip compressed, such as HTML, CSS, and JavaScript, so compressing
large text-based data, such as JSON objects, in the same way is a good idea.
There are many choices of web server technology available to use for hosting, such as Apache, IIS, and nginx.
Most servers support enabling gzip as a configuration option and usually allow you to specify which file types to apply
it to when a request comes in with the header
Accept-Encoding: gzip
. If a server has it turned on, it should serve
the asset gzipped with the header
Content-Encoding: gzip
. There is usually an associated CPU cost of encoding
and decoding the gzip on server and client side, but this assumes that the cost is less than the transfer cost of a larger
file. Server-side compression costs can usually be eliminated if the response is cached with the gzipped file. Also,
not all gzip compression utilities are considered equal. At Turbulenz, we have found that 7-Zip provides very good
gzip compression, which can be done offline before uploading the assets to the server. In this case, the server should
be configured to serve up the pre-compressed version of the file when gzip is requested. It is worth trying different
compression tools to find which one works best for you. For more information about enabling HTTP compression, see
Gzip compression is considered essential for uncompressed text formats, but for compressed formats such
as PNG it can result in files that are larger than the original compressed file. However, some types of compressed
data do benefit from additional gzip compression, such as DXT texture data. The preferred approach should be to
compress the file offline and compare with and without compression. If the resulting file sizes are similar, then the
added decompression overhead may make loading times slower, and it is probably not worth compressing. If the
compressed file size is much smaller, it might be worth considering. If you have limited hosting space, it is worth
doing a few tests before choosing which version to upload and serve.
Geolocating Assets
The latency of a request (the time it takes the server to receive, process, and respond) has an impact on how quickly
the game will load, regardless of whether the asset is actually transferred or not. Assuming a player is accessing the
game for the first time and can't take advantage of any of the client-side caching techniques previously described,
what can be done to reduce this latency? Since the latency is related to how far the client is away from the server, the
logical solution is to reduce the distance from the player to the host server. As an example, assume that the latency
to the server is 100ms (not including transfer time) and assume your game needs to transfer 100 assets. Worst case,
that's 10000ms (10 seconds) to query the host server to even find out about each asset (assuming a single server with a
single sequential request). In reality, browsers can make more than one request at a time to a given server, but there is
a limit to how many requests can be made. If, however, the base latency can be reduced, then savings can be made for
every asset request. If the player's bandwidth available to transfer a given asset is the same for two different servers,
then the performance benefit will be with the one with lower latency. Having host servers in multiple locations
around the world helps reduce the start time for all your players. It's easy to forget this if you only test run the game
from a single location.
Using a Content Distribution Network
Providing geolocated assets in multiple locations around the world would require you to run multiple servers
and distribute assets among those locations. Luckily, CDNs exist to provide this type of service. The infrastructure
provided by companies running these networks can serve internet content up to millions of users with more hosting
servers than would be feasible for an individual games company to provide. Pricing, performance, and interfaces vary
depending on the provider, so it is worth investigating before making a decision.
