I get really bad vibes from some of my clients, who feel like they have been forced to migrate into a beta product.

"We've lost our connection to you, so we've disabled editing to prevent any issues. You'll be able to edit once we reconnect. Trying to reconnect"

Why is the status "Closed"?

This issue is not acceptable as it's blocking for work activity of whole team.

In these conditions, how can this tool be used for professional use?

We've lost our connection to you, so we've disabled editing to prevent any issues. You'll be able to edit once we reconnect. Trying to reconnect...

Hi Atlassian support,

We are in December 2021. Do you have any news on this problem?

Thanks in advance

Best Regards,

Antonio

Hi,

After filing a community support topic regarding the connection lost error, I was asked to comment on this page to let you guys know that another person is impacted.

https://community.atlassian.com/t5/Confluence-questions/Connection-Error-We-ve-lost-our-connection-to-you/qaq-p/1800308?utm_source=atlcomm&utm_medium=email&utm_campaign=mentions_answer&utm_content=topic 

At the moment, we are evaluating Confluence as a product and our team has been using it for 2 months already. We're still at our Free tier limit (10 users, mostly engineers using), but plan on recommending this to management to onboard other users in the next few months of evaluating. However, due to this issue, we will have a hard time proposing to pay for a laggy product.

It's a bit frustrating since we've done a lot of work on a single page, and after publishing it, we could not edit it due to this issue. We're trying to break down long pages to solve this issue, but even with that we don't know what the "limit" is before we encounter this issue.

