Live data from Hacker News

Static site hosting hurdles

notes.volution.ro

111–120 of 183 posts

Re: Static site hosting hurdles

#111
post #8
post #3

It felt odd to see a doc this comprehensive on static site hosting with no mention of AWS S3/Cloudfront, given how easy it is to push content to an S3 bucket (either manually or via the CI pipeline of your choosing) and then serve it up either direct-from-S3 or via Cloudfront. But then it turns out that this is actually pushing folks towards some new paradigm of static cached HTTP responses instead of files. It pitch…

>We’ve already standardized the hosting side of static sites by using the file system. Worth noting that the incoming younger generations can't and don't into file systems.[1] Yes, anyone who wants to be a webmaster should do their homework, but that is besides the point. We are probably the last generation who can be ubiquitously assumed to have an understanding of files and folders/directories in a computer. [1]: h…

> Worth noting that the incoming younger generations can't and don't into file systems. [...] We are probably the last generation who can be ubiquitously assumed to have an understanding of files and folders/directories in a computer.

[the author here] The article is not about misunderstanding file-systems.

As I've commented earlier on a different thread, https://news.ycombinator.com/item?id=32733825>, the problem is that when it comes to performance and jumping through the hoops the internet gatekeepers (i.e. the search engines) have set out, just dropping some files somewhere the web-server can pick up isn't enough; there are additional tasks that can't be easily performed with files-on-the-disk approach.

Re: Static site hosting hurdles

#112

Are there any static hosts that provide HTTP logs? I know it’s not perfect, but I want to have some sort of analytics without trackers.

You could just use GoatCounter https://www.goatcounter.com/>; it's simple to deploy it yourself (it's open-source), but it's also free to use it hosted, and it seems to be quite privacy friendly (if one could call a web analytics solution as such).

If you are already using CloudFlare, they have a (free and) simple enough web analytics solution. (They say they are also privacy friendly, but given it's not open-source you can't check.)

As with static hosts that provide HTTP logs, perhaps they are, but certainly they won't be for free, as log shipping (from the edge where most hosted solutions cache things to the aggregator) and then storing those isn't quite that cheap...

Re: Static site hosting hurdles

#113
post #64

Earlier quoted context omitted.

> what's wrong with shared hosting? You answered that yourself: > It costs less than $10/month That’s a lot of dollars for a static website. There are a myriad of free options and there have been for years. Kinda disappointing that they weren’t mentioned. Anyone wanting to deploy a static website knows the big 4, completely free: Netlify, Vercel, CloudFlare Pages, GitHub Pages.

I prefer not to use free services because they're not sustainable, and they usually come with strings attached Remember I've been using this for 13 years, and if it keeps on working the same way, I'll use it for another 13 easily. (I've hosted multiple sites on it over the years) The current page claims it's $3.95 a month if you pay yearly: https://www.dreamhost.com/hosting/shared/ I thought mine was more like $8 but…

This had me wondering when GitHub Pages was actually introduced; earliest sign I can find is a blog post [0] from December 2008, so that's almost 14 years ago.

[0] https://github.blog/2008-12-18-github-pages/

Re: Static site hosting hurdles

#114
post #100

This is less of an article, and more of an advertisement for cloudflare.. No, you don't need a CDN for your lightweight static site. nginx and your home fiber gigabit connection will do _JUST_FINE_ (tm), even when slashdotted or getting on frontpage at HN. Also, just drop the generators and write your html already.. Sure, it's fun to learn a new toy, but in end, any abstraction between your content and the HTML being…

[the author here] Indeed I mention Cloudflare quite a lot, and that is for two reasons:

(A) If you do want to have a performant website (be it static or dynamic) you do need a CDN with edge caching; else the physics with it's insistence on a cap for the light speed will put a minimum theoretical latency of 25ms say between Bucharest and Toronto, which in practical terms translates towards at least 100ms one way, or 300ms just to establish a TCP connection, and around 500 for a complete TLS handshake... And no amount of bandwidth can solve that.

(B) Cloudflare is the only free choice that allows you to use your own domain and that doesn't impose any (published) limits on your usage. If you know of other CDN providers that give you this for free please let me know and I'll add their link to the article.

Re: Static site hosting hurdles

