The initial page load

(Luke Larris) #1

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?

How to add a loading page, some like Gmail?
"Executing action: latest" Taking a Long Time
(Tuan Anh Tran) #2

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

(Sam Saffron) #3

I spent some time tuning today, after my fixes we now are able to do an initial render in 3.5 seconds:

My fixes included:

  1. Ensuring we compress all our dynamic and static content at a much higher level (10-15% network savings)
  2. Ensuring last modified date ships with all assets (avatars, letter avatars, cdn assets) - improves cdn perf
  3. Serving statically compressed assets where possible

This is pretty good considering we are

  1. Serving meta over HTTPS
  2. Our CDNs HTTPS performance is sub par
  3. 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

And that IPBoards takes 2 seconds

And that Discourse on non HTTPS without a CDN on digital ocean takes 3 seconds

So yeah, we are a second slower on initial render than the competition and about 1.5 seconds off from leaders in this area like say stackoverflow WebPagetest - Running web page performance and optimization test...

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.

(Jeff Atwood) #4

I have a question about WebPageTest – what kind of CPU is it “simulating”? I find it odd that in your example there’s this big pink block which I assume is browser rendering, CPU loading?

On my machine when I navigate to I can barely get through

  • one one thousand…
  • two one thousand…

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.

(Jeff Atwood) #5

Some results for home page. Times are initial load / subsequent loads:

LA, CA – Chrome

  • Load Time 4.7 / 1.6
  • First Byte 0.2 / 0.1
  • Start Render 3.5 / 1.6
  • Requests 119 / 1
  • Fully loaded KB in 848 / 14

Dulles, Va – Chrome

  • Load time 4.7 / 1.6
  • First byte 0.2 / 0.1
  • Start render 3.5 / 1.6
  • Requests 119 / 1
  • Fully loaded KB in 848 / 14

Dulles, Va Thinkpad T430 – Chrome

  • Load time 5.3 / 2.3
  • First byte 0.5 / 0.2
  • Start render 4.5 / 2.3
  • Requests 119 / 1
  • Fully loaded KB in 848 / 14

Montreal, Canada – Chrome

  • Load time 10.8 / 8.5
  • First byte 0.3 / 0.2
  • Start render 8.7 / 8.3
  • Requests 119 / 1
  • Fully loaded KB in 847 / 96

Manchester, UK – Chrome

  • Load time 6.0 / 3.8
  • First byte 0.5 / 0.6
  • Start render 4.9 / 2.1
  • Requests 120 / 2
  • Fully loaded KB in 848 / 14

(Jeff Atwood) #6

Here are some results for a specific topic on the same site. Times are initial load / subsequent loads:

LA, CA – Chrome

  • Load Time 3.8 / 2.0
  • First Byte 0.2 / 0.4
  • Start Render 3.6 / 1.1
  • Requests 41 / 1
  • Fully loaded KB in 666 / 23

Dulles, Va – Chrome

  • Load time 3.5 / 2.2
  • First byte 0.5 / 0.2
  • Start render 3.5 / 0.9
  • Requests 41 / 2
  • Fully loaded KB in 748 / 23

Dulles, Va Thinkpad T430 – Chrome

  • Load time 4.7 / 3.7
  • First byte 0.3 / 0.2
  • Start render 4.7 / 1.6
  • Requests 40 / 2
  • Fully loaded KB in 748 / 22

(Kris) #7

Since we’re talking 3-4 seconds; could a loading indicator make that initial pageload feel more meaningful and somewhat shorter?

Show a loader starting page for slow connections?
(Sam Saffron) #8

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”

(Kris) #9

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.

(Erlend Sogge Heggen) #10

I can imagine a pretty/cute welcome message could be very effective though.


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.

(Luke Larris) #11

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?”.

(Lowell Heddings) #12

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.

(Jeff Atwood) #13

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).

(Lowell Heddings) #14

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.

(Jesse Perry) #15


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.

Thanks for considering!

(Jeff Atwood) #16

This may eventually be covered by Ember Fast Boot.

Show a loader starting page for slow connections?

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.

(Sam Saffron) #18

One and two are already done

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?


Thanks. Here’s the article and the paragraph pasted below:

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.

(Sam Saffron) #20

Can you confirm this is still relevant for iOS 9? and latest Safari. Pretty sure this has been fixed…