I hope the Atlassian team can fix this since the issue has been first filed in 2018 (https://jira.atlassian.com/browse/CONFCLOUD-64686)  and this ticket has been created for more than a year already.

Regards,

RB

Hello. My performance issues are mostly concerning the page include macro.

I have several dozen on a single page, as we find the content reuse an indispensable feature. And the parent page is for a Reference Manual, so it has several sections. Asking us to break up this parent page into several smaller pages brings us back to the days of breaking up complex Word files into chapters (due to its limitations) and reassembling them as one large PDF.

We will also lose the ability to cross-reference from within the one large page if we were to break up the page into smaller ones. 

But the load times and the constant "We've lost our connection..." messages after nearly every insert or attempt at editing text is frustrating, and any workaround sounds good at this point and worth some sacrifice as we wait for a genuine solution.

—

To add to the frustration, after having moved content to external pages and did the page include macro, the Table of Contents in the parent page does not grab the child pages' headings.

It's as if we're going from bad to worse on this workaround.

90253c67a11f yes please go and vote for the relevant issues impacting your team.

9d3e03f83e46 thanks for your pointed feedback regarding the table editing experience. When you switch from editing tables to other parts of the document, what's the specific performance issue you're experiencing? Is the page freezing? Are you encountering input lag? If it doesn't fall under the themes we have identified above, my ask is that you create a new ticket so that we can appropriately categorise the issue, and better understand how many others are experiencing similar performance issues. 

Thanks for the update.

However, from my experience: it's the switching from editing the TABLES to editing other regular parts of the document (and back) that causes the problem. Not the size or other factors.

So do we have to go and 'vote' on those issues where our team is impacted? 

See this comment for the relevant tickets to follow regarding slow performance issues when viewing and editing Confluence pages

Hi all,

This is Ethan from the Atlassian Editor Team. Thank you for the continuous feedback on performance improvement needs within the Confluence editing experience. Over the past 12 months, Atlassian teams have been improving our monitoring capabilities to detect performance degradation and updating various parts of the backend architecture to improve 2 issues of primary concern outlined in our last update: keyboard typing performance and frozen pages. As a result, editing input latency spike has dropped from 274ms at p99 to 80ms from November 2020 to July 2021. Similarly, fewer customers are citing frozen pages while trying to edit pages.

Nonetheless, we recognise there is still plenty of ground to cover on making our products faster. New themes are emerging in the more recent customer reports, so we will deprecating this ticket by splitting it into the following to better track different performance degradations:

1. Slowness rendering Non-Content PAGE FEATURES when VIEWING a Confluence page
2. Slowness rendering IN-PAGE CONTENT when VIEWING a large Confluence page
3. Slowness initially rendering a large Confluence page in EDIT mode
4. Keyboard typing delays while trying to EDIT a Confluence page
5. Changes are lost and unsaved after EDITING a Confluence page
6. Inability or delay of publishing EDITS to a Confluence page

Atlassian teams will focus upcoming efforts to actively address themes 1-3, which involves optimising the performance of the base editor and renderer components. This should improve the time-to-interact for both the page editing and viewing experiences in Confluence for all types of pages. Following this, we will narrow our focus on optimising the performance of specific page elements when editing pages with large amounts of content, including tables, macros, and other media.

In the mean time, we will continue to monitor issues related to themes 4-6. To improve both the viewing and editing speeds of large pages, we still recommend splitting up the page into multiple pages for a more performant experience.

We aim to provide the next update on our progress by Dec 2021.

Thanks all and stay safe,

Ethan

The page I'm trying to create definitely falls under the following category, though I'm not sure if I'm working on the New Editor or not

• Keyboard typing delays while tying to EDIT the page on the New Editor

This two scenarios this has been most apparent which have become major roadblocks for my work are:

1. When I attempt to make large tables (over 20 separate tables with dozen's of rows and columns) the keyboard is delayed and the page lags out.
2. When I attempt to split the page into multiple sections yet I've included dozens of pictures in my page, the keyboard is delayed and the page lags out.

These issues disappear when using pages with data limited to text.

Looking forward to seeing this issue resolved.

Crippling slow and affects my productivity by a huge amount as I constantly need to edit documents with lots of tables present. If this doesn't qualify as a critical I'm a bit surprised. I wouldn't have shipped this product with this issue.

If Atlassian have no interest in resolving this issue promptly is there at least a way to revert a page to the old editor?

This does qualify as critical for me, in that it makes it really difficult to convert others in the business to want to use Confluence, when they say "it is slower than a word file". - Not interested.

To that end, it has a significant impact on us purchasing more licenses to include more members in the echo system.

Same problem on Brave, it's a definitely annoying bug but I wouldn't call it critical. I'm trying to structure a Test Fixtures document with tables for my developers but it's taking ages because of this bug... 

Bump - converting a lot of our previous specification documents that contained a large number of tables 10+ and it's taking so much longer to do something in the server version of confluence was a breeze.

Definitely not a minor issue hope this gets raised in priority.

Disappointing that this has not been addressed yet and that its been assigned a severity level 3 - minor.

Its not minor if you have to try editing a large table. 

Same behaviour as Gideon's for me in Chrome. 

Bump, chrome user. Any time I have a table with more than 10 rows I have non-stop keyboard typing lag. I do not need to have 10 tables in my document, just a single table with 10 or more rows and 3 or more columns and the lag is incredibly long and makes using confluence a nightmare.

I have experienced this for almost a year. It is tremendously frustrating as table based note taking and thought structuring is one of the most useful parts of confluence. Can this issue please be bumped in priority??

Bump - firefox user with several-second lag on a page with a 30-row table (keyboard typing delays, unresponsive Publish button over several minutes, sections of table taking several seconds to load on scroll) making Confluence very frustrating to use.

I'm using safari and using confluence cloud. Recently my confluence slowness load and keyboard typing delays. Do you have any workarounds? while your team solve the issues? and what's the reason?

It feels a bit ironic to get a promotional email from Atlassian celebrating bug fixes with the headline"Begone bugs! We don't love you" and a couple of hours later the resolution date of this issue is again pushed months into the future. 

We've been experiencing this problem since May 2020 and my colleagues (and me) are running out of patience, because it is just such a waste of time.

Same thing here, we are using Google Docs to manages out tabular data with links to Jira, with only the link in the Confluence doc.

@Roman Tekhov,

Have you been able to make ANY progress on this issue? Incremental performance improvement would be greatly appreciated rather than batching up many small fixes waiting for a big update.

How much does Atlassian server's load impact this issue?  Today, I've experienced 10X more lag editing a table in one hour than an entire day yesterday.  This difference is significant and I'm doing the exact same task as yesterday. It's really frustrating because you're entering data, the page freezes and then 30+ seconds later the page scrolls to the bottom of the page and your data got pasted somewhere else. So its not just slow and loss of productivity, it actually leads to data errors.

Does Atlassian use their own product? There is no way that a competent developer using Confluence could ever run into this bug and not immediately try and solve the issue as being the most excruciating usability bug. There's also no way that a competent developer could have such a severe bug open for so long with absolutely no progress.  

I'm not sure who or why someone has this classified as "minor" severity (clearly, you don't understand the issue).  This is the showstopper bug that will have me stop using Confluence and move to Microsoft or Google for collaboration.  The time lost due to lag will actually be less than the pain of switching a team to another solution.  I've lost confidence in Confluence developers due to the lack of progress on this severe bug.

This should at lest have a warning when editing the page, "Sorry Confluence is not capable to handle this much information. Plase edit your page in several pages. "

We are experiencing severe performance problems on pages with tables whilst editing.  The pages in question are all based on the Products Requirements template.  The pages contain around 150 rows in a table, but even with just a handful of rows you experience the issues.

Primarily we see frozen page issues and delays in keyboard response.  In some cases the keyboard fails to respond for several seconds and makes editing the page completely unusable.

Equally this is not a network related issue and we see the same behaviour across various browsers.

We have a number of pages which each contain a single large table and have a large number of Jira macros (linking to individual tickets). Often we'll try to edit the page - sometimes two or three of us at once - and find that the page loads very slowly, macros load slowly, and the page scrolls back to the top as it loads.

One of your support engineers was unable to duplicate the problem. However, most of us in the organisation have had this problem, some in the office and some WFH, so it's not to do with our network or equipment. We use various different browsers, although we're all on Windows 10.

Splitting into multiple pages is absolutely not a workable solution for us; neither is removing the macros, as we need the information at a glance. It's disappointing that your suggested solutions come down to 'Don't use the functionality'.

We have page that is an Encyclopedia of terms. It is fast to load, but we are facing the problem where the new editor is slow to respond to clicks and typing. It only has text and URLs on it. There are roughly 2,500 lines and 66k characters. We're looking forward to an improvement.

I arrived here after experiencing the issue with pages very slow to respond to any clicks or typing if the page has a bunch of tables (https://jira.atlassian.com/browse/CONFCLOUD-65329) . It doesn't seem to matter as much how many rows the tables have, just the number of tables on the page. This is a major blocker to create a single requirements document as the page editing feature becomes completely unusable. A bit concerning this has been an ongoing issue since 2018, and tables are a very basic, critical feature.

https://community.atlassian.com/t5/Confluence-questions/Edit-and-other-buttons-take-forever-to-load/qaq-p/1545347

Customer met this issue when evaluating the confluence cloud.

This is high priority issue, but it has not been resolved such a long time.

And workaround cannot be the solution for customer.

Do you have any plan to fix it?

Quick question for everyone watching this issue (especially Atlassian support folks): has anyone been looking at storage allowance in their subscription as a possible contributing factor?

It just occurred to me that teams who have a large amount of data in their instance, not just in single pages, or are nearing or over their limit, might have overhead they aren't aware of.

It may not matter. Hopefully someone can tell me if this has already been ruled out as a factor. (I just found out that when you copy a page, its attachments are also duplicated in the back-end. Even if you create a copy of a page, and don't publish it (an unpublished draft), this will also keep the attachments. So our team has some spring cleaning to do as we probably have a bunch of that.)

https://community.atlassian.com/t5/Confluence-questions/Local-browser-sees-heavy-memory-increase-after-editing-pages/qaq-p/1544280?utm_source=atlcomm&utm_medium=email&utm_campaign=mentions_answer&utm_content=topic

Adding another report. I include a reproducible demonstration of slowness related to memory consumption/management on rather simple pages that requires user intervention to work around or.. significant productivity loss and user frustration.

https://community.atlassian.com/t5/Confluence-questions/Large-pages-in-the-Cloud-are-slow-to-use-and-worse-when-screen/qaq-p/1531990

A quick profiling on my Firefox seemed to indicate a lot of GC going on, when it slowed down in the editor.
It also seems we see this a lot when there code examples or code formatting on the page.

Hello, I expect we found a pattern that causes horrible slowness
1) Page which is very long is being edited (example https://signanthealth.atlassian.net/wiki/spaces/TMAXUM/pages/482141973/Management+team – see from history the page content e.g. on 2020-Oct-26 as we might split this to multiple pages
2) There are multiple editors (in our case 10) at the same time editing the page
--> Confluence is so slow that it is almost impossible to use. This was not the case before migration

I don't see why a network connection would have anything do do with throttling limits. Unpopular opinion here (I'm just another customer) but Very Large Tables are nearly always a waste of time. There are practical and more agile solutions to creating these kinds of pages...

could it be that the error message has evolved to a gray banner stating: We've lost our connection to you, so we've disabled editing to prevent any issues. You'll be able to edit once we reconnect. Trying to reconnect... 

We don't experience this as Minor. We have a large page which is difficult to edit and wastes a lot of our time.

@Mario Nebl or someone?

What is the release date for this bug, I am seriously looking to cancel my service with you at this point.

Hello!

Thank you all for raising support cases and watching this ticket. We have been working on small improvements to this and trying to get a better understanding of the problem over the past few months, but based on your continued difficulties we know we haven't done enough to meet your needs. My team will be focusing on this issue over the coming weeks with mnebl@atlassian.com leading the work.

We're sorry for all the pain and frustration this has caused, and we hope we can give you a better experience soon!

Thanks,
Lucy

We are also facing this issue with tables of more than 200 rows.  Surprising, why a tech giant like Atlassian with access to the best engineers is not able to resolve this for months now.

Hey all,

Thank you for the continuous feedback on performance improvement needs within the Confluence editing experience. Over the next 12 months, Atlassian teams will be delivering incremental improvements to performance by updating various parts of the backend architecture. These improvements include ones around typing performance, and we anticipate a faster response compared to the current delay between keystrokes.

Because not all performance issues stem from the same cause, we are aggregating potentially disparate issues within this ticket. We can continue to do so with your help in providing additional details on what your page contains. If you are able to remove elements and see performance improvements, sharing that information can help us narrow our focus on key elements that are slowing page performance. Thank you for your help and continued feedback to improve the editing experience!

Best,

Sunny Xu

We've been experiencing this issue since about mid-May. It mostly seems to affect pages with longer tables, but every now and then pages with small tables (e.g. 3x3 fields with little content and only text in each cell) show the alert. 

The issue is affecting us heavily and a resolve would be very much appreciated. 

Hi, I have been asked to comment on the bug.  We don't have what I consider to be a large portfolio of projects.  Up until last week the "Portfolio Dashboard" was working fine.  It is now not displaying the information required to be of use to the Business Technology Director and Project Portfolio Office.  Having to break this down into a number of pages defeats have a dashboard, especially as it is slow to load.

Your urgent attention would be appreciated.

Thanks

Roger

Hi X,

The document is a manually made page (not a pre-built template) with few macros:  a TOC, 1 or 2 tables, a Jira issue list, a couple of task reports and a bunch of text.  I wouldn't even consider it all that large of a page.  The intended use for the page is to have 2 or 3 people editing it at the same time while taking notes during a live interactive discussion, which we obviously can't do.

I tried loading and editing one of these types of pages this morning and the page itself takes about 30 seconds to load for plain viewing, and a little longer before any editing can be done.  Once editing can technically be performed, the editing itself is almost unusable as you can't even see what you're typing due to a multi-second delay in display.  On my first edit attempt one of the macros didn't load either and I had to refresh.  Publishing takes less time, 10 - 20 secs.

My organisation uses Chrome but other browsers have been tried and are not any better.  My memory and cpu usage is normal and I don't have any other speed issues with other apps even when they are tabs in the same Chrome instance as the Confluence page.  Incognito mode does not help at all or if it is helping it's negligible.  Firefox gives a similar but slightly worse experience in terms of speed when compared to Chrome with the added nugget of getting warnings from the browser saying "a page is loading slowly causing issues...".

I don't know what a smartlink is since I don't have access to any macro called that, but if it's just a link, then the page contains few of them.

As Carla mentioned in her comment, one work around is to break the page into many pages, but my users don't want to do that so they've been using the old editor instead which seems to work much better.

How do i give you access to one of these pages?

The workaround at present for this issue is to split the content of the page into multiple pages. .

Hi jackson20,

Thanks for your comment. I am interested to know a little bit more about the kind of document that you guys are working with. It would be great if we could access the page (or similar structure page) to assess it internally, as most of the problems we are aware of are related to tables/smartlinks. 

Few updates:

• Last week we pushed a fix for pages that contained a lot of smartlinks. Big pages would perform poorly. Please ensure you refresh the page in order to get latest version with fix. 
• Previous weeks we fixed some general problems about delta algorithm that was slowing all pages down.
• Team continues working on fixing some general performance issues.

Other general concerns that you could check:

• We are working with some well-known browser extensions that are slowing overall pages down. So, please ask your users if they can open browser in incognito (or extensions disabled) to check if pages perform better
• We are working with Chrome in regards some performance problems introduced lately. You could use other browsers like Firefox in the meanwhile to identify whether it is a browser issue
• Some macros may introduce some performance regressions. Please let us know if you face any problems with specific one.

We'll keep you updated

Hi,

We are having this performance issue consistently with larger documents that we are importing from Word, sometimes with only 1 or no tables in the document at all.  This performance issue is forcing us to use the old editor instead of upgrading pages to the new editor.

The Word import process seems to use the old Confluence editor and if we simply use this page as imported then everything is fine.  However, we are told that the page is eligible for an upgrade to the new version and if we do this upgrade, the page becomes so slow its completely unusable in edit mode for some users and some users can't publish at all while others that can publish have to wait a minute or more to publish followed by another minute for the published page to load.

I have seen other performance issues for the new Confluence editor being posted as Resolved, but it seems there is still a long way to go in terms of performance fixes.

Hi Team,

Can we get any updates on the ticket? We are facing the issue and our customers are asking for the fix or workaround. Can you please expedite this request.