The Pros & Cons of Using GitHub Pages

As of the time of this writing, this site is being generated by Jekyll and GitHub Pages. There are things I love about the setup and other things that I wish I had more control over.

For reference, there are two distinct ways that you can host on GitHub Pages. The easier way is to let GitHub generate your files for you. The more complicated way is to generate the files locally and commit those to GitHub. The latter offers much more flexibility because if you let GitHub generate your site for you, you can’t use any plugins. This post is mainly concerned with the former method, in other words, letting GitHub generate the files.

I’ll start with the positives.


  • GitHub Pages is FREE! - It’s seriously hard to beat this, and it basically trumps everything else for me.

  • Fast CDN - They use Fastly as their CDN, one of the best around.

  • Built-in CMS - If you’re letting GitHub generate your site for you, you can use GitHub’s built-in editor. Saving the file in the editor is the same as committing a file. As soon as it’s committed, GitHub will redeploy the site in seconds.

  • Automatic gzip & minify - GitHub does a pretty good job of serving assets. Everything is automatically gzipped and minified.


  • Need to use a subdomain - You basically need to use a subdomain, such as instead of This is due to how GitHub implements DDoS mitigation technology. You can leave off the subdomain, but first page load time is incredibly slow. In my tests, it was normal to see four second response times on the initial HTTP request. I was forced to switch to

  • Less control over URLs - I’m picky about my URLs, I’ll admit. The two options you have for how a post URL ends is attaching an extension, such as Personally, I wouldn’t be caught dead using a .html extension. Your other option is a trailing slash, like Personally, I’d love for that slash to be gone, but what can you do. This only affects Jekyll posts, and not regular html pages. For example, the URL for my about page is I wish Jekyll would generate the posts in the same way.

  • Low cache expires - GitHub sets the cache-control: max-age header to 600 seconds, or ten minutes. Normally, you would set this value to a year so that it stays cached, and then use fingerprinting on your assets. Instead of serving style.css, you would serve something like style-62c887ea7cf54e743ecf3ce6c62a4ed6.css. As it stands now, assets are rarely going to be cached on repeat visits.

  • No cookies to change HTML - Sometimes it’s useful to change what HTML you send a visitor, based on a cookie. The Filament Group uses a cookie as a flag for whether or not to inline CSS. This is inherently not possible with a static site.

  • No Grunt / Gulp / Rake / etc. tasks - This is only true if you’re letting GitHub generate the site for you. Still, you lose a whole lot of power and flexibility without any build system.

  • No SSL support - You can use SSL if you don’t care about using a custom domain. I could use, but I can’t use This isn’t a huge deal–my site doesn’t have any forms, but Google just announced that sites using HTTPS will get preferential SEO treatment. Serving sites over a secure connection is a good practice in general.

Penned on August 13, 2014 by Kevin Sweet