Gitea: Firefox renders pages and _then_ applies the styles (page "jumps" as a result)
- Gitea version (or commit ref): 1.1.0
- Git version: n/a
- Operating system: Wndows 7
- Database (use
[x]):
- [ ] PostgreSQL
- [ ] MySQL
- [ ] MSSQL
- [x] SQLite
- Can you reproduce the bug at https://try.gitea.io:
- [x] Yes (provide example URL)
- [ ] No
- [ ] Not relevant
- Log gist:
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?
MCF
All 19 comments
An attempted fix can be found @ https://github.com/go-gitea/gitea/pull/1379. Unfortunately it had negative impact on Chrome =/
cez81
on 9 May 2017
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.
MCF
on 10 May 2017
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.
silverwind
on 10 May 2017
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.
MCF
on 10 May 2017
I'm pretty sure this has to do with how Gitea loads fonts with CSS. I'll look into it this weekend.
sondr3
on 13 May 2017
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).
sondr3
on 14 May 2017
Actually quite simple to fix. Move all <script> and <link> to the bottom of <body> instead of inside the <head>.
bkcsoft
on 14 May 2017
You mean move the CSS to the bottom as well?
sondr3
on 14 May 2017
@sondr3 yes
bkcsoft
on 14 May 2017
As far as I know CSS should always be in the <head> of a webpage, not anywhere else.
sondr3
on 14 May 2017
No, putting CSS in <head> makes them load async, while putting them in the <body> will make them load sync, and not render the page until they're all loaded.
bkcsoft
on 14 May 2017
I'll look into it.
sondr3
on 14 May 2017
External stylesheets (as in <link rel="stylesheet" [...]> is the only thing that needs moving
bkcsoft
on 14 May 2017
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.
sondr3
on 14 May 2017
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
bkcsoft
on 14 May 2017
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.
sondr3
on 14 May 2017
I just tried doing what you recommended, I put all the CSS just above all the <scripts> in footer.tmp and the FOUC still happens.
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:
sondr3
on 14 May 2017
Okey, so I had my facts backwards... http://stackoverflow.com/questions/1642212/whats-the-difference-if-i-put-css-file-inside-head-or-body
bkcsoft
on 15 May 2017
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
sondr3
on 15 May 2017
Related issues
Fastidious
路
3Comments
thehowl
路
3Comments
mirhec
路
3Comments
ghost
路
3Comments
jonasfranz
路
3Comments
Most helpful comment
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