Live data from Hacker News

How to Build a Low-Tech Website

solar.lowtechmagazine.com

91–100 of 188 posts

Re: How to Build a Low-Tech Website

#91

From clicking around this site, it looks like their image dithering technique has taken away the color quality required to properly view the graphs on this article: https://solar.lowtechmagazine.com/2015/10/the-4g-mobile-inte...

I'm not convinced it saves much in the way of bandwidth, either. If you take this[0] image, it's 43 KB for a 800x533 image. I'd expect a JPEG to be able to do that without too much in the way of artifacts. It does give the page a kind of neat newspapery vibe, though. [0]: https://solar.lowtechmagazine.com/dithers/sps_wide.png

Even if it did save bandwidth, that does not equal significant energy savings. And if it did, there are better ways to save.

For example, looking at their response headers I see the image cache control expires after a day, plus has validation caching. This could be significantly improved. First, get rid of the `etag`, `expires`, and `last-modified` headers and go with expiration caching only. Increase the `max-age` from one day (86400) to one year (31536000). I get the HTML expiring after 24 hours, but images should be more aggressively cached. Validation caching always requires a round trip to the server, plus running validation rules on every single request so it can't save nearly as much bandwith and CPU as simple expiration caching.

Also, if they got rid of the those headers, plus the pointless `server: nginx/1.10.3` they could save over 100b per HTTP response. I counted 19 requests on that article, so it may seem small, but it can add up to a significant amount.

Re: How to Build a Low-Tech Website

#94
post #10

Neat article, but I think we should distinguish basically two things here that the article blurs together: 1) Reducing website bandwidth and computational usage (static sites, small images, reducing extra resource requests). Super common topic that HN talks about all the time. 2) Reducing the electricity bill for the server and powering it with renewable resources. This part is quite neat, I think, but for a single b…

The odd thing about this to me is that I feel just throwing those few MB of static files on a CDN would actually be more energy efficient. There is a great deal of energy needed to create and distribute a raspberry pi, and there is basically no energy needed to add a few files to servers that are already up and running constantly.

Re: How to Build a Low-Tech Website

#97
post #58

It's a good start, but the CSS is obnoxious and definitely not low-tech, and the image dithering is a bad compromise between having real images and simply not having images at all. In short, it's an attempt at a low-tech website made by people who've never seen a real low-tech website, and probably wouldn't know Lynx if they saw it in use.

Doesn't this seem a bit uncharitable a characterization? What's an example of a "real low-tech website" that does better than the work presented here? Are you browsing hackernews using lynx or surfraw?

https://yarchive.net/

That's a low-tech website. Absolutely nothing but content.

Re: How to Build a Low-Tech Website

#98
post #40

Wonder if they've considered a gravity battery? As an additional benefit it'd let someone local "recharge" the battery manually rather than being 100% tied to the Sun.

I imagine huge weights hanging off the balcony of a Barcelona apartment :)

We can hire a British from Salou for that.

Re: How to Build a Low-Tech Website

#99
post #37

Earlier quoted context omitted.

> The dithering on images is actually kinda nice. Less visual over-stimulation. Yes, but does it also consume less power, formatting the images this way?

Sure, as it reduces overall filesize. They could have achieved similar efficiency by compressing full-color images though.

Or they can do away with some of the useless images and save a lot more bytes.

Re: How to Build a Low-Tech Website

#100
post #81

I am going to guess they are getting a massive surge of traffic about now and yet the site still renders in a fraction of the time it takes most "modern" web apps or even just static content sites - this is how it should be.

Honestly, I'm not even sure what modern website are doing when they generate pages. I've had highly dynamic PHP/MySQL websites running on crap hardware, and it was trivial to attain .03 second page generation time. Didn't even need fancy caching, just some common-sense SQL optimizations.
Post reply on HN