CDC found one virus from a cow with a marker known to be associated with reduced susceptibility to the neuraminidase inhibitors (a change at NA-T438I). This change has been seen rarely in the past in H5N1 viruses isolated from wild birds and poultry.
Us sitting here with our fiber internet and recent model phones have it pretty good. But the “i” in iPhone stands for “inequality”. Most people in the world still have pretty bad internet and old/slow phones. For a platform to be widely adopted and to serve the needs of those who often miss out, it needs to be frugal in network and cpu usage.
Lemmy
Kbin
PieFed
Home page
4.5 MB
1.65 MB
700 KB – 930 KB
Viewing a post
360 KB
826 KB (varies)
29 KB
Home pages
Due to Lemmy’s javascript-heavy software architecture, visiting a Lemmy home page involves downloading . And this only gets you 20 posts! Also community thumbnails, even if displayed as a 22px by 22px icon are served directly from their home instances, unresized, which can often be multiple megabytes in size. The home page of lemmy.nz is currently weighing over 9 MB.
Kbin’s home page comes in at a respectable 1.65 MB due to relying less on JavaScript. However it is let down by not using loading=”lazy” on images so they all need to be loaded immediately and by generating post thumbnails that are twice as big as they need to be.
When viewing a post, we can assume various assets (CSS, JS and some images) are cached due to loading the home page first.
The picture looks similar when viewing a post, which is a bit surprising. One of the usual benefits of the JS-heavy SPA architecture used by Lemmy is that once all the ‘app’ is loaded into the browser, subsequent pages only involve a small API call. However, going to a page in Lemmy involves two API calls (one for the page and one for the comments) both of which return quite a bit of data. If you look at the ‘get the comments on this post’ JSON response you can see the developers have fallen into the classic SPA pitfall of “over-fetching“. They’re retrieving a whole haystack from the backend and then using JavaScript to find the needle they want, which involves transferring the haystack over the internet. Ideally the backend would find the needle and just send that to the frontend.
Kbin sends more data than it needs to when viewing a post, again because of not using loading=”lazy” which causes every profile picture of the commenters to be loaded at once. Making this simple fix would bring the weight down, from ~800 KB to around 50 KB.
PieFed only sends 10 KB – 30 KB to show a post, but it varies depending on the number and length of comments. This could be reduced even more by minifying the HTML response but with PieFed under active development I prefer the source to be as readable as possible to aid in debugging.
This is no accident. It is the result of choices made very early on in the development process, well before any code was written. These choices were made based on certain priorities and values which will continue to shape PieFed in the future as it grows. In a world where digital access remains unequal, prioritizing accessible and fast-loading websites isn’t just about technology; it’s a step towards a more inclusive and equitable society.
I'm getting #tired of #people responding to my "here's the #situation here today, and how the #engineering works out for this #problem" with #hopes and #dreams about how they wish the world was, or #anecdotes about how that problem doesn't exist where they are (which is utterly unlike here) so it doesn't matter.