HTML and CSS Reference
In-Depth Information
<Directory /path/to/asset/files>
ExpiresDefault "access plus 10 years"
</Director>
This directive requires that you have the
mod_expires
Apache module installed.
You need to ensure that you can update your game assets if you make changes to your game, however. One
way to ensure that you are always serving up-to-date assets when caching is turned on is to append the last mod-
ified time in seconds (known as the
mtime
) of the file to the URL, as follows:
<script src='js/game.js?1326075236'></script>
If your HTML file is served dynamically, this is easy to do. If it's served via a static file, you can hard code
a modified date using a build script.
For assets loaded dynamically, use a similar method. In general, keeping a global version number that gets
automatically appended to any loaded assets is the simplest method for small games.
Lastly, make sure you turn caching off during development. There is nothing more infuriating than trying to
hunt down a bug that you have already fixed but the browser is serving an old version of your code.
Making sure that your assets serve the right cache headers is only half the battle. The second half is to ensure
that assets that benefit from compression are served gzipped to browsers that support it (which, at this time, is
every browser you should be concerned about playing an HTML5 game on, even including the venerable IE6).
If you use Apache, this is handled by the
mod_deflate
module. Ensure
mod_deflate
is enabled, and
then add the following to your virtual host or to an .htaccess file:
AddOutputFilterByType DEFLATE application/javascript application/
x-javascript text/html text/plain text/xml text/css
Your JavaScript, HTML, CSS, plain text, and XML files can now be served compressed over the wire.
Serving from a CDN
To really make your assets fly, your best bet is to actually forgo serving them yourself and serve them directly
from a content delivery network, also known as a
CDN
. CDNs are designed to serve files fast from edge-loc-
ations spread throughout the country and the globe. Serving files from a nearby location means that requests
will be answered faster (there's less round-trip time for packets getting passed back and forth,) but the biggest
advantage is usually simply that CDNs are optimized for serving files quickly, so they have the infrastructure
and fat Internet pipes to do so.
Amazon.com
's Cloudfront is one of the most popular CDNs and is relatively easy to get started with and
inexpensive until you rack up significant bandwidth. Cloudfront works with
Amazon.com
's S3, a cloud stor-
age service. You need to configure Cloudfront to pull from a specific S3 bucket, but from then on, any file you
upload to S3 will be available via Cloudfront.
To sign up for S3 and Cloudfront, you need to sign up for an account at
http://aws.amazon.com/
.
From there
you can launch the AWS Management console. From the console, go to the S3 tab (it may prompt you to sign up
for the service first) and click Create Bucket. Enter a unique bucket name. The bucket name needs to be unique
across all S3 buckets, so it may take a little bit of creativity to come up with a name.
Next you need to click the Cloudfront tab and create a new distribution. Click the Create Distribution button,
and select the bucket you just created. You can press Continue through the remaining screens until your distri-
bution is ready to go. After you create the distribution, it can take up to five minutes to set up, but you can see
