Cloudflare pages is better overall because it’s trivially easy to integrate with DNS for your custom domain/cloudflare workers, and handles staged changes better IMO. You can point it at a GitHub repo so unless you have a complex build it’s easy to setup.
Unfortunately IME it’s not a super well-polished product though (I can’t for the life of me get their CLI “wrangler” to login to a headless machine, and their HTTP APIs are not documented well enough to use for non-git file sources, so I can’t get it to work in my not-so-special dev environment setup). So it’s only better if you can get it to work, although that’s something you’ll probably figure out in the first 5-10m of using it.
But cloudflare has a growing monopoly on internet traffic that is worse for the internet than privacy busting laws that are passed. If you are a technologist worried about the distributed nature of the web, you should avoid it.
GitHub Pages is pretty bad for static content with its universal
Cache-Control: max-age=600
that can’t be changed. Your assets should have much longer expiry and hopefully be immutable. Just get a server, it’s cheap and you can do proper cache control and you’re not beholden to your Microsoft overlord.
With long expiry/immutable assets, only the HTML needs to be refetched from the server on refreshes or subsequent visits, instead of everything after merely ten minutes. On slow and/or high latency networks the difference can be huge. And you don’t even need to intentionally refresh — mobile browsers have been evicting background tabs since the dawn of time, and Chrome brought this behavior to desktop a while ago to save RAM (on by default).
By refetch I mean re-requested, which can return 304 responses. You still have to do a roundtrip for each resource in that case, and many websites (including static ones) have this waterfall of requests where html includes scripts and scripts include other scripts, especially now that some geniuses are pushing adoption of native esm imports instead of bundling. The roundtrips add up, and good luck if your link is unreliable in addition to being high latency. Compare that to proper caching where a refresh doesn’t request anything except maybe the html. I have experienced the web on such a link and it’s a shitshow.
Ok. I don't think this is a big deal for the vast majority of blogs, like mine, that are hosted on GH pages. It's just HTML and some photos that are unique per post. But I also don't see why GH would put the number so low.
Because they have this one max-time for everything, from things that should be refetched frequently (html, unversioned scripts and stylesheets, etc.) to things that should be immutable (versioned scripts and stylesheets, images, etc.). They don’t understand your website. You do, and you can set exactly the right headers for the best user experience. Btw you can set the right headers with Netlify and Vercel as well.
I'm not confident a "cheap server" (like a $5/mo DO droplet) would be able to withstand being on the front page of HN, but I am pretty confident a GH pages page could withstand being on the front page of HN.
I had a blog article of mine on the HN front page a few years ago and the nginx serving static pages from an ultra cheap VPS didn't even break a sweat.
Or cloudflare pages. As far as I can tell static content is served at no cost and dynamic requests have very generous free limits (something like 100k requests/day)
i love gp. this one almost didn't fit on it because I wanted to serve a small db file to the client rather pay for remote. Luckily I was able to keep it under their pretty generous file limit.
The main downside of GitHub pages is that they don't support running your own Jekyll plugins from _plugins; sometimes it's just a lot easier to write a bit of Ruby code. That said, you can just generate stuff locally and push the result, but that's the main reason I've been using Netlify.
You mean run Jekyll and deploy "manually"? That should work, yeah; didn't think of that actually. But the standard "GitHub Pages" deploy won't work with custom Ruby.
Unfortunately IME it’s not a super well-polished product though (I can’t for the life of me get their CLI “wrangler” to login to a headless machine, and their HTTP APIs are not documented well enough to use for non-git file sources, so I can’t get it to work in my not-so-special dev environment setup). So it’s only better if you can get it to work, although that’s something you’ll probably figure out in the first 5-10m of using it.