Hey @digitaldominica - it’s not related to the Ember upgrade, but it is a known issue with the new admin sidebar. More details over in Introducing experimental admin sidebar navigation - #37 by martin
Okay noted. Thanks
2 Likes
David, can we safely assume that the next stable release will be Ember 5 only?
Additionally, any thoughts on an approximate timeline for the next stable?
5 Likes
The next stable is scheduled for 30th January, and AFAIK we’re still on-track for that.
Ember 5 will certainly be the default in the 3.2 release. TBC on whether Ember 3 will still be available behind a flag. I think most likely yes, but we’ll aim to make it clear that it’s not a ‘supported’ configuration (e.g. via an admin warning).
9 Likes
Thanks
That would be incredibly helpful in order clarify things for eg clients.
6 Likes
Apologies for the necro-response. The warning banner would appear every so often and then disappear again before I could figure out what was causing it to appear. It hasn’t appeared for several weeks now. 
3 Likes
Thanks for following up @xJack. The Ember upgrade has now been deployed across our hosting for several weeks, so I imagine the issue you were being warned about has now been resolved 
4 Likes
We’ve now dropped the EMBER_VERSION feature flag. Going forward, Ember 5 is the only option.
Thanks to everyone for your help in rolling out this upgrade! 
16 Likes
Question: Does this make the JS more optimized at all, or no? I only ask because on basically every site performance test (GTmetrix, Lighthouse, WebpageTest, etc), with no plugins enabled, default theme, etc., they always say that there is a Total Blocking Time of 2-15s with the JavaScript scripts…
Example:
1 Like
The upgrade itself is not expected to affect performance. However, it does unlock techniques which we can use to reduce our JS payload size (and therefore initial load performance) in future.
One concrete example are the new build technologies unlocked by embroider. Theoretically, those techniques will allow us to delay loading route-specific JS modules until they’re actually needed.
We’ve already started doing this for the Wizard, which means other pages don’t need to carry the weight of all that code. We will be expanding that to more parts of the app in future, but we need to be very careful about theme/plugin compatibility.
5 Likes
How far in the future we talking here? Thank-you for the reply! Yeah, I’m loving the Discourse software so far as a new-ish user of it. My main gripe is really just optimizing the JS stuff since that seems to be the biggest thing for load times that I’ve noticed.
1 Like
Performance improvements are something we’re constantly investing in, so I don’t think there will ever be a date when it’ll be “done”.
In terms of the metrics you shared, it’s important to note that those reflect only the first visit to the community. Clicking around the site, and coming back in future, will be significantly faster!
5 Likes
If your first load time is critical, use a platform like this instead to create a blog:
… which is lightning fast.
If you want an extremely rich forum app, stick with Discourse.
This statistic has come up a lot on here, even recently.
Judging only by first load time is not reasonable as a lot of the app is being downloaded on first visit (similar too, but not exactly the same as an app on an app store), and that will then be cached for:
- changes between routes (not pages, it’s an app!)
- changes of e.g. filters
You will note how incredibly quick Discourse responds as you navigate around.
That’s because it doesn’t have to load each page and is just loading the raw content from the API.
3 Likes
But it’s what Google does, so we’ll have to live with it.
2 Likes
Hopefully they’ll start including ‘soft navigations’ in Core Web Vitals soon 
10 Likes