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.
How to Build a Low-Tech Website
81–90 of 188 posts
Re: How to Build a Low-Tech Website
#82I think this website is a beautiful piece of engineering: simple, efficient, clear and humane. It solves a pressing human problem with mature, straightforward technologies.
The dithering is obviously not to everyone's tastes, but I like the paper feel and think it's appropriate for a 'low tech' brand. Bravo to the lowtech team.
Re: How to Build a Low-Tech Website
#83I once basically did just that, besides the image dithering. I ran a small blog off a Raspberry Pi, only using Markdown files and something to render them to HTML. I used my own IP address, which I know you're not technically supposed to do but in 15 years I've never had an ISP crack down on me for it, and had a script that would run periodically to update the A record for my domain in Route 53. (since my IP was dyna…
For several years starting in 2010 I ran my personal website off a Pentium III Thinkpad running Plan 9 sitting on the floor behind my desk. I wrote the web server in Go; it was a "hybrid" in that it served mostly static files, but in the blog subdirectory it would render Markdown to HTML.
It worked great! I eventually migrated to a VPS when the hardware started to get too flaky with age (and years of accumulated dust sucked through the fan inlet)
Re: How to Build a Low-Tech Website
#84> The size of the average web page (defined as the average page size of the 500,000 most popular domains) increased from 0.45 megabytes (MB) in 2010 to 1.7 megabytes in June 2018. It's the second place I see such low average size values (I'd say, somewhat reasonable), but I'm having a hard time believing in them. On a typical site, when I hit F12 and proceed to Network tab, I usually see ten times greater values. I f…
I remember from over a decade ago there was an annual contest to make the best web page that would fit into 5KB - yes, 5000 bytes. There were many impressive entries. I'd really hoped it would catch on. Sadly, that lightweight concept is now so forgotten that I can't even find it in a quick search. (perhaps someone else can find a pointer?)
Re: How to Build a Low-Tech Website
#85The idea is great, the software side especially is something I'd like to see more of, and the not-always-available scheme is very commendable as well.
But the end of article stuck out at me.
> we'll be offering print on demand versions of our blog.
How is that consistent with low energy footprint? Will the printers and the cellulose factory run on solar as well?
Re: How to Build a Low-Tech Website
#86Earlier quoted context omitted.
> This makes sense and I don't understand why self-hosted sites are doing it. The logs are there. Analyzing them is all that is needed. 1) Laziness. A third-party JS tracker usually comes with a complete dashboard, full of pretty (and sometimes even useful) graphs. 2) Data. Client-side trackers can spy on users more, giving you more information you can e.g. missapply in an A/B test trying to drive "engagement". RE 1,…
You don't need a thirds party tracker to get fancy graphs. Matomo is free, open source, self-hosted, works on logs, and has fancy graphs. An ELK stack would also work fine. Lazy-loaded 1px images can be used for tracking how far users have read and a/b testing can be done by compiling multiple versions and redirecting users to the version you want them to try.
If I could toot my own horn for a moment, Gravwell (gravwell.io) has a 2GB/day free license which should be plenty to ingest web logs. We've got a GeoIP module to resolve IPs to locations, we can display geographic heatmaps (see https://dev.gravwell.io/docs/#!search/map/map.md), a variety of charts, tables, etc.
Matomo looks really polished and if it provides the features you need, it seems like an obvious choice. If OTOH you're looking at rolling your own with ELK, Gravwell might make sense.
Re: How to Build a Low-Tech Website
#87[deleted]
Re: How to Build a Low-Tech Website
#88Earlier quoted context omitted.
Those are compression techniques, they do not require js, nor a different client and work with the jpeg standard.
To implement the improvements you suggest on this site (which appears to be a static site), the best way would be to have your proposed image compression as part of the static site preprocessor, correct? Just trying to understand how it would be implemented, as this site is an interesting idea but the dithered images would likely not have mass-appeal.
Yes, you'd just run all of the images through jpeg-recompress (from the GitHub repo linked above). They're already doing something like this to dither, so it's just a question of swapping out which command to run.
Incidentally, even where PNG is appropriate (images with crisp edges, such as text and icons) you can frequently get a large size savings by applying zopflipng, which uses an alternative GZIP compression algorithm to get a higher-efficiency compression, at the cost of greater CPU use for encoding.[1]
[1]: https://blog.codinghorror.com/zopfli-optimization-literally-...
Re: How to Build a Low-Tech Website
#89I 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.
[deleted]
Re: How to Build a Low-Tech Website
#90Neat 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…
Is that a comment on the effort to produce a site like this, or the cheapness of energy and bandwidth? The effort required to produce a site like this would be negligible, given that it's almost entirely plain HTML. Dithering the images would take seconds in something like GIMP. The HTML looks to have been produced by a tool, based on the formatting, so they wouldn't need to spend time working with markup.
What about the energy used to design and build the infrastructure? There's a lot more that went into this project than just the static site, which is something the article touches on.
To illustrate, I'm going to invent some numbers:
Let's say that this site on "standard" hardware would use 1kW per day. This means the existing site saves ~950W per day looking at just the hardware energy use.
However, the hardware it's running on had to be produced, let's say that costs 10kW. The solar panels and batteries need power to make, let's; say they cost another 30kW of power.
Additionally, the system needs to be designed and built by a human being. Humans use a lot of energy. Let's say that this took 1 week to design and build. Let's say a human "uses" 50kW of "power" per day (e.g. from food production, etc.). This means it costs an additional 350kW of power to design and build the infrastructure.
Adding up all these made up numbers gives us a total infrastructure cost of 390kW. This means that, in order to "pay back" the difference, the new system has to operate for (390,000 W / 950 W/d =) 410 days.
These numbers are wildly inaccurate and cut a lot of corners, but this should give an idea as to what the grandparent was getting at.
Sidenote: I'm not, personally, trying to make a point about the project itself. Just, in order to fully understand the energy impact you have, you need to take a lot more into account than just "the amount of work performed by the computer".