When you go to a Discourse site for the first time, it can sometimes take about 1 - 3 seconds before the page shows anything but a white background. Call me impatient, but I don’t like that. I like my sites to load almost instantly, and Discourse sure doesn’t load very fast the first time on every Discourse forum I’ve visited. However, when it’s loaded, browsing the forum is pretty quick, so no complaints there.
The reason it bothers me so much is because that initial page load is very important to me. I believe it really helps my site in the eyes of the user if the site loads instantly. They may not browse around, or even join, but a snappy first page load will leave a positive impression, if only subconsciously.
Is there anything people can do on their host to make that initial page load faster? I know upgrading hardware is one way, but is there any optimizing or caching we can do to improve things?
Also, does the Discourse team have any plans to improve the speed of initial page loads?
CDN would be first thought. On first visit, discourse has to load a bunch of js, css and fonts so its understandably slow (especially on mobile network). After that, things are cached and everything is pretty smooth
Ensuring we compress all our dynamic and static content at a much higher level (10-15% network savings)
Ensuring last modified date ships with all assets (avatars, letter avatars, cdn assets) - improves cdn perf
Serving statically compressed assets where possible
This is pretty good considering we are
Serving meta over HTTPS
Our CDNs HTTPS performance is sub par
We have no way of rendering anything before all the JS and CSS downloads.
The nature of the “JS application” beast is that rendering happens on the client side, this is a limitation of Ember.JS, it is possible that some time in the next few years we will be able to render the html server side. But … we would be talking a major architectural shift to support that.
Considering sites like Vanilla (a more traditionally designed non HTTPS site) take 2 seconds
But… on the upside due to the fact we only need JSON to navigate around a site we perform significantly better once the site is loaded than traditional apps when dealing with constrained networks.
Its a balancing act, eventually I hope to have a server rendering story, but for the time being I think we are doing quite well.
I have a question about WebPageTest – what kind of CPU is it “simulating”? I find it odd that in your discuss.samsaffron.com example there’s this big pink block which I assume is browser rendering, CPU loading?
by the time I get to the middle of “two one thousand”, your site is loaded (and I haven’t been there in months, so cache had to be super cold.)
I know these are relative numbers, but that seems like a big difference from “3.5 seconds” in practice. Seems like you can take the “real world” times WebPageTest reports and more than cut them in half to get… real real world times.
Slack tend to do this, but they have much longer loading times. I am not sure, its not super common to have these and makes your site feel like a “flash website”
yeah, definitely wouldn’t want to make it feel like a flash site; actually never noticed how crazy long Slack’s loading time is until just now — the app has a spinner-type thing and then an additional loading message.
I can imagine a pretty/cute welcome message could be very effective though.
E.g.
So instead of a loading animation, it’s more like the beautiful loading screens of AAA games that need to divert your attention to shiny things for a while as they do some background processing.
It might, flash reference aside. It might bring more attention to the fact that it takes a while to load initially though, people would be like, “hey, can’t you guys remove that spinner so Discourse loads faster?”.
When load Discourse pages on my new Nexus 9, there is a huge delay before anything appears, to the point where I usually wonder if it is actually loading.
Some type of animation for slow browsers might be a good idea.
This is the 3x to 5x perf penalty for Android in action, though. Nexus 9 is perhaps the fastest Android device out there, and in Discourse it performs between the iPhone 4s (2011) and the iPhone 5 (2012).
Right… I am aware of that. I meant an animation loading in the HTML before the JavaScript loads. So the server responds immediately with something at least.
Would really appreciate some basic initial load graphic. Especially for users that are easily confused by nothing appearing immediately.
That being said - so impressed with the speed of Discourse overall. My hope is it would be relatively simple to implement an initial load graphic, even if it didn’t have a loading bar.
Sam, would you consider these techniques, the first one is used by Cloudfare to optimize pages (though experimentally):
Package the JS together in one big package to reduce latency. (this one Cloudflare employs to great effect) Async loading (I think you may be doing async already)
Can JS be gzipped? They are big.
Https for only the login screen. Safari and iOS don’t cache static resources over https I understand.
Sacrificing security to work around old browser bugs sounds very odd to me, first I heard of this https caching issue can you link to a relevant article on it?
Safari. Apple Safari does not cache HTTPS-delivered content to disk, regardless of any headers sent by the server. ISE tested the mobile version of Safari on an iPad 2, and the HTTPS caching behavior was identical to the desktop version.
ISE verified that using Safari 6.0 (7536.25) on Mac OS X 10.7.5, and Mobile Safari on iOS 5.1.1, HTTPS content is never disk cached.
