Performance issues with Discourse 3.0

The site is also much slower to load on mobile than previously.

This isn’t caching, as I am seeing this per link folllowed.

1 Like

Loading this page made about 60 requests and transferred a total of 1.3 MB for me. With or without cache doesn’t seem to matter. The biggest transferred chunks is (oh wonder) the javascript application itself.
It seems to be that this is something that should be cached / be cachable? Even the downloaded images (OSM logo etc) are not cached.


Paying attention to bandwidth needs is a critical thing to do, now and going forward. It very likely can be better managed, perhaps starting with an urgent feature request ticket. Smarter caching can be a “quick tune-up” amount of effort (not much) and it’s 99% or 100% done (for now).

As far as @SK53 's refreshing notifications, I don’t doubt it! Not just flushing of old caches, but downloading of both code to run things and data which don’t appear to be well-cached. That really should be tuned up.

I, too, have noticed significant differences (sidebar included) with Safari (browser) on macOS, but I’ll reserve further comment for now. I’m on a fast, all-I-can-drink network, so I don’t see / pay attention to download, speed or caching / buffering issues (directly), though I can do some “traffic analysis across the wires” if need be.

I’m glad to see people talking about things like “performance and network bandwidth on mobile devices” as that is truly critical for Discourse 3 (and beyond) to work (in a global project, on a billions-of-mobile-devices planet).

I’ve heard it said before (about software “tuning”): “this is manageable.” We talk about it a bit (like this), the right people are tapped on the shoulder with a small list of possible tune-ups and “things improve.”

It should be said at least once (again?) that “an initial download” is simply going to be a bandwidth hit. So for quite a few (including those who are only just now reading this using 3.0) they might have experienced the worst of it, and it might be better, or sluggish ahead, that’s still yet to be determined.

So, eyes open, everyone. If you see something, say something. We can turn off that spigot as needed.

Steady ahead as she goes, Captain. (Captains, maybe).

Caching is done automatically by the browser unless it is prevented for one reason or another. However, I don’t understand why it doesn’t seem to be cached. Maybe a web developer can chime in here?

  • not sure what “service worker” in the “Transferred” column means. Usually it should say how many bytes were transferred or “cached” if that resource is cached. Anyone know what this means?
1 Like

Maybe you accidentally activated “Deactivate Cache” in DevTools? For me Caching works, only about 700kb are transferred

Okay, nevermind. I found the documentation for the Transferred column - in a nutshell “service worker” means that the caching is handled by a service worker and that no bytes were transferred. The developer tools in Edge are clearer in that it also displays the bytes transferred

In conclusion, it doesn’t seem to be a caching issue at all. What is always transferred without cache is the html page itself, but this page for example is just 40kB.

No, I have not activated that option. Curious:

  • your Firefox shows only 729kB were transferred
  • my Firefox shows 1480kB were transferred
  • my Edge shows only 42kB were transferred


What page were you testing on? I just used this topic page. Maybe there were differences in how much new content was there at reload time?

But I wouldn’t worry too much about it, 500kb to 1.5 MB transfer size are really not much compared to most other websites.

I measured the amount of data actually received by my computer. Using Firefox.
First load: 1,77 MB
Second load: 32 kB
So the caching works fine. :smiley:

Moving the performance conversation to a new topic for better tracking.

@Firefishy bringing this to your attention :slight_smile:

Depending on where you are, that might be the case. In some places that might be enough to make using this site financially impossible.

Separately from that I find that even on a fast mobile broadband connection (31Mbps down) it takes about 5 seconds to load the first page, and 4-5 seconds to load subsequent ones**, following a link from an email. A snappy conversation it is not - if any of the systems I used to work on back in the 80s were that slow on every page load they’d have been thrown out.

** Firefox, Nokia 6.1, Android 10. On a newer phone (Nokia X10, Android 13) it’s about 3 and 2 seconds respectively. better; but still not great.

While I sympathise with anyone having issues with the caching / download size issues with the website, we are running a fairly standard install of discourse. Any issue will likely need to be fixed upstream.

Modern browsers use the brotli compressed assets. Older browsers use gzip compressed assets. Make sure to use network transferred bytes, rather than uncompressed asset size when using web developer tools.

I have briefly tested using the latest Chrome and Firefox, after an initial large set of JS/CSS etc downloads, the subsequent pages load using less than 100KB of new downloads.


I can’t reproduce that though. It takes about 1 second on an Android 11, Firefox, with 1 of 4 bars of 4G connectivity. Which is plausible given that on reload, something like 40kB or so are actually transmitted.

1 Like