Errors when the network is super slow

[jdanish]

If I run with chrome set to simulate a slow phone connection I get a blank screen on the load about 1/2 of the time (almost always if I multi-task to a different window while it is loading). Occasionally there is an error displayed, but otherwise we see the attached blank screen. Not sure if this is related to the other issue I reported.

[benloh]

@jdanish A few questions:

1. This looks like it's not standalone mode right?
2. Can you open up the Network panel and see if any file loading has been stalled?
3. Given the sourcemap errors, I'm assuming this is running the net-debug branch? Are you seeing netc-lib being compressed?

#132 did point us at a few issues where asynchronous loads was biting us in the ass. That explains the intermittent nature of the problem. I wouldn't be surprised if there's another issue similar to that. We just need to be able to reproduce it to know where to look.

[benloh]

OK I just hit the page, and it looks like netc-lib is not compressed, so perhaps it's running an earlier commit?

Also, I'm curious if running this with #132 issue fix will help? This looks like a similar issue.

[jdanish]

Which page? I am at http://134.209.73.52/graph/H213FA2020Prokopios/#/

And netc is 1 mb and change (compressed)

[jdanish]

I swear it crashed at least once (and I got that photo) but of course now it is no-longer crashing. But it seems to take as long as a minute to load the graph even after transferring netc, so it is quite possible students are just giving up?

[benloh]

I'm at http://134.209.73.52/graph/H213FA2020Prokopios/#/
Oh! I misread the Safari output. The size is 5.15MB, but the transferred size is indeed 1.1MB. I did get a Server disconnect though.

We might have to do some auditing to see what the script is doing.

Is this related to the size of the graph? Or do they have similar issues with smaller graphs?

[benloh]

It does look like the websocket is taking a long time to load. Are there a lot of open graphs on this machine?

[jdanish]

The server only has 2 open graphs (you can check - default password is still set for testing). On my machine I’ve closed all of the other graphs. Joshua

[jdanish]

I don't know that the students ever saw a smaller graph in this class. I have a much smaller graph in my class (CHAT: http://134.209.73.52/graph/CHAT/#/) and have had no problems for me or reported, but with only 8 grad students ... not sure what if anything that might mean.

[jdanish]

Here is the database for the large file

H213FA2020Prokopios.zip

[benloh]

@jdanish It seems that I am unable to reproduce the error with the current server even with "Low-end mobile" throttling.

I did do some local testing with throttling and there are a few things we can improve.

There are basically two main factors affecting the page load: 1) network load time, and 2) script performance running/rendering time.

By far the biggest delay is the load time for the page. Even with GZIP compression on, with throttling on (emulating low-end 3G), it takes about 42 seconds to load and render the page. Of that, about 32 seconds is simply loading all of the file assets over the network, and about 10 seconds is script running/rendering time.

The biggest culprit is netc-lib.js, which at 1.2MB takes 30 seconds to simply download. The next biggest file is netc-app.js at a mere 145k.

I tried a few quick optimization strategies:

• Turn off fonts -- Turning off the custom fonts can save about 2 seconds of load time, but doesn't have a big impact on script performance.

• Turn off GA -- Turning off Google analytics might save about half a second in load time.

• Turn off node and edge tables by default -- If we avoid rendering the node and edge tables unless they're displayed, we can trim about 2.5seconds off of the script/rendering time, AND decrease the total blocking time by about 5 seconds (time scripts spend waiting for something else to be completed).

Recommendations

Given that, it sounds like there are some quick and simple things we can do:

1. Turn off font awesome fonts -- two seconds isn't huge, but unless there's a really compelling reason to use load the web fonts, removing them will keep the load more efficient for mobile users.

2. Hide Node and Edge Tables by default -- This is fairly easy to implement and can speed up the initial rendering by about 2.5 seconds.

3. See if we can throw up an initial loading page so the user isn't staring at a blank screen during the load. We probably can't easily do a real progress bar, but a message is better than nothing.

4. GA seems important enough to you, and the performance impact is minimal enough that it seems like we should leave it alone.

Other things to look into

• markdown rendering -- It looks like markdown is only being called when a node or edge is being edited. So it's not a big culprit.

• GZIP -- we are already using GZIP (at least when netcreate is NOT running standalone), so the files are probably already close to their minimum size.

• Minimizing javascript -- According to Google's Lighthouse analysis, we can potentially save 500k (probably uncompressed) if we minimize javascript. We had tried this earlier but the problem is that brunch's built-in optimize function seems to rely on an older version of javascript and is unable to minimize the js. We'd have to do a fair amount of fiddling to get this to work. And it's quite possible that with GZIP already on, we won't get much of an improvement.

• It is theoretically possible to split netc-lib into separate bundles to improve loading time, but this can be fairly involved.

• Look for inefficient js script -- It's quite possible d3 and/or react is being very inefficient somewhere when rendering large graphs. This would require more of an in-depth dive.

---

It's worth noting that the GZipped version has not been tested with students yet, so some of these problems may have already been addressed.

What do you think? Should we pursue some simple fixes?

[jdanish]

Awesome. Yeah why don’t we start with removing font awesome, a loading image, and not rendering the tables until we need them? I believe font awesome was added for the i and ? Icons so am sure those could instead come from google or something else?

[benloh]

Implemented with #129.