#115
One forgotten hurdle of static site hosting is in-memory caching. At most http-server default setup each request goes down to the filesystem. Mostly your are lucky and your filesystem itself has some kind of caching mechanism, so you won't notice. But if your static site ends up in a "very high requests" situation, you should think about in-memory caching of your static files.

Re: Static site hosting hurdles

#116
post #8

Earlier quoted context omitted.

>We’ve already standardized the hosting side of static sites by using the file system. Worth noting that the incoming younger generations can't and don't into file systems.[1] Yes, anyone who wants to be a webmaster should do their homework, but that is besides the point. We are probably the last generation who can be ubiquitously assumed to have an understanding of files and folders/directories in a computer. [1]: h…

> Worth noting that the incoming younger generations can't and don't into file systems. [...] We are probably the last generation who can be ubiquitously assumed to have an understanding of files and folders/directories in a computer. [the author here] The article is not about misunderstanding file-systems. As I've commented earlier on a different thread, https://news.ycombinator.com/item?id=32733825 >, the problem i…

Not that I'm interested in arguing against your intent, but the second and third paragraphs clearly lay out the article is about the younger generations not knowing what a file system is.

I linked it here because, with regards to "already standardized the hosting side of static sites by using the file system", it means squat if the webmaster-to-be doesn't know what a file system is. There's no preconception of using files to hold and serve data from if you don't know (and possibly don't care) about file systems.

If we're going to be discussing attempts at changing the paradigm, then it stands to reason to understand the environment at large that might be encouraging it. If we're going to be talking about something replacing file systems for data storage, it's pertinent to know first of all that the younger generations give zero bits about files.

Also, SEO is at best a tangent to data storage and serving. Some webmasters might not even care to bother with SEO if they don't care about search engine rankings.

Re: Static site hosting hurdles

#117
post #44

Cloudflare has free hosting for static content. there are some limits, but my sites are tiny.

The limits are actually pretty darn extreme for CF Pages — no bandwidth limits, 20000 files, and 500 deployments per day.

It's mind-boggling for me to read the comment section with people paying (and recommending!) anything above 0$/mo for static page hosting, because most likely GitHub / CF Pages can handle more requests than that and requires zero maintenance.

Re: Static site hosting hurdles

#118

One forgotten hurdle of static site hosting is in-memory caching. At most http-server default setup each request goes down to the filesystem. Mostly your are lucky and your filesystem itself has some kind of caching mechanism, so you won't notice. But if your static site ends up in a "very high requests" situation, you should think about in-memory caching of your static files.

With nginx you should set static files to be on a separate cookieless domain and proxied to a different port with the nginx cache keys set how you want them.

You should be using brotli dialled up to 11 for scripts and stylesheets. This takes ages to do if done on the fly but works great if using an nginx cache.

Images need to be on another cookieless domain with the cache configured to work with accept headers, in that way you can serve webp instead of jpg, again with the wonder cache able to serve jpg to Internet Explorer and curl, with real browsers getting webp from cache.

Nowadays you can use nginx to convert to webp, I use VIPS instead so my thumbnail generator goes from source to webp without an intermediary step with the resized image stored as jpg.

Building an origin server for a CDN is a different task to building a regular server. The focus for cached resources is getting the byte size down, not serving a billion requests at once. The CDN can do that.

After I built my nginx proxy with cache I was happy with what happens with memory and how the Linux strengths are leveraged with no wheels reinvented.

Re: Static site hosting hurdles

#119

Yeah I went with Netlify for my static site because I have zero desire to ever been an IT admin. I do skip the static generator part and go with artisinally hand crafted HTML/CSS/JS instead. It’s radically simpler and ultimately better imho.

I used to use Amazon but something broke somewhere and I haven' fixed it. Netlify was very low effort on my part. However I really like the idea of this approach as it helps feed into owning your own data. So I may have another go using this.

Re: Static site hosting hurdles

#120
post #3

It felt odd to see a doc this comprehensive on static site hosting with no mention of AWS S3/Cloudfront, given how easy it is to push content to an S3 bucket (either manually or via the CI pipeline of your choosing) and then serve it up either direct-from-S3 or via Cloudfront. But then it turns out that this is actually pushing folks towards some new paradigm of static cached HTTP responses instead of files. It pitch…

"HTML on disk" does not cover headers.

But it's true that cloud providers have that solved, and "DIY" bring-your-own-server don't, and the article somehow concludes that bringing your own server with the right configuration is not an option.

Post reply on HN