dynode is now static

Authored: 04/04/2023 17:35

The latest update to dynode includes a move away from MDwiki, the static site generator I was using from dynode’s inception in 2018 to render its pages via markdown. There are several reasons for this, as follows:

The HTML file required for MDwiki took up almost 61% of the total size of the prior snapshot of the site (/ipfs/QmUgdq7LKx11Y2X3g671LumC4PrKfUGC3WYgRkKy2i9enp), excluding image files and external styling - it is, by any metric, a major source of bloat that needed loading with any page visit
For static content (text files, images and indexes for other documents) it is already preferable to avoid executable logic such as JavaScript unless completely necessary, but MDwiki in general is a mess of nontrivial JS that causes a number of problems and uncertainties with regards to loading over IPFS
The theming it uses created a necessary dependency on 3rd party CSS via BootstrapCDN and Google, and there should be no reason that styling cannot all be self-contained within the IPFS object, other than the fact that the obscurantism of MDwiki’s language makes this a chore to alter

The new markup has been generated with pandoc (more on the process of creating the IPFS object here), and placed into separate static HTML files for each page. This method likewise confers its own benefits:

A wider browser compatibility, particularly for older or more simple (including text-based) browsers
Elimination of all scripts, which also helps with compatibility
The object is now self-contained (so, no multi-thousand-rule BootstrapCDN CSS files), +1 for privacy
The object in general is smaller and lighter on resources
Better opportunity for scraping / indexing and general extensibility with other utilities and services

I was first introduced to MDwiki by a colleague from a mutual project as a convenient means of generating documentation without the complications of building source code trees like with typical documentation generators. When it occurred to me that these pages could be added to IPFS and loaded through public gateways quickly and with ease, the broader implications for online publishing (especially as it pertained to IPFS) became clear, and so I created an infographic explaining a method for creating these sites (alas, I was apparently beaten to it by several months by a Chinese dev), followed by dynode, the proof-of-concept.

Since then the site has served (and will continue to serve) as a sandbox of sorts for my forays into the matter of self-publishing. Attendant to that is a general philosophy (or set of principles) on the matter of publishing that is perhaps best expressed through the form and content of the site itself.

To that end, the latest update was intended to demonstrate advantages mostly concerning the goals of simplicity, minimalism, and efficiency - not simply for their own sake, but for the fact that these things ultimately determine real-world accessibility for users who do not have infinite resources to expend.

For most fibre- or 4G-connected users in developed countries with reasonably-priced and reasonably-performing devices, for example, the end result of the tremendous bloat of typical Web design can be absorbed with relatively few problems. If even minor increases in latency are introduced here however, then every 14kB loaded thus becomes critical. Likewise, resource usage generated by unnecessary features or styles within services catering to thin clients are less easily dealt with by lower-end computers. These problems yet compound for everyone with each additional tab, page, or service one is attempting to load.

With that in mind, the new design attempts to emulate much of the visual elements of the MDwiki theme I was using in simpler ways (e.g. sticky headers), with some minor differences. The background-foreground tones have been inverted for example, to make pages far easier on the eyes. Hyperlinks have also been made a muted green, which, as it happens, was the original colour used during early WWW testing. To complement this, a ::selection selector is used to make the backgrounds for highlights green too.

There are also a couple of hacks and newer elements of CSS I have implemented, usually to achieve certain functionality in lieu of using scripts - for example, a semi-successful attempt to imitate the on-click image expansion of Gazelle for images without links, which, for wider images, don’t quite hold their aspect ratios. This WIP aside, I have retained the Lora font from MDwiki, but am using it in variable font form, to keep the necessary files down to 2 (standard and italic), and to make it simpler to switch between them.

One may understandably submit that these simple inclusions violate the very ideals that were just raised. To this are some pertinent notes: firstly, any worry of incompatibility or deprecation in the case of variable fonts is rather small, with no less than 95% of browsers supporting the feature (merely 1% fewer than the general support for system fonts). The same may be said of the :focus selector, that, along with a tabindex value of -1 for <img> tags without links, I use to achieve image expansion - where support lies at almost 97%.

Most importantly, these additions present nought but embellishment for pages that would otherwise still function equally well. For the vast majority of users with browsers that can support these functions, some extra kilobytes loaded for aesthetics is a worthwhile tradeoff. For text browsers, this is irrelevant anyway, as they probably won’t be loading images or styles, and the sensible, minimal page design will look almost identical regardless (and for that matter, even the raw HTML is more readable than many sites offer today).

