Improve frontend performance

[jchristgit]

trafficstars

When opening the homepage without the page's styles in cache, the homepage flashes around before the layout is fully loaded. We should load the CSS synchronously or use another solution to prevent this.

To reproduce, refresh the website clearing the cache (on Firefox, CTRL - Shift - R). The slower the connection & the higher the latency, the easier to reproduce

[hedyhli]

I couldn't reproduce the FOUC behaviour for my devices and browsers I used, even on slower networks. However while working on my dark theme PR I noticed a lot of opportunities to improve performance.

The main ones:

• Minify large images, for smaller images the resolution can be reduced unnoticeably, and also the dimensions
  • Or opt for better image formats where applicable
  • This is especially problematic for images in the homepage hero. When a user visits a site for the first time it's likely they are visiting the homepage. The codejam thumbnail we're showcasing takes a long time to load the first time. If the performance can be improved there, shifting of other elements can also be reduced (because the cover image is the first visual element at the top, excluding the navbar)
• Reduce the number of requests for fetching static resources, such as avoiding fetching external libraries (like JQuery) if they provide only a little development convenience (also see #1209)
• There are CSS files, especially the one for the timeline, with a lot of rules largely unused and redundant. I'm not sure where it was copied from, or why, but I do think the size there can be improved significantly following a refactor
  • This also applies to the CSS in cases where multiple rules are used to achieve something that can be done in a much simpler approach
• There are places where we modify visibility of elements through javascript which might be loaded some time later than the elements themselves. There might be opportunities there to delegate control of visibility (or other things the JS is doing) somewhere else (such as CSS or backend), which helps with large visual movements on page loads
• If there is a good way to control the cache TTL from the backend with least overhead that could help as well

Other ideas which probably won't help as much

• Refactoring the html in templates together with CSS
• Serve minified static resources (this can be done once every time the server restarts, not for every request) This was mentioned in #355 and django-simple-bulma already supports this. It should be extremely easy to do
• It might help if we know which endpoints are the most visited. My wild guess points to the resources, which is linked often in the server. So improvements to those pages might help the UX a lot

Other resources:

• https://github.com/python-discord/site/issues/355#issuecomment-635235655
• https://seirdy.one/posts/2020/11/23/website-best-practices/#optimal-loading

[jchristgit]

Hmm, I can't reproduce this anymore either, maybe because of #1161 or something similar?

I agree with you on the other points. I will update this issue for those

[jchristgit]

Actually skip that. I've found a reliable way to reproduce it:

• In Firefox, open devtools, then go to the network tab
• Select "Regular 2G"
• Force refresh

There should be a FUOC reproduceable using this method. Can you check?

[hedyhli]

Yes, with Firefox using Regular 2G throttling I can reproduce this. However anything above Regular 2G it does not happen. With Chrome-based browsers using network conditions equivalent to that of Firefox's Regular 2G I cannot reproduce FOUC either.

I wonder if this is less about our site performance and more about a Firefox bug. Locally I tried out this fix, and it worked: https://stackoverflow.com/questions/21147149/flash-of-unstyled-content-fouc-in-firefox-only-is-ff-slow-renderer

It blocks any rendering of the (unstyled) page until it's fully loaded. So before that happens the user sees a blank page.

[jchristgit]

Wow, I didn't know that, but it does indeed seem to be a Firefox bug! That's really annoying. And the fix is kind of strange... I wonder if it's worth to include.

[hedyhli]

Firstly I believe the overall frontend performance can be improved.

Now since this fix targets specifically for firefox users on an incredibly slow connection, it's a matter of comparing the user experience for this audience:

1. Blank screen, shortly after, unstyled content loads first, then some time later the styles are loaded and applied. (if we don't include the fix)
2. Blank screen, a long time later the entire page loads together. (if we include the fix)

If the overall frontend performance can be improved to such an extent that the waiting time of behavior (2) is acceptable, then I think this fix is definitely worthwhile to include. Especially considering it's a Firefox problem.

However right now since we do not have any significant performance improvements work being done, behavior (1) is better IMO so the user can see at least some part of the webpage being loaded first, so they can wait a bit longer for the styles. As compared to (2) right now where the user only sees a blank screen, they might get impatient and close the site. This is just my personal experience when I am the user, though.