💾 Archived View for warmedal.se › ~bjorn › posts › the-size-of-gemini.gmi captured on 2023-12-28 at 15:32:55. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-05-25)
-=-=-=-=-=-=-
This might be a somewhat misleading title...
Anyways! I've been thinking about writing this for some time; and today is December 2nd. As good a time as any! I spent some time yesterday doing some measurements in order to write this post. There was *a lot* of difficulty involved in that, so there will be some handwaved assumptions at play here. Bear with me.
The point of this whole exercise is to have some info ready when we discuss differences between the web and geminispace in terms of bandwidth usage, overhead, and environmental impact.
Making a fair comparison of a webpage and a gemini capsule is really hard. What is reasonable to compare? There's no such thing as an "average" webpage, and I guess that's to some extent true of capsules too. I decided to not dwell on this too much. You're reading a simple gemlog right now, published by a single individual. I figure a fair comparison is a simple blog, published by a single individual and with roughly the same human-parseable information mass -- i.e. actual text. I entered "wordpress.com" into duckduckgo and picked a result that looked like a simple blog post. For comparison I used my second post about POSTing in gemini, as that looked like it had roughly the same amount of text.
Wow... this was complicated, especially since I wanted to capture TLS and TCP overhead, and have an average and... yeah, suffice to say that I fiddled a lot with netstat and wget only to find that html and http are hopelessly weird. And the overhead would differ a whole lot depending on which version of http was used, too. I ended up just entering the blog post URL into https://tools.pingdom.com and checking the weight of the page and the number of requests made there.
For the gemlog post I actually did do "netstat -s; <fetched the site ten times>; netstat -s" and compared the number of in/out octets before and after. I'm thinking I must have missed something somehow, because I ran it with and without client certificate in the transmission and it looked the same on both... I believe that summarizing the size of the server cert with the size of the post might get me far enough for the purposes of this post, so that's what I'm gonna go with. There's so much margin of error in the measurements.
The test at pingdom reveals that it takes a total of 48 requests and takes up 1.4MB of data to render the post. This includes a couple of pictures (about 1.0MB, according to the summary), which my gemlog post does not. How much extra bandwidth is involved in TLS transmissions? Not much, but too much.
HTTPS reuses TLS connections, so there's only one handshake and certificate exchange per domain and page load, but the 48 requests made are not all made to the same domain! Typically a web page will fetch images and scripts from CDNs on other domains.
In essence:
Not much to say here:
The certificate at tilde.team is about 1.4KB, and without looking at it in too much detail I'm going to assume that this is roughly true for most certificates; server and client alike. This is an unfair assumption, because:
These differences are not too interesting here, however. We end up in pretty much the same ballpark either way. In the case of HTTP/HTML/JS/CSS the size of the certificate and TLS handshake is too small to be significant. In the case of gemini the numbers are tiny in an absolute sense -- especially compared to the blog post example -- but "pretty big" in a relative sense.
HTTP/HTML/CSS/JS is bloated. No news there. Of course we have to make HTTP more efficient and consider reducing all sorts of overhead, because we need to fit all that crap in! I guarantee that the rebound effect of a faster connection will be that all the more crap is sent, bogging down our CPUs and RAM and making the pages load slower.
An average (for some value of "average") gemini request is about one third certificate and two thirds content. Probably about half of each if a client certificate is used too. But it's also just the one request to load an entire post.
On the web a certificate sent is just a fart in space compared to everything else.
The size difference is relatively huge! The blog post sans images still weighs in at 400KB, compared to the 4.2KB of the gemlog post. That's one hundred times the size. Even if we add (and overestimate) server and client certificates to the gemini request it's still only one 50th the size of the blog post.
If you want to be really, really efficient with your bandwidth usage, consider this:
Remember, however, that content in geminispace is a lot lot lot cheaper in terms of CPU, RAM, and bandwidth than corresponding content is likely to be on the web. Write, my friends, and make apps, unfethered by these tiny numbers. Create and enjoy the fruits of your labour :)
PS. Tomorrow's post will probably be a lot less wordy...
-- CC0 ew0k, 2020-12-02