Crucially, all of the content will still load and will still work for all users, in spite of their individual set-up. None of the text is being placed behind the barrier of arbitrary and superfluous code execution, no image is prevented from being seen. As what will likely be the most advanced elements of styling I will implement (and the closest to an exception for these ‘static-only’ pages), I consider the use of variable fonts and image expansion a valid trade that will probably not even be felt by the tiny fraction of users who can load images but not years-old styling functions - and the same argument could be made for styling support in general.

To ascertain some kind of measure of speed improvement over MDwiki, I also conducted some tests.

While they may not have passed your average peer reviewer, I did try to maintain something approximating lab conditions when collecting the values plotted below. The process itself went as follows:

Using a single IP, and recording ‘data transferred’ and ‘finish’ metrics with Firefox’s Network Monitor, I conducted three page-loads for each of three selected pages of the previous version of dynode’s IPFS object, ie QmUgdq7LKx11Y2X3g671LumC4PrKfUGC3WYgRkKy2i9enp - the index page, the about page, and the Hegemonic Influence article - on each of three gateways - those of ipfs.io (Protocol Labs’ gateway), cloudflare-ipfs.com (where the HTTP domain for dynode.io was last pointed), and pinata.cloud (where dynode’s files are first hosted prior to being cached elsewhere), then did the same for an object containing the new static revisions, each of them with minor changes to the page content itself.

I calculated mean values for each page load, on each gateway, and used them to produce the charts below:

Bar charts of speed tests conducted on various pages of dynode

Before interpreting, there are a few notes to be made:

I cleared the browser’s cache after each load so they would not interfere with future loads, that each one could be considered a ‘fresh load’. I also loaded each page once before recording it, so as to control the possible variable of time taken for the gateway to fetch the content over the IPFS network (as they would already be cached by the gateway). During fresh loads, gateways can end up with huge variation in load times, sometimes timing out. So I used values I considered to be ‘representative’ of regular loads and left these anomalies out, but sometimes (mostly with ipfs.io), this couldn’t be done.
Using the same IP and browser for each other load, Firefox simply refused to display the MDwiki page when loading through Pinata’s gateway, and they were thus entered as 0. While this then may present an ‘incomplete’ set of data, I think this speaks for how the oddity of MDwiki’s code produces this kind of unpredictability (since the object itself, including other items inside, could technically be loaded).
I cannot be entirely sure that these results could not have been in part determined by the particular connection I was using at the time, and the connectivity of that server to each gateway. However, the results do fit with my experience in loading the site, so the general trend of them is likely replicable.

Now, on to the takeaways.

First, the most evident and expected result is that of the advantages of the static pages. On half of the 6 tests where the pages could be loaded, the static pages loaded more quickly than the MDwiki equivalent, but for the other 3 tests, the MDwiki pages would not display at all. During each of the tests where the static results were better, they were all by extreme margins, which was not the case the other way around.

Second, it is quite clear that the performance of the Protocol Labs gateway leaves much to be desired. 2/3 of the times that MDwiki had won out, it was on the ipfs.io gateway. While cached loads were adequate, it performed poorly on fresh loads. I was intending to move the HTTP domain back to PL, but in light of this, I will be keeping it, for now, on Cloudflare’s (and linking via dweb.link, which also seems to be run by PL).

Also, for all of the static loads, the Pinata and Cloudflare gateways usually downloaded the same amount of data as one another. The PL gateway however, often downloaded an extra 100 kB when compared with the others - most obvious here within the index page, as that is 2/3rds of the entire page. Upon closer inspection, the PL gateway appears to be downloading the full standard Lora font file (209 kB in total), while the others fetch half of that (the non-bolded half?). Not sure how this is done, but interesting nonetheless.

Finally, the arcane JS constructions of MDwiki are unavoidable and even cascade into one being entirely unable to load the object - and it makes me wonder how many times this has happened over the years of people trying to access the site. It serves as a lesson in itself regarding the trading of bloat for convenience.

While I still consider the MDwiki guide to be a fine way of quickly spinning up an avenue for Internet publishing for those without even the requisite HTML knowledge, there are indeed better options when usability and readability for a wide range of users is desired. As always, dynode remains a primary ground for testing such experiments, and ultimately, this is but one redesign of perhaps many in the future.