Community.frame.work gets stuck with slow internet connections

General Topics
1

Hi, everyone!

This message is a suggestion for improvement for Framework.

The community.frame.work website fails to completely load on slow internet connections. What is slow? Here are some examples:

  1. I’m throttled down to 1Mbps by my 5G cellular data provider OR the local coffee shop/restaurant. Or, I am deprioritized by my 5G cellular data provider when in a highly-congested area.

  2. I’ve got a large download going on in parallel, usually an ISO or some important software, and the bandwidth available to the web browser is below 1Mbps.

  3. Something’s wrong with my Wifi driver or card and its performance is either slow or (usually) very flaky.

Anyway, what appears to be happening is that the software that community.frame.work is built on makes a bunch of API calls on page load, and several of these time out, causing the whole page to fail to render.

Everything works fine once I get onto a faster internet connection with the exact same device, whether it be my smartphone or laptop or LINUX tablet or Windows 11 desktop.

Here’s why I’m making this suggestion. Usually, the exact moment I need to get onto community.frame.work is when I’m trying to fix some big problem with one of my devices. For example, last night, I installed and then updated CachyOS on my Framework 13. It pulled down an update that caused Plymouth to lock up during the boot sequence. I immediately grabbed my LINUX tablet and started researching. After much research on the CachyOS forums I found that I needed the latest BIOS with an AMD-specific fix in it. I then tried to access the main frame.work and community.frame.work sites, but they would not load while I was throttled. So I couldn’t even read those sites to find out if there is anyone else having this problem with Plymouth on a FW computer or whether a newer version of the BIOS was available, etc.

What I ended up having to do in the end (after disabling Plymouth) was get to a CUI login (because SDDM core dumped), then use fwupdmgr to check for available updates. It did manage to see that BIOS v. 3.05 was available (I had 3.03) and pull it down. The BIOS update fixed the issue, but to me it was a gamble, because I was not able to research its changes before downloading it. I was flying blind and gave it try because I had nothing else to lose since my FW13 was unable to get a GUI going.

Another example: I might be having a problem with a particular distro of LINUX on my FW13, I’m downloading a new distro’s ISO, and I’m trying to research the distro on community.frame.work and it is inaccessible because the ISO download is consuming most of my bandwidth.

I would expect that other users would benefit from having community.frame.work be more tolerant of lower-speed internet connections, such as rural dwellers with slow connections, people stuck on DSL due to their HOA (I know someone who suffers from this), people stuck on DSL due to being in an unincorporated part of a major city (I also know someone who suffers from this), vanlyfers/RVers, sailors, etc.

My suggestion is to increase the timeouts for the many API calls OR make the page load more tolerant of failures to get anything back from a specific API call. Another way around this is to offer a read-only plain-text version of the website so that people can read the posts already there, maybe learn about a fix for their problem, and download drivers/BIOS.

Thank you for your consideration!