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.
Pros
-
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.
Cons
-
Need to use a subdomain - You basically need to use a subdomain, such as
www.kevinsweet.com
instead ofkevinsweet.com
. 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 towww.kevinsweet.com
. -
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
www.kevinsweet.com/my-post.html
. Personally, I wouldn’t be caught dead using a .html extension. Your other option is a trailing slash, likewww.kevinsweet.com/my-post/
. 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 iswww.kevinsweet.com/about
. 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 servingstyle.css
, you would serve something likestyle-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
https://dynamicdyno.github.io
, but I can’t usehttps://kevinsweet.com
. 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.