Back when I had no clue what I was doing with this site, and it was nothing more than a single HTML file with some jQuery that I absolutely did not need, I was hosting it for free on GitHub Pages. It made sense at the time—my site was simple, I didn't have to pay anything, and I already had a free domain right at my fingertips. GitHub Pages is one of the easiest ways to create a personal website, publish documentation, or share small projects.
But with time, I realized that GitHub Pages also has many limitations and doesn't scale well with frameworks and third-party plugins, particularly for static site generators like Jekyll. Now, my site is hosted on Netlify under a custom domain, and I couldn't be happier.
Table of Contents
Below are just of the reasons why I prefer to use Netlify over GitHub Pages. I'll be updating this post occasionally as I continue using Netlify and learning more about its features.
My favorite thing about Netlify is its ecosystem of build plugins, which allow you to extend Netlify's build pipeline to run additional checks on your site before it deploys to production. If any build plugin throws an error, your build will fail with detailed logs clarifying what went wrong.
Netlify plugins are open source and free to use. Here are some that you might find useful:
netlify-plugin-checklinks: flags broken internal and external links.
netlify-plugin-a11y: runs accessibility-related checks on your site.
netlify-plugin-inline-critical-css: inlines critical CSS.
Netlify also offers framework-agnostic features like:
- Free contact forms that work with static sites and have spam protection.
- Netlify Functions, a popular option for serverless sites and apps.
- Split A/B testing, where Netlify serves multiple branches to users at random.
If you want to test production changes on GitHub Pages, you need to push up a branch and wait for the build to finish on prod. By contrast, Netlify allows you to run dev and production builds locally using the Netlify CLI, with secure authentication. This allows you to simulate a full Netlify build locally, including with any build plugins that you've installed.
When you connect a GitHub repo to Netlify, you can take full advantage of its CI/CD pipeline for a better developer experience. For example, if anyone opens a pull request in your repo, this will automatically trigger a Netlify build and generate a unique Deploy Preview URL when the build finishes. This deploy preview doesn't get indexed, and it can be shared with anyone within or outside your team.
Deploy previews are a great way to verify that merging a pull request won't introduce unintended side effects, allowing other devs on your team to test a feature live rather than having to build your branch locally. If you're a freelancer, this is especially useful because it means that you can show deploy previews to clients and solicit their feedback before your changes ever go live.
With Netlify, you have greater control over the entire deployment process. Your dashboard provides a clear view of your deploy history and even allows you to manually revert your site to a prior state with its one-click rollback. You can also stop auto-publishing new versions of your site, access all of your deploy previews, and more.
GitHub Pages doesn't give you this kind of fine-grained control over deployments. It's actually fairly limited—you can only deploy to two branches, one of which is
master by default. So if you want to revert your production build to a prior state, you'll need to do this at the repo level by resetting to a previous commit with git and deploying a different branch. There are also no deploy previews, so whatever you publish will go live as soon as it builds.
Netlify builds my site in just 1–2 minutes, on average:
Back when I was hosting my site on GitHub Pages, things were much slower, and I'd sometimes have to do a hard refresh to see any updates on prod. GitHub's own documentation notes that you may have to wait up to 20 minutes to see your changes go live:
It can take up to 20 minutes for changes to your site to publish after you push the changes to GitHub.
Unfortunately, GitHub Pages also caps you at only 10 builds per hour. So if you're frequently pushing to your deployment branch (which you probably shouldn't be doing anyway), you may run into trouble:
If your site exceeds these usage quotas, we may not be able to serve your site, or you may receive a polite email from GitHub Support or GitHub Premium Support suggesting strategies for reducing your site's impact on our servers, including putting a third-party content distribution network (CDN) in front of your site, making use of other GitHub features such as releases, or moving to a different hosting service that might better fit your needs.
Netlify has a much more generous soft cap of 3 builds per minute. You also get 300 build minutes per month and 100 GB data usage with its free tier, which is more than enough for most needs.
Build minutes are just Netlify's currency for a billing cycle. If you're a free user, this means that your builds can't exceed 300 minutes total for one month. Next month, your usage resets to 0. You don't have to pay anything as long as your usage doesn't exceed this limit.
Netlify lets you configure your builds using either the Netlify UI or a
netlify.toml configuration file at the root of your repo. This file houses your build commands, the directory to publish, redirect rules, response headers, plugins to use and the options they accept, post-processing steps, and other settings. The customization options for GitHub Pages are limited to whatever is offered under the repo Settings page.
If you're a free GitHub user, then GitHub Pages will only be able to build your public repos. You can get it to also build private repos, but you'll have to purchase one of the Pro plans, the least expensive of which is GitHub Teams at $4/month. Netlify, on the other hand, can build both public and private repos for free. Slap on a custom .com domain from Google Domains for just $12/year, and you're all set.
This may not matter if you don't intend to publish any private repos, but some people do prefer to keep their source code private, so it's a nice added bonus of using Netlify. If you ever want to make your source code private, it won't affect Netlify so long as you've correctly linked your Netlify access token to GitHub.
This one's a big deal if you value your site's SEO.
If one of your URLs changes, Google will need to know that the old and new version share the same content and that your search results listing should be updated. The proper way to do this is with a 301 redirect, but GitHub Pages doesn't let you configure redirects for your site's URLs. You'll have to handle this in your source code, like using the jekyll-redirect-from plugin for Jekyll, gatsby-redirect-from for Gatsby, and so on.
On the other hand, redirects in Netlify are super easy to set up. All you need to do is create a plaintext
_redirects file that maps old URLs to new ones, separating the two with a tab:
/old-url/ /new-url/ /another-old-url /another-new-url
Make sure this file is included in your site's build output, and Netlify will handle the rest for you.
If you run a blog on a GitHub Pages domain and it gets decent traffic, you'll want to be careful about how you go about switching hosting providers since
.github.io domains are reserved by GitHub, and you can't carry these over to a different hosting provider (like Netlify).
I recommend that you keep your old GitHub Pages repository around temporarily, separate from your new site. This allows you to set up custom 301 redirects (e.g., using one of the plugins mentioned above) that point from your old GitHub Pages site to your new site so that your search engine rankings don't tank.
You can also use the Change of Address Tool right there in Google Search Console to migrate your old site's traffic to your new one, once you've set up 301 redirects:
Keep an eye on your Google Search Console over the next few months following your migration. Once things stabilize, you can make your old repo private or delete it altogether, taking it off of GitHub Pages.
A few months after migrating my site this way, I took down my
.github.io domain. My search engine rankings were stable throughout this migration period thanks to the redirects I had set up.
Okay, so that's obviously a slight exaggeration—all I really did is switch hosting providers!
However, the future looks very promising for Netlify—it recently secured a whopping $53 million in Series C funding. Past investors of the company have included founders from GitHub, Slack, Yelp, and other big names, so people clearly see value in its business.
Having switched from GitHub Pages to Netlify, I feel like I have far more control over my site. The only downside is that if I want to take advantage of more features, their paid plans are pretty expensive. But I don't anticipate this being a problem—the free tier has everything I need, and then some.