you could easy have a web server with thousands of visitors running on a rasbery pi. i would say a week end project to set it up or one hour if you already are familiar with web servers.
I'm curious about this. If you have a purely static site, what would be the major bottleneck for a front-page-reaching site hosted on a raspberry pi? I'm thinking things like compression would eat up a lot of its CPU, but you seem to know more about this than me.
A solid 3,000-word article with enough CSS to make the page look nice will fit comfortably in 20-30KB gzipped. A Raspberry Pi could handle on the order of tens of requests per second (tens of thousands per hour).
A fluffy 500-word Medium-style article with 1-2MB of JavaScript serving no apparent purpose and 5-10MB of animated GIFs would be another story.
A realistic static site will have multiple css, a logo, potential images in the headers/footers/sides, links to the other top read articles with icons, pictures/schemas/drawing/photos in the content.
That sets any stupid article at a 500kB bar.
I have no doubt that a HN engineer can publish a single .txt file and force gzip-9 compression, however that's not an acceptable blog by any standard.
Last I checked, compression wasn't supported by all browsers all the time. It needs to be done dynamically depending on the settings the browser allows.
nginx or varnish can do that (with more or less correct rules).
In practise, I usually disable compression everywhere and let the CDN handles it.
The CDN is configured to compress on the fly and I am very confident that CloudFlare/Akamai are doing that much better than a broken snippet of nginx settings from stack overflow.
As one would expect, S3 can certainly support various browsers. It ends up being just like content negotiation, in that you have multiple representations that could be served from a particular resource, depending on what headers are sent.
I'm not sure if it's still like that, since I'm not using S3 for that right now.
I'm not an expert by any means, but I think you can manually gzip your content and add rewrite rules to Apache (don't know about other servers) to use the .gz versions. I think this is the only way for compressed content to be cached by Apache, but I'd love to learn if I'm wrong here.
You seriously overestimate the capabilities of a raspberry and undestimate the traffic you get.