Confluence Performance: Roughly 2x Faster—Again

[#1]

It’s been a while… I’m back to talk more about Confluence performance.

Previously, I shared how we made Confluence roughly twice as fast in FY25, then went deeper into React 18, hydration, streaming, and server-side rendering (SSR). We were proud—but not done.

TL;DR: what got faster for you

During FY26, we worked across viewing, editing, page weight, and regression prevention so you get pages that appear sooner, settle faster, and become ready to use more quickly.

• Your View page finishes rendering sooner: View TTVC improved by 44% at P50 and 30% at P90.

• Your Edit page becomes ready sooner: Edit TTVC improved by 43% at P50 and 26% at P90.

• You see the first content sooner: View FCP improved by 40% at P90.

• You get a steadier page: View layout shift improved by 66% at P90.

There was no single silver bullet. Streaming, React Compiler, deeper SSR and hydration, smaller payloads, and stronger performance checks all added up to a faster experience.

Faster viewing

When you open a page, you should not have to wait for everything to finish loading before you can start reading. We focused first on getting useful content in front of you sooner, then on making the page settle faster and feel more responsive.

React streaming: content appears sooner

Instead of waiting for the whole page to be ready before sending HTML to your browser, React streaming lets us deliver useful parts of the experience as soon as they become available. This improved P90 First Contentful Paint by 40%, so you spend less time looking at an empty screen.

View page before and after streaming

Optimizations made since then

Showing the first content is only part of the story. A page can appear quickly and still feel slow if elements keep moving or your browser has too much JavaScript work to do.

We made server-rendered and client-rendered pages work together more reliably, adopted React Compiler in heavily used components, improved how links and macros load, and reduced the JavaScript shipped on View by 15.8%. For you, that means a page that not only appears sooner, but also feels calmer: P90 layout shift fell by 66%.

Faster editing

Reading is only half of Confluence. You also need to move from consuming information to contributing without losing momentum.

Faster edit load times

We brought hydration deeper into Edit and Live pages, preserving the HTML already produced by the server and attaching interactivity instead of asking React to recreate the page from scratch. We also simplified the editor’s server-rendering path, prefetched draft data before View-to-Edit transitions, and reduced rendering work on large, complex pages.

The result for you: Edit TTVC improved by 43% at P50 and 26% at P90, while the editor supports documents up to 40% larger.

Less work for your browser

One of the most reliable ways to make a page faster is also one of the least glamorous: send less data and do less work.

During FY26, we reduced the uncompressed HTML payload for View by around 30–40%. We also continued moving from Apollo toward Relay and modernized more of our rendering foundation, including our bundler and server-side JavaScript engine.

To be clear, fewer backend calls are not delivered yet. The Relay work completed in FY26 established the foundation. This fiscal year, we plan to use it to consolidate requests and reduce backend calls during page load—so future page loads can do less network work.

Protecting the speed you gained

Shipping a performance improvement is only the first step. You should keep benefiting from it as Confluence evolves.

We moved performance checks earlier in development by expanding automated testing, adding more SSR and hydration coverage, and improving feedback during local development and pull-request reviews. We are also using AI-assisted tools to spot known performance anti-patterns and help investigate regressions.

The goal is simple: turn lessons from previous problems into earlier feedback for engineers, so performance issues can be caught before they reach you.

What comes next

Making Confluence faster took improvements across the whole experience: earlier content, less browser work, steadier layouts, faster editing, and stronger regression defenses. Performance work is never really finished, but our goal stays the same—to make Confluence’s growing capabilities feel simple and fast for you.

In a future post, I would like to go deeper into how we use automated and AI-assisted guardrails to catch performance problems earlier. Stay tuned—and let me know in the comments which part of the journey you would like to hear more about.

[zoltanersek _outpostlabs_dev_]

That's a solid improvement, did you get much help from ai coding agents on this, I'm curious how good they are when it comes to frontend performance tasks

[Ilia Fainshtroy]

Great question @zoltanersek _outpostlabs_dev_ ! We use AI coding agents extensively, but primarily as accelerators—not as the source of our performance strategy. They’re effective at well-scoped frontend performance tasks, such as generating or refactoring code and applying known optimization patterns quickly. Engineers still decide what to optimize, interpret the data, set the architectural direction, evaluate trade-offs, and validate customer impact.

Beyond coding, AI has helped us operate at scale: generating performance-specific lint rules, reviewing changes for known anti-patterns, creating straightforward fix PRs, and triaging synthetic performance-test results. We also use AI to assist with performance investigations—bringing signals together, identifying likely causes, and suggesting where engineers should look next. It has been genuinely helpful in several cases, while the final diagnosis and decisions remain with engineers.

My take: AI agents are strong force multipliers when supported by good telemetry, clear guardrails, and engineering review—but they’re not a substitute for performance expertise.

[zoltanersek _outpostlabs_dev_]

I agree, this is pretty much my take on it as well, thanks for replying @Ilia Fainshtroy 

[Josh]

Sharing some AI-translated definitions from this article in case less technical users stumble upon it and want to understand a bit more about the metrics:

• TTVC = Time To Visually Complete

  • How long it takes before the page looks fully loaded to a user.
  • Not necessarily "everything is finished," but the screen appears complete and usable.
  • Lower is better.
  • If TTVC drops from 10 seconds to 5 seconds, users perceive the page as loading twice as fast.

• FCP = First Contentful Paint

  • How long it takes before you see the first meaningful content on the screen.
  • This could be text, an image, or another visible element.
  • It answers: "When do I stop staring at a blank page?"
  • Lower is better.

• P50 = 50th Percentile (Median)

  • 50% of page loads are faster than this value.
  • 50% are slower.
  • Think of it as the experience of a "typical" user.

• P90 = 90th Percentile
  • 90% of page loads are faster than this value.
  • Only the slowest 10% are worse.
  • This measures how well the system performs under less-than-ideal conditions (slow devices, large pages, poor networks, etc.).