Confluence Performance - React Streaming, SSR tuning and more

[#1]

Missed me yet? Well, I’m here to talk more about Confluence performance. As promised in the previous blog, let me share more about React 18 streaming, SSR optimizations and more !!!

React Streaming

FCP (First Contentful Paint)

On the graph above you can see FCP of initial load of a view page. We’ve been doing some improvements over time, and you can see the most significant performance gain, around 40% for P50 and 20% for P90, were achieved when we rolled out React streaming. Now you can see page content, usually in the navigation, faster. This is just the beginning for streaming improvements. Next, we will work on splitting the page into more streamable section and other optimizations to further push the FCP numbers down.

Here is a side by side comparison with (on the left) and without (on the right) streaming, please note that we reduced the video playback on purpose to highlight the differences.

Sharing the wins we have delivered is obviously the biggest pleasure and reflects the hard work of multiple engineering teams, but I also want to talk a bit about work that is in flight.

SSR Optimizations and Relay

The team is working on optimizing our SSR latency, more specifically both the time it takes to fetch the data as well as to render the HTML. On the fetching side, we’re working on further improving latencies of our backend calls, and also how to fetch more efficiently - ensuring we are not over-fetching or fetching the same data more than once (and… surprise, in some cases we do ). To help with the latter, we are moving our client side graphQL library from Apollo to Relay, which will solve many of the problems out of the box.

Our goal is to reduce the amount of GraphQL backend calls executed during a page load, by unifying as many calls as possible. This (many backend calls) is also a common complaint we sometimes get from our users. To optimize HTML creation, we are currently working on updating the V8 JavaScript engine we leverage, as well as introducing other optimizations like compute fine-tuning. I will share more details on the work done and impact in future blog posts.

Atlaspack (Parcel)

We recently switched our bundler from Webpack to Atlaspack (Parcel). On top of about 6% improvement on the initial loads of the pages measured by TTVC, even bigger improvements are seen to build times. Atlaspack builds are about 70% faster, due to more optimized packing algorithm, a huge win for developer productivity and infra costs.

Teaser

In the next blog I will touch on tooling we have built to be able to better manage and prevent performance regressions. These are inevitably introduced over time, as many teams are working on new and existing features. Stay tuned, and also feel free to suggest, in comments, specific topics you might be interested to learn more about.