Feedback on Height Restriction in Confluence Page Banner Module (48px Limit)

Forge Forge Modules and Product Triggers
1

Hi Atlassian Team & Community,

We’d like to share our feedback on the recently announced change to the latest Confluence Page Banner module:

“Due to concerns raised with CLS performance, we’re restricting the banner size to a maximum height of 48px and moving the module back to preview. This change will take effect on December 1st, 2026. Developers currently using the existing module will have a 6-month period to adjust their implementations…”

We are the developers behind the app “Navigation Menus for Confluence” (currently Connect-based, Forge migration in progress). Our app allows customers to configure a custom, expandable navigation menu that appears above all Confluence pages. The announced height restriction to a maximum of 48px will break the ability to show submenus, effectively limiting the menu to a single level – which would be a major loss in usability for our customers.

This change doesn’t just affect our app – it impacts many other apps that use the banner creatively and functionally. It’s also confusing that the previous Connect-based module never had any height limitation at all – and now such a strict restriction is being introduced without prior consultation with the developer community.

As for the reasoning around CLS performance – we believe it doesn’t fully apply in this context. CLS metrics stem from Lighthouse, designed primarily for standalone websites where users may bounce due to poor UX. In internal platforms like Confluence, users generally have no alternative – usage is mandated by their organization. In addition, apps like ours are deliberately configured by admins, who are aware of the tradeoffs between layout and functionality.

Our request to Atlassian:

  • Provide a clear technical explanation of why such a strict height limit is really necessary.
  • Consider less restrictive alternatives (e.g. a maximum initial height with an expand/collapse option).
  • Involve affected developers before enforcing such disruptive limitations.

There’s also confusion about the effective date: Atlassian states the restriction will take effect on December 1st, 2026, but also that developers will have 6 months to adapt. If that’s the case, wouldn’t the cutoff for the current implementation be December 1st, 2025? Please clarify the timeline.

We’d really appreciate feedback from Atlassian and input from other affected developers.

Best regards,
Sven

9 Likes
2

I’d like to share my concerns regarding this change. Fortunately, we haven’t yet migrated our Connect-on-Forge app, as our customers rely on the atl.general web panel having a flexible height.

Had we already migrated, we would have had no way to revert to the Connect version—resulting in an inevitable loss of functionality later this year. That said, this loss is still coming due to the deprecation of Connect, and our customers will lose a crucial part of our app’s functionality.

This not only significantly reduces the value of our app and harms our business, but also severely damages the trust we’ve built with our customers, who rely on our tools. Unfortunately, customers don’t differentiate between Atlassian removing a feature from our app and a bug on our end—they’ll direct their frustration at us, and I completely understand why.

I also feel this change is being driven by the recent push to improve add-on performance. As mentioned in the announcement, the justification is based on concerns around CLS performance. I’d like to point out that CLS is not a performance metric—it’s a user experience metric. Removing this feature won’t address any of the actual pain points customers have, such as slow loading times.

While I understand this change might be easy for Atlassian to implement and may superficially improve Lighthouse scores, it doesn’t solve the real issues users are experiencing.

Lastly, I’d like to offer a suggestion to address the CLS issue without sacrificing flexibility: rather than pushing the page content downward, the pageBanner could simply overlap the page after the initial 48px. This can be achieved by adding a 48px top margin to the page when the pageBanner is present, and positioning the banner absolutely on top of the page.

This approach would eliminate CLS concerns, as the page would no longer shift entirely due to the banner. I understand there may be concerns about overlapping important parts of the Confluence UI, but this could be addressed by implementing an auto-resizing mechanism that reduces the banner back to 48px when clicked outside. This remains feasible thanks to the margin provided by the navigation and sidebar elements.

6 Likes
3

Hey both :waving_hand:

Thanks for sharing your input here. To start with, I want to acknowledge that the changelog entry for this is a bit unclear and lacks sufficient context to paint the full picture of what Atlassian is trying to accomplish with this change. We’ve removed the entry for the time being and the team is going to work to provide some improved communication around this topic. So for now, consider this deprecation on hold. Sorry we didn’t get it right the first time round.

To address the CLS topic briefly:

Removing this feature won’t address any of the actual pain points customers have, such as slow loading times.

This is incorrect. You’re right in that it’s not a complete measure of page load time, and that it’s important this is effectively addressed too. However, CLS does impact a users ability to effectively navigate our products (e.g. quickly navigating through a page that they don’t need to fully load or a user wanting to perform a particular action without needing the rest of the information to show, etc). Perceived performance is arguably just as important as true performance. So it’s not about superficially improving scores, one main driver is that it makes our products feel more performant.

We take the learning here that more information is needed from us, and we will actively consider your other inputs too. Will loop back to this thread when we have more info to share.

-Dan, Head of Engineering, Ecosystem

5 Likes
4

I understand that Atlassian wants good metrics for their products, but as mentioned the trade-off between CLS and usability in these cases are conscious decisions made by the administrator(s).
This is not an inherent part of Atlassian’s product, but rather an added functionality. The argument that CLS performance would be more important than giving the end-user the choice between functionality and performance is not convincing to me.

There can be good reason to break with Lighthouse metrics, if the trade-off is worthwhile to the user. I believe this is not a decision outsiders (Atlassian or app devs) should make for the user, but one that the user needs to make for themselves.