Jumping / flickering on page load

[dbrgn]

Technical Bug Report

Your Environment

Software	Version(s)
Form Factor	Desktop
Browser Type	Firefox
Browser Version	63.0.3 (64-bit)

Is this an issue with Rust, CSS, or HTML (or a combination)?

Probably a combination of CSS and webfonts.

Current and Expected Behavior

When loading or reloading the page, the page elements jump around a lot. It seems that the layout is being processed only after page load. (I initially thought that this was due to some JS based layouting, but I can't seem to find any JavaScript.)

Here's a screen capture of the behavior: https://tmp.dbrgn.ch/rust-2018-11-30_00.04.14.webm

For example, the main menu can quickly be seen in the upper left corner. After a short moment, it "jumps" to the upper right corner.

I think there are multiple stages of page loading (got the screenshots by pressing ESC during page load):

1. The raw HTML content

2. Some webfonts have been loaded, some CSS rules have been applied

3. Menu moves to upper right corner, but some page elements like the logo haven't loaded yet

4. Page is fully loaded

The fact that for example the logo isn't loaded immediately seems to indicate that there are no caching headers set up for static files. Could that be? (see also #319) Would probably good to cache all static resources, with proper cache busting parameters appended on deployment.

Step to Reproduce

Load the page in Firefox, then press F5 or Ctrl+F5.

[ashleygwilliams]

this is related to a few open issues currently, but it's an excellent comprehensive issue- so i'm going to opt to close the others in favor of this. thank you for the excellent issue- it's very appreciated.

[yoshuawuyts]

Ive seen this behavior before, and I believe the root cause of it is that we don't inline critical CSS inside each page load. To my knowledge Rust currently doesn't have any crates capable of this, so we might need to get a bit creative.

If I recall correctly, the reason why this only happens on Firefox, and less on Chrome, is because Chrome is a bit more conservative with applying styles, whereas FF is a bit faster to start rendering.

[chriskrycho]

Great writeup! It's a combination of load sequence and caching at play here – fixing our caching story should fix the behavior after the first load, but won't change it for the first load.

@yoshuawuyts yeah, and I note that it also doesn't happen in Safari.

More generally: I want to spend some time thinking on this. In general, the behavior described is what I would expect for a first load (other than that other browsers normally block DOM rendering if there's an ongoing CSS load-and-parse IIRC?), so I'm not sure how much time we'd want to invest here – but I'll also poke around and see what the best options are. Critical CSS is a great strategy in general, but it also may be an over-optimization at this point.

[dbrgn]

Critical CSS would probably be very minimal, mainly the layout (text changing appearance is fine, but entire blocks of text jumping around are irritating).

[chriskrycho]

An update: this seems to be a more general behavior of Firefox Quantum, *combined with *how we still have a combination of Skeleton and Tachyons. The FF Quantum bits are not something we can do anything about without doing Critical CSS as far as I can tell (and I'm not even sure about that). The other parts are simply a matter of finishing the migration.

I'm inclined to bump it from Edition Release accordingly unless we manage to finish everything else first with a lot of time to spare: we can't change FF's behavior, and we probably don't have bandwidth to finish the migration to Tachyons in that time. (We're close, but Thursday is coming very quickly.)

[chriskrycho]

Given we landed #538, I'm going ahead and moving this from the Edition Release milestone to the End of the Year milestone. It's still not perfect, but we get a single bit of re-layout along with some flash of unrendered text from fonts loading in, rather than the sequenced problem we had before.