Why Discourse PageSpeed mobile Insights speeds are so low?


Hi, I started using discourse recently, loving it and all and now I’m optimizing for SEO.

One thing that stands out for me is that the discourse is the lowest ranking website served on my server.

Especially mobile is a issue since my target is people in a country with slow, not reliable mobile data.

The mobile has several issues that amplify those issues - like 8 render-blocking round trips.

With my server, google even says my server responded in 0.54 seconds! Which is weird, because I have other websites running under same reverse proxy and cloudflare settings without this issue! And I don’t even know where to start debugging this.

You can check for yourself at: PageSpeed Insights

I worry because google will rank my website based on analysis like this - so even if I think discourse is amazing, google may not rank me in mobile searches and choose others instead with better rankings, and most of my traffic is mobile.

Loading this forum with my 4G plan and great signal takes around 7-10 seconds. I could see that in some situations this could easily become 15 seconds.

Perhaps bundling PageSpeed Module  |  Google Developers in the docker nginx default settings could help? It’s open source.

Thank you!

(David Taylor) #2

Discourse is a complex single page web application, and as such will always be slower on ‘first load’. You can read some previous discussion on the topic here:

(David Taylor) #4

Are you actually seeing an impact on search results for your site? Google uses a huge range of metrics for ranking - page speed is only one of them.

(Jay Pfaffman) #6

I think you can remove the rate limiting template from app.yml.

(Jay Pfaffman) #8

Oh. I just looked more closely. You’re using a reverse proxy and not getting the real ip all the way to discourse,i suspect.

(Jay Pfaffman) #10

You’ll need to add the cloudflare template and search here for help on getting the right ip all the way down. You’ll want to make sure that your ip is being logged and not something upstream.


possibly related: Discourse socketed: Nginx in front of discourse: no IP adresses

(Jay Pfaffman) #13

That’s not what you said here:

If you want to solve your rate limiting problem, you’ll first need to solve your IP problem. is Docker’s IP.

(Ultra Noob) #14

Unfortunately, Concatenation of JavaScript and CSS are the old-school things of HTTP 1.1 age, when each HTTP request used to be quite costly. When there was trend like image Sprite, reducing HTTP request, etc.

Now, it’s time to forget about few Yslow rules which was written long time ago. Internet has changed so much.

It’s age of HTTPS, HTTP/2 where request load much better without even bundling. It’s not necessary.

I would suggest reading this article to know more about HTTP/2.

PageSpeed Insight is not right tool to judge performance. It doesn’t check actual load time.

There are many scripts like Adsense (adsbygoogle.js), Google analytics, all fail at their own rule of so called Leaverage Browser cache. And Funny thing, if it is considerable may be it shouldn’t simply appear as warning. Well, why not prefer another tool called WebPageTest, it is more accurate and meaningful.

Back to Page Speed, Discourse is faster. No need to follow snake oil tools recommendation. It’s all bullshit, even their own site will fail getting 100/100.

If you want to maintain performance in the real world, below are some tips I would highly recommend -

  1. Monitor your CPU usage, Memory usage via SSH. Go for faster CPU and sufficient resources.

  2. Use less plugins as possible as.

  3. Choose correct server location. Many user do serious mistake at this point. I see they get traffic from India, they choose USA. Why? Blind target!! I would suggest, choose server location as per your major audience region. You can find some realistic data using Google Analytics.

  4. Needless to say, keep software updated. It is continuously improving. Thanks to Discourse team.

  5. Use HTTPS to leverage HTTP/2.

  6. Avoid reverse proxy kind of CDN. It will badly increase TTFB up to 2x.

  7. As possible as - Avoid use of third-party JS, this includes Google AdSense also. If you really need, use asynchronous approach to load it, so it do not block DOM and make rendering faster.


(Jay Pfaffman) #17

Discourse uses ip addresses to identify and block spammers, for one thing. And there are others. Search for cloudflare and maybe reverse proxy.

(Ultra Noob) #18

Cause: Cloudflare Reverse Proxy CDN

(Ultra Noob) #20

It will mess up your site badly. Please do not. Discourse is not officially supported for it. For that you should look for fastly may be!!

(David Taylor) #21

As @Gulshan_Kumar, this is a bad idea. You will almost certainly cause problems with your installation.

The only CDN setup we recommend is described here:

(Jeff Atwood) #23

Cdn77 is not $50 per month.

(Jeff Atwood) #25

That is a screenshot from CDN77? I don’t think it is?

(Jeff Atwood) #28

I see no mention of $50 per month minimum here

(Sam Saffron) #29

At the end of the day stuff is limited by the speed of light. Especially TTFB. Adding another hop between end users and dynamic content comes at a cost. At low volumes all of the magic of Argo is still likely to make stuff slower see this for an explanation of what Argo is: Performance through smart routing and tiered caching | Cloudflare. Testing from one single location is also a huge anti pattern, you have no control over where google is testing from.

For context … ping times from Australia to the US west coast are 200ms.

(Rafael dos Santos Silva) #32

You know that Discourse is a JS app right? :stuck_out_tongue_winking_eye:

Maybe check using static generated sites (Jekyll, Hugo, etc) to get the desired page speed score.

(Ultra Noob) #34

In advanced: Please do not blame Discourse if you notice any issue.

Discourse uses cache-control: no-cache, no-store value for serving content. By overriding this pattern, definately something will go wrong. All the best!!

User experience first > not Just fast TTFB

(Stephen) #36

You need to be very careful with Cloudflare caching, you only want to cache uploads, not CSS or JS. If you cache the latter you’re going to have a Very Bad Time™.

You also need to make sure you “Disable Performance”, which can also be achieved with a page rule.