The initial page load

Contribute Site feedback

AI 生成的摘要

The discussion revolves around the initial page load of Discourse sites, with lukelarris expressing dissatisfaction with the 1-3 second delay before the page loads. tuananh suggests using a CDN to improve load times, while sam shares his experience of optimizing his Discourse site to achieve an initial render time of 3.5 seconds.

sam attributes the slow load times to the nature of JavaScript applications, which render on the client side, and mentions that a major architectural shift would be required to enable server-side rendering. He also compares the load times of Discourse to other sites, such as Vanilla and IPBoards.

codinghorror questions the accuracy of WebPageTest results, citing a significant difference between the reported load times and his own experience. He provides test results for his own Discourse site, showing load times ranging from 3.5 to 10.8 seconds.

The discussion also touches on the idea of implementing a loading indicator or animation to make the initial page load feel more meaningful. awesomerobot suggests this could be an effective way to make the load time feel shorter, while sam expresses reservations about making the site feel like a “flash website.” erlend_sh proposes a loading message with a cute animation, similar to those found in AAA games.

The conversation also covers the performance of Discourse on Android devices, with geek reporting a significant delay before anything appears on his Nexus 9. codinghorror attributes this to the 3x to 5x performance penalty for Android.

Finally, ckshen suggests techniques to optimize page load times, including packaging JavaScript together in one big package and using async loading. sam confirms that these techniques are already being used, and expresses skepticism about sacrificing security to work around old browser bugs.

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?

8 个赞
How to add a loading page, some like Gmail?
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

3

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

http://www.webpagetest.org/video/compare.php?tests=140708_QJ_AMX-r:1-c:0

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

http://www.webpagetest.org/video/compare.php?tests=140708_CW_ARE-r:1-c:0

And that IPBoards takes 2 seconds

http://www.webpagetest.org/result/140708_7H_AV4/

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

http://www.webpagetest.org/video/compare.php?tests=140708_9A_AXE-r%3A1-c%3A0&thumbSize=200&ival=100&end=visual

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 http://www.webpagetest.org/result/140708_VJ_AYX/

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.

8 个赞
4

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?

Pasted image893×236 36.2 KB

On my machine when I navigate to http://discuss.samsaffron.com/ 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.

1 个赞
5

Some results for discourse.codinghorror.com 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
2 个赞
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
1 个赞
7

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

1 个赞
Show a loader starting page for slow connections?
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”

1 个赞
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.

10

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.

3 个赞
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?”.

3 个赞
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.

1 个赞
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).

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.

8 个赞
15

This.

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!

3 个赞
16

This may eventually be covered by Ember Fast Boot.

7 个赞
Show a loader starting page for slow connections?
17

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

19

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.

20

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