Firefox renders pages and _then_ applies the styles (page "jumps" as a result) #1698
Comments
|
An attempted fix can be found @ #1379. Unfortunately it had negative impact on Chrome =/ |
|
Sorry I looked for an exisiting issue/PR but had forgotten that this class of problem had an acronym (FOUC). Looks like my report is a duplicate. Seems odd though that the problem occurs on any page load - not just on the first page load of the site. There is a lot of javascript in the site though, so perhaps having CSS cached or not has no impact on the problem. |
|
Do you perhaps have your browser cache disabled (like I do)? In theory, the FOUC shouldn't be as bad when the assets are cached in the Browser. Check in the DevTools Network tab, if there are 200 responses when you reload, caching isn't active. Of course this whole situation could be improved by either using HTTP2 or by concatenating the JS/CSS assets on Gitea's side. Another approach could also be to include a few layout-critical styles in the HTML. |
|
On my windows machine I have Firefox set to clear history when it is closed. So request to request it is loading most of the gitea content from cache if you are looking at the Network tab in dev tools. I checked with Firefox 53.0.2 on MacOS and it has the same problem but much less severely (perhaps once ever 4 or 5 page loads do you see the flash). I tried it with content being cached, and without. It did not seem to make much of a difference - which surprised me. FWIW github.com also has a FOUC if you arrive without anything in the browser cache. It is very obvious on Firefox on Windows 7. Not noticeable at all with Firefox on MacOS. |
|
I'm pretty sure this has to do with how Gitea loads fonts with CSS. I'll look into it this weekend. |
|
Dang, didn't know creating a fork and referencing an issue in a commit would ping the upstream repo before the pull request. In any case, I've created a fix for this that locally removes the FOUC. I've tested this in Firefox 53.0.2 on OS X Sierra and since this doesn't happen in Chrome there is no change besides the added JS. Would be nice if someone could also test and verify (but it should work). |
|
Actually quite simple to fix. Move all |
|
You mean move the CSS to the bottom as well? |
|
@sondr3 yes |
|
As far as I know CSS should always be in the |
|
No, putting CSS in |
|
I'll look into it. |
|
External stylesheets (as in |
|
Putting the Font Awesome CSS in the footer didn't solve the problem, you still get the FOUC because your browser will wait with drawing your DOM until all your CSS and JS is parsed. |
|
It's not only the FA-CSS that needs to move, it's all the CSS-files. And no, it doesn't wait to draw the DOM since then we wouldn't get FOUC, FOUC is because it does draw the DOM before all styles are loaded, then redraws it again after they are loaded |
|
That sounds very unorthodox and is not something I've ever seen done on any website. And yes, that's what I meant, the terminology for web browsers is ever so slightly confusing still. |
|
I just tried doing what you recommended, I put all the CSS just above all the The problem is still the Font Awesome CSS, compared to using loadCSS where it loads once the DOM is fully drawn and doesn't have to be redrawn: |
|
Okey, so I had my facts backwards... http://stackoverflow.com/questions/1642212/whats-the-difference-if-i-put-css-file-inside-head-or-body |
|
No worries, trying to work with CSS and HTML and JS is a hodgepodge of hacks and workarounds and whatnot. If moving the CSS to the body would've worked it would've been great :D |
[x]):Description
In Firefox many of the gitea pages are displayed "unstyled" then styles are applied moments later. This results in the raw html appearing briefly then the page "jumps" to it's final formatting rather dramatically. It does not happen everytime a page is loaded but it does happen at least half the time a page is loaded. This does not seem to be page specific, it happens with many of the pages on gitea. I see the same behaviour on try.gitea.io.
Firefox version is 53.0.2 FWIW. I have yet to try it on operating systems other than Windows 7.
I have performed the same tests with Chrome and IE 11. They never seem to have this behaviour.
I have seen this kind of behaviour with other sites the first time they are loaded (oddly github is one such site). It seems to be related to when the css file is fetched. I've never bothered looking into it in details because it usually does not re-occur after the first page load. Presumably because it has the css file loaded from the first page and it is then available immediately in the browser?
Screenshots
I tried to record a video but the video capture tool seems to miss the page jumps. Not sure if that is because they are so brief, or because the screen recorder is tied in with the Firefox and/or OS window rendering somehow - waiting until the screen is rendered before capturing it?
The text was updated successfully, but these errors were encountered: