Confluence Performance Journey: 2x Faster in 1 Year

[#1]

So what does it mean to be 2x faster? Please allow me to share some context with you first

Intro

Hi folks, this is a long overdue first blog of series about Confluence Cloud performance journey and achievements. Little about me - I’ve been with Atlassian for almost 7 years, started by managing a frontend platform team, which was responsible for evolving our front-end code. As time passed by, I managed various additional teams in Confluence like Migrations, Permissions, and Developer Productivity. Today my group is mainly focused on end-to-end Performance.

How it all began (for me)

Back when I joined, one of the my favorite Confluence Cloud managers, Aaron, was looking at performance numbers - Apdex few times a day, and would come (yeah, physically approach as we were in the office back then, sitting all together) to one of my engineers - Ran, to take a look every time it dipped. Wow, how things changed since then. Now we have automation to detect performance regressions, a whole performance team in each product, as well as central DevInfra team developing these tools. But more on that later.

Metrics Journey

As mentioned above, we were measuring performance with Apdex, then we moved to TTI. But we had our own definition of it - when the main content rendering component is loaded. Which meant that main content has been rendered and is also interactive. It also meant we just started loading any async macros the page had - both 1st party and 3rd party (think Gliffy, resolving links, Jira macro, etc…). While macros are loaded, they would resize themselves and the page content would constantly shift. TTI metric has already fired before, so it did not capture real user experience, and users are unable to consume the content up until the page has stabilized (no more shifts). To ensure we capture the real user experience, we moved to the latest and greatest TTVC - Time To Visually Complete. We are using VC90, which means when 90% of the page has visually completed, this allows for small updates of the remaining 10%, which usually are something like notifications count and alike, that should not affect the ability to start consuming the page. This metric is also not perfect, as it measures all DOM attributes mutations, some of which doesn’t affect the visibility. It means that on the engineering side we need to do slightly more work.

Above, I presented the main metric we had selected to measure performance, and we also monitor others - FCP, LCP, TBT and CLS. FCP is especially important as it represents when user can see the first content-full paint of the page, and stop staring at the empty screen .

When it comes to percentiles, we’re a P90 company. This allows us to capture the vast majority of most painful scenarios. As our solution is an SPA (Single Page Application), we measure initial load, which is slower and transitions separately. This is a good segue into our SSR (Server-Side Rendering) journey.

SSR In Confluence

About five years ago, after doing all possible optimizations for initial load of our SPA application, like - early data preloading, using service worker to serve initial HTML from cache, and many more, we’ve realized we hit a roadblock, and unavoidable came - we have to do the Server-Side Rendering. We collaborated with platform team, which delivered the rendering container, created our own orchestration service and deployed SSR for initial load of our viewing experiences. The page load experience became significantly better, P90 FMP (FMP in this scenario is the server-side rendered HTML, downloaded and parsed by the client machine) was reduced by about 50%. Slower machines had the biggest benefit as rendering the initial HTML was now done in our controlled environment.

We started from SSRing only the main content of the page and worked on including more and more page elements in the initial HTML.

Here is an example of before SSR (left) and after (right)

SSR Architecture

We even got a patent for our SSR technology https://patentsgazette.uspto.gov/week22/OG/html/1535-1/US12321757-20250603.html

2x Times Faster in 1 Year

You must be wondering - so how Confluence became 2x faster in only 1 year. Well, stay tuned, this will be the topic of my next post

[Tomislav Tobijas]

Nice visualization of the architecture behind all of this! Thanks for sharing @Ilia Fainshtroy ! 🙌

[Patrick S_ Stuckenberger]

to be honest:

this is a good start but far more work will be necessary to reach m365 sharepoint speed. 

I doubt that this will be possible without an edge proxy on the customer site. 

it also will be just a matter of time since the AI/rovo processing will be done at the customer edge. 

LLM Hardware became really affordable, a solution design with containers and AMD Ryzen AI Max+ is not complicated ant the environment is not a devops challenge. 

The Atlassian products tend do be expensive and every company using the datacenter edition experience a big resistance from the user base because of the lack of the former snappiness. 

especially almost every addon from the marketplace has the same problems with loading times, api request limits. 

those discussions are not new and similar options also were an option in an Atlassian  customer survey back in 2017. 

make Atlassian great again ; )