GitHub as CDN?

4 min. read

Caution! This article is 8 years old. It may be obsolete or show old techniques. It may also still be relevant, and you may find it useful! So it has been marked as deprecated, just in case.

I have all my projects' sites hosted at GitHub pages, but I also have some sites outside GitHub, and I use a lot of files from GitHub as well, like normalize.css, prism.js (a syntax highlighter by Lea Verou), etc. So at some point I thought:

Why not serve those files directly from their GitHub repos?

I could just link to the "raw" version of them. My hosting would breath, both in bandwidth and disk space, the file would be updated automatically and I would always serve the last version. What could possibly go wrong?

This turned out to be A Bad Idea, for at least these reasons:

  • What if the author decides to delete the file?
  • What if the author decides to rename the file?
  • What if the author rearranges the folder structure?
  • What if GitHub wasn't created to be a file server, but, you know, a remote git repositories server? :-P

The last one is really the clue. GitHub doesn't serve its "raw" files with a far-future expires header. Also, Another problem is that GitHub doesn't serve "raw" files with a content-type header that matches the file's actual MIME type. In IE9 (and perhaps other browsers/proxies/firewalls/etc), JavaScript files that aren't served with the correct content-type are blocked by default.

But there's RawGit!

Oh, yeah, there is RawGit. It serves raw files directly from GitHub with proper Content-Type headers. Problem solved! Let's link to RawGit as if there was no tomorrow!

Well, not so fast.

Requests to are routed through MaxCDN's content delivery network, and are cached permanently the first time they're loaded. This results in the best performance and reduces load on RawGit and on GitHub, but it means that reloading won't fetch new changes from GitHub.

(From the FAQ:

So, instead of having an updated version, you will have to stick to a particular version of the file, that you can access using a URL like or instead of

Will I use this?

I don't know. It's true that I'll benefit from the caching and all that... BUT.

Most of the time I am concatenating and compressing my several css and js files. There is some discussion going on about this, since you should find a compromise between benefiting from caching some files but having more http requests, versus serving a huge uncached css or js file but making a single http request. I do serve files like prism.js which have to be served in a separate http request anyway, because they don't work if you use theĀ async attribute on them. Those would be candidates for RawGit.

So... I have to think about it!