I am on a very slow internet connection in a rural area now. And when initially loading my discourse instance, it takes like 2-3 minutes with a blank screen and suddenly everything appears. So i guess it is loading all the assests and the app in the background in that time.
It would be nice to see a fast loading static html page with a loading… until the actual loading of the app has been completed in the background for such slow connections i feel.
Related:
Sure, feel free to submit a pull request that adds this!
Preaching to the choir.
@codinghorror, if we were able to insert html to lod right after the body tag, wouldnt that show right away? There should be html / js that can be added that could then disappear upon page load.
Sorry, I am not a technical person though I can manage editing css, write the html page, build discourse app and manage my droplets on DO. If someone can guide me a bit, I can try.
As already said in different trends (here and here) the best solution would be to install fastboot in discourse but since this is quite big task which will require more time i suggest within this issue to implement a middle-way solution which will give feedbacks to the users about the app loading even if it will be not the most useful informations.
A recent approach in the design world is the skeleton screen preloading, a blank version of a page into which information is gradually loaded, currently used by Facebook and some other important applications.
This give to the users the feeling the page is being build and avoid the frustration coming from the constant looking of loading icons.
I found two way to implement this technique:
We should anyway keep in mind that long wait time should go along with a progress loader indicator
What do you think?
Other interesting resources:
I like the idea of using a “skeleton screen” also for a starting page that’s loading. We actually have a concept of this already, but strictly for topics. You can find a really long topic and test it yourself:
@eviltrout do you think there’s a way we could reuse that for an initial page load?
Hmmm, maybe we could sneak a loader animation into the placeholders themselves somehow? Like one of the mock text bars going from left to right as if to finish the paragraph. Ideally you’d never notice it until you run into a longer page load.
If we did that for initial page load you’d get quite a bit of a Flash of Unstyled Content effect that I suspect would look much worse.
Oh cool. i didn’t notice you already have for topics!
@eviltrout so are you suggesting to add a simlper loader?
Maybe the best solution would be to add a simpler loader icon and if the loading take mor ethen 2 sec, use the skeleton screen.
No I’m not suggesting that right now. Long term I would love something like FastBoot but as you pointed out it’s a lot of work.
I think we can live with longer loading times for now – Discourse is the type of App people spend a long time using once it’s loaded, unlike a lot of content sites – it’s not hurting us much right now to load a little longer.
In the future as we switch the asset pipeline to something else, we can look at ember engines and splitting our app into smaller chunks that will help tremendously.
So nevermind the skeleton layout, but what about a very basic loader? One good example is LinkedIn, which I believe is using Ember as well:
They do a bit of skeleton magic as well, but all I wanna point out is the loader. Their first-load time is quite long, but the load animation makes it way more bearable.
Errrr we already have this? It’s the spinning circle outline?
Really? I’ve never seen the spinner appear on the initial page load…
I dunno if a whole bunch of risky work is necessary for that one particular case, when we already do display a loading spinner in literally every other case.
If it’s possible without breaking anything, and without a ton of engineering time… perhaps?
Even better than “add a first load animation” is to simply make first load fast enough that no animation is needed. Certainly a more effective use of our engineering time.
Agree with @codinghorror even if a loader/animation like the Linkedin one, is actuallty very fast to implement.
Nevertheless we could still have Flash of Unstyled Content.
That doesn’t dipend from the loader image or technique but mostly by the loading time.
Is there an easy way to show the loader just if the loading time is above 1.5 seconds or so? I think so.
But from @eviltrout words, i understood he would prefer to postponed this issue and speed up the loading time instead (at one point in the near future).
This is Discourse on Chrome Beta, it’s loading from splash to functional app without any blank screen when using the improved Add to Home screen
That’s nice!! I would add a little animation, to give feeling of something loading but anyway is nice.
Do we want to try to implement this and see if it works smooth?
The splash is generated by Android automatically and we have no control over it.
I agre with @eviltrout that we can wait a bit on this, we got much faster last year (brotli, smaller payloads, HTTP/2, latest EmberJS) and will probably get more speed this year (Chrome new JS runtime, HTTP/2 Push).
ok, so look like most of the people think is not worth to implement it now.
Can’t you avoid the FOUC if the loading indicator uses entirely inline styles and data: images? Which is reasonable for something handcrafted to be small I think.
Here’s a CSS hack if y’all are still interested: