Using GitHub Pages as a CDN ~ 2015-01-21

I recently began playing with Cesium, a JavaScript-based open source Earth visualization engine. My use case is the Great North American Eclipse in August of 2017, the first total solar eclipse to track across the continental United States in many decades. Using Cesium as a mapping engine with NASA data of the eclipse track overlaid I can explore wilderness areas all along the hundred-kilometer-wide track that stretches from Washington State to South Carolina, in hopes of finding an ideal camping destination for August 21, 2017.

Since I couldn't be the only person who wants to camping under the eclipse but doesn't know where it made sense to publish the app online for general use. That led to eclipsetracks.org, a deployment of my functional (but still bare-bones) Cesium application. I deployed it to my Dreamhost VPS which also hosts some of my other projects.

This revealed a problem: Cesium has a big footprint. A quick check in the network tab in developer tools shows over 4MB of data, mostly CSS, JS, and JSON, being served from my puny little hosted server. When the app itself (the stuff I developed separate from Cesium) weighs in under 100KB it was clear that I had signed up for a massive overhead on every new visit that will only change to track major updates from Cesium upstream. In other words: I needed a CDN!

I turned to GitHub Pages to stand something up quickly. Intended as a means of hosting an entire repository as a website it was a nautral fit to get just the assets I need served from a reliable host. With the repository already hosted on GitHub all I had to do was create a branch named gh-pages upstream and, magically, any file in the repository was suddenly accessible at frencil.github.io/eclipsetracks with the same directory structure.

Unfortunately, though, the specific assets I needed to include weren't there. I installed Cesium as a subtree in the eclipsetracks repository, which essentially squashed the whole thing to a single commit that looks sort of like a mini-repository in a subdirectory within eclipsetracks. A working Cesium takes a build process, and of course completed builds are not a part of the source code. To get my CDN working I needed to commit the build to the repository and push it upstream, and that just sounds dirty.

Since GitHub Pages require that gh-pages branch, though, I could push the build to that branch instead of to master. Master would stay clean and the ickiness of pushing a build into the repo is relegated to a single branch that will only see pulls from master in the future, no development (zero risk of conflicts down the line).

With a manageable solution in place I nuked the Build directory from the .gitignore of the subtree and did the add/commit/push trio to start it serving from GitHub. Changing a couple paths in the eclipsetracks index to point to them and I should see a noticeable drop in data served from eclipsetracks.org. Sure enough: only a few KB per request.

As an added (but not very surprising) bonus, GitHub serves content faster than my little virtual private server. Initial page load times over 10 seconds dropped to the 6-7 second range. This is still a long time for a page load, and given the scale and complexity of Cesium that's not like to get orders of magnitude better very quickly, so it might be wise to spend some time building a loading screen of some kind.

Either way, I can now actively try to scale up traffic on eclipsetracks without worrying about a huge bill from DreamHost.