# The initial page load
**URL:** https://meta.discourse.org/t/the-initial-page-load/17323
**Category:** Site feedback
**Created:** [July 8, 2014, 2:37am UTC](https://meta.discourse.org/t/the-initial-page-load/17323 "2014-07-08T02:37:18Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@lukelarris](https://meta.discourse.org/u/lukelarris)
#### Post date: [July 8, 2014, 2:37am UTC](https://meta.discourse.org/t/the-initial-page-load/17323/1 "2014-07-08T02:37:18Z")
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?
---
### Author:  [@tuananh](https://meta.discourse.org/u/tuananh)
#### Post date: [July 8, 2014, 6:13am UTC](https://meta.discourse.org/t/the-initial-page-load/17323/2 "2014-07-08T06:13:29Z")
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
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [July 8, 2014, 7:57am UTC](https://meta.discourse.org/t/the-initial-page-load/17323/3 "2014-07-08T07:57:47Z")
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](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](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/](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](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/](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.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [July 8, 2014, 8:26pm UTC](https://meta.discourse.org/t/the-initial-page-load/17323/4 "2014-07-08T20:26:54Z")
I have a question about WebPageTest – what kind of CPU is it “simulating”? I find it odd that in [your discuss.samsaffron.com example](http://www.webpagetest.org/video/compare.php?tests=140708_9A_AXE-r%3A1-c%3A0&thumbSize=200&ival=100&end=visual) there’s this big pink block which I assume is browser rendering, CPU loading?
On _my_ machine when I navigate to [http://discuss.samsaffron.com/](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.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [July 8, 2014, 8:46pm UTC](https://meta.discourse.org/t/the-initial-page-load/17323/5 "2014-07-08T20:46:27Z")
Some results for [discourse.codinghorror.com](http://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](http://shop.lenovo.com/us/en/laptops/thinkpad/t-series/t430/#techspecs) – 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
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [July 8, 2014, 8:52pm UTC](https://meta.discourse.org/t/the-initial-page-load/17323/6 "2014-07-08T20:52:02Z")
Here are some results for a [specific topic on the same site](http://discourse.codinghorror.com/t/the-infinite-space-between-words/2063). 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](http://shop.lenovo.com/us/en/laptops/thinkpad/t-series/t430/#techspecs) – 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
---
### Author:  [@awesomerobot](https://meta.discourse.org/u/awesomerobot)
#### Post date: [December 4, 2014, 7:50pm UTC](https://meta.discourse.org/t/the-initial-page-load/17323/7 "2014-12-04T19:50:37Z")
Since we’re talking 3-4 seconds; could a loading indicator make that initial pageload feel more meaningful and somewhat shorter?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [December 4, 2014, 8:08pm UTC](https://meta.discourse.org/t/the-initial-page-load/17323/8 "2014-12-04T20:08:19Z")
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”
---
### Author:  [@awesomerobot](https://meta.discourse.org/u/awesomerobot)
#### Post date: [December 4, 2014, 9:30pm UTC](https://meta.discourse.org/t/the-initial-page-load/17323/9 "2014-12-04T21:30:17Z")
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.
---
### Author:  [@erlend\_sh](https://meta.discourse.org/u/erlend_sh)
#### Post date: [December 5, 2014, 12:32am UTC](https://meta.discourse.org/t/the-initial-page-load/17323/10 "2014-12-05T00:32:00Z")
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.
---
### Author:  [@lukelarris](https://meta.discourse.org/u/lukelarris)
#### Post date: [December 5, 2014, 2:34am UTC](https://meta.discourse.org/t/the-initial-page-load/17323/11 "2014-12-05T02:34:15Z")
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?”.
---
### Author:  [@geek](https://meta.discourse.org/u/geek)
#### Post date: [December 5, 2014, 3:37am UTC](https://meta.discourse.org/t/the-initial-page-load/17323/12 "2014-12-05T03:37:36Z")
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.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [December 5, 2014, 3:51am UTC](https://meta.discourse.org/t/the-initial-page-load/17323/13 "2014-12-05T03:51:50Z")
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).
---
### Author:  [@geek](https://meta.discourse.org/u/geek)
#### Post date: [December 5, 2014, 4:10am UTC](https://meta.discourse.org/t/the-initial-page-load/17323/14 "2014-12-05T04:10:08Z")
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.
---
### Author:  [@jesselperry](https://meta.discourse.org/u/jesselperry)
#### Post date: [March 28, 2015, 2:54pm UTC](https://meta.discourse.org/t/the-initial-page-load/17323/15 "2015-03-28T14:54:42Z")
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!
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [March 28, 2015, 9:38pm UTC](https://meta.discourse.org/t/the-initial-page-load/17323/16 "2015-03-28T21:38:21Z")
This may eventually be covered by Ember Fast Boot.
> **[Inside FastBoot: The Road to Server-Side Rendering](https://blog.emberjs.com/inside-fastboot-the-road-to-server-side-rendering/)**
>
> Using JavaScript to write fast, interactive web applications has exploded in popularity over the past few years. JavaScript apps offer many strengths over traditional server-rendered applications. Most notably, rich interactions and lightning-...
---
### Author:  [@ckshen](https://meta.discourse.org/u/ckshen)
#### Post date: [November 6, 2015, 8:15pm UTC](https://meta.discourse.org/t/the-initial-page-load/17323/17 "2015-11-06T20:15:01Z")
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.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [November 6, 2015, 8:20pm UTC](https://meta.discourse.org/t/the-initial-page-load/17323/18 "2015-11-06T20:20:17Z")
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?
---
### Author:  [@ckshen](https://meta.discourse.org/u/ckshen)
#### Post date: [November 6, 2015, 9:11pm UTC](https://meta.discourse.org/t/the-initial-page-load/17323/19 "2015-11-06T21:11:10Z")
Thanks. Here’s the article and the paragraph pasted below:
> **[\- Independent Security Evaluators](https://www.ise.io/knowledge/case_studies/caching/)**
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.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [November 6, 2015, 9:14pm UTC](https://meta.discourse.org/t/the-initial-page-load/17323/20 "2015-11-06T21:14:23Z")
Can you confirm this is still relevant for iOS 9? and latest Safari. Pretty sure this has been fixed…
[Next page](https://meta.discourse.org/t/the-initial-page-load/17323.md?page